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

On Mon, May 11, 2020 at 4:36 PM Hugo Krawczyk 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 suppo

Re: [TLS] Bikeshedding ECHO

I agree that it’s misleading and potentially confusing to newcomers. ETCH sounds like a good alternative. > On May 11, 2020, at 3:52 PM, Nick Harper > wrote: > > I see how the name ECHO can be confusing and support renaming it. All of the > proposed replacement names are fine with me. > >

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

Hi Quynh, see a couple of remarks below, On Mon, May 11, 2020 at 8:10 AM Dang, Quynh H. (Fed) wrote: > Hi Rich, Sean and all, > > 1) Traditionally, a HKDF-Extract is used to extract entropy from a DH type > shared secret. However, the first HKDF-Extract in the key schedule takes a > PSK instead

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

There is no flaw if you use HMAC and HKDF as intended. See details below. 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. R

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

I will forward this to the official comment address as well. I don't support making HKDF a NIST standard in its current form because there is a flaw. Consider the case in which the initial keying material is formed by concatenating two items, the second of which is a variable length string. As c

Re: [TLS] Traffic secrets: What's in handshake transcripts?

On Wed, May 6, 2020 at 1:09 AM Ben Smyth wrote: > As far as I can tell, secret [sender]_handshake_traffic_secret is computed > over transcript CH || SH or CH || HRR || CH || SH. (A server can compute > their secret once they've computed SH, whereas a client must wait until > they've received SH b

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

Hi Rich, Sean and all, 1) Traditionally, a HKDF-Extract is used to extract entropy from a DH type shared secret. However, the first HKDF-Extract in the key schedule takes a PSK instead of a DH shared secret. We don't see security problems with this instance in TLS 1.3. NIST requires the PSK to