Re: [Cfrg] NIST crypto group and HKDF (and therefore TLS 1.3)

[Phillip Hallam-Baker <[e-mail]>]

On Mon, May 11, 2020 at 4:36 PM Hugo Krawczyk <[e-mail]>
wrote:

> There is no flaw if you use HMAC and HKDF as intended. See details below.
>

One time pads aren't flawed if you use them right. When they become a two
time pad, there is a problem.

My point is that if we are developing schemes that are supposed to be used
as utility building blocks, we need to consider all the ways they might be
used and not just limit ourselves to the ones we expect. That was the
argument made for defining authenticated encryption modes, it holds here as
well.


> The bottom line advise is: If you are using related (not random) salt
> values in HKDF, you are probably using it with  domain separation
> functionality. In HKDF, domain separation is enforced via the info field
> not the salt. Read the HKDF RFC and paper for background and rationale.
>

I am already using the info field for domain separation. I use info to
generate separate keys for encryption, authentication, any IVs etc. by
concatenating the IANA protocol name and the encryption function. So I
don't want to put any more in there.

It is easy enough to fix if you are aware of it. I noticed the issue while
I was implementing HMAC by hand. But the person who is using the function
using a library call (i.e. myself five years from now) might not be aware.

Saying 'read my paper' really isn't an argument. I know the design
rationale. I am saying it is the wrong one for the future. And regardless,
I don't see mention of the issue in section 4.2 of the paper you cite nor
is there mention of the issue in RFC 2104.

If I have to go hunting to find security issues with a standard, that is a
problem in itself.


BTW, the reason it came up with DARE was an attempt to address the problem
of 'encrypting the subject header' and other metadata separately from the
content data. But under the same key. Bearing in mind that we want to be
able to encrypt multiple data items under a single key exchange.

So starting from the result of the key agreement, I add in a per envelope
salt which is typically 128 bits. That allows for erasure of the message by
overwriting the salt value. The main data content is encrypted under a KDF
with the IKM and envelope salt. If additional encrypted data sequences are
required, they are encrypted under the IKM, salt and an additional counter.

Now I can fix my designs, but others won't. Considering the EDS counter to
be an extension to the key led to the unexpected result that the EDS and
content were encrypted with the same key. Now, it is arguably better
considered to be a part of the salt which is where I think the current code
is (have to check). But my general point stands, this should be a utility
function but the Feb 1997 spec does not meet our standards today.