On Mon, May 11, 2020 at 4:36 PM Hugo Krawczyk <h...@ee.technion.ac.il> 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.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls