Subject: Re: [Openpgp-dt] Version 2 Sym. Encrypted Integrity Protected Data Packet Format

From: Justus Winter <[email-masked]>
Date: Tue, 01 Mar 2022 10:02:00 +0100

Hello NIIBE :)

NIIBE Yutaka <[email-masked]> writes:

> Thank you for the test vectors.  Next attempt of mine is v2 SEIPD, and I
> confirmed my imprementation works with the test vectors of EAX and OCB.
> (I don't yet have GCM.)

Great!

> During reading the spec., I noticed two things.
>
> * It would be better to have a field for HKDF hash algo (in v2 SEIPD
>   packet).
>
>   - Currently, the crypto-refresh.md uses fixed hash algo of SHA256.
>
>   - I wonder if someone wants to use different hash algo for larger
>     cipher key.
>
>     - We should note that, TLS 1.3 has TLS_AES_256_GCM_SHA384, which
>       uses SHA384 for such an hkdf with AES256.

AIUI, HKDF has two parts, extract and expand.  RFC5869 notes that

   The second stage "expands" the pseudorandom key to the desired
   length; the number and lengths of the output keys depend on the
   specific cryptographic algorithms for which the keys are needed.

Note how this does not depend on the choice of hash algorithm.  Further,
the expand phase has a parameter L, the output keying material length,
that can be freely chosen with the constraint "[L] <= 255*HashLen".
This seems more than adequate even with the fixed hash algorithm.

> * The construction of nonce looks not good for me.
>
>   - Currently, the crypto-refresh.md uses:
>
>     The left-most N - 64 bits are the initialization vector derived using HKDF.
>     The right-most 64 bits are the chunk index as big-endian value.
>
>   - In TLS 1.2, it uses RFC5116 method;
>     nonce: composed by random part + counter part.
>     addtional data: composed by counter + something.
>
>   - In TLS 1.3,
>     nonce: XORed with random part and counter.
>     addtional data: with no counter.
>
>   - I think not including counter in additional data is good.
>
>   - I wonder why not use XORed nonce (given the use of HKDF, which can
>     generate more, easily)?

We changed that recently to accommodate cryptographic APIs that expect
the nonce to be a monotonically increasing counter:

https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/84

Justus