Re: [TLS] Before we PQC... Re: PQC key exchange sizes

[Ilari Liusvaara <[e-mail]>]

On Fri, Aug 05, 2022 at 10:11:05PM -0700, Benjamin Kaduk wrote:
> Hi Scott,
> 
> On Sat, Aug 06, 2022 at 03:18:31AM +0000, Scott Fluhrer (sfluhrer) wrote:
> > 
> > I’m trying to figure out what you’re saying; at least one of us is
> > confused.  NIST asked for a Key Exchange Mechanism (KEM), and Kyber
> > meets that definition (which is essentially what you describe; both
> > sides gets a shared secret).  That is the functionality that TLS
> > needs, and is the functionality that NIST (and others) evaluated. 
> > Yes, there are internal functions within Kyber; no one is suggesting
> > those be used directly.  And, yes, NIST might tweak the precise
> > definition of Kyber before it is formally approved; any such tweak
> > would be minor (and there might not be any at all); if they do make
> > such a change, it should not be difficult to modify any draft we put
> > out to account for that change.

My guess about the changes is replacing the four different SHA-3
variants (yup, KYBER uses all of SHA3-256, SHA3-512, SHAKE-128 and
SHAKE-256) with some kind of contextualized SHAKE-256. But That's deep
internals of KYBER, not something TLS WG needs to be concerned about.


> I thought KEM expanded to "Key Encapsulation Mechanism" (viz RFC
> 9180). Indeed, my understanding is that PHB's specific point is
> that it is *not* an exchange, and rather that the sender picks a key
> and the recipient just gets that key without contributing do it.
> (Well, I think there is maybe also some bit in PHB's note that's
> quibbling about how the sender doesn't actually pick the key, and
> rather the local output of the KEM is the encapsulated blob plus the
> shared key, with the shared key not being an input to the KEM ...
> but I haven't read NIST's report yet and can't confirm or reject that
> assertion.)  I am reading PHB as saying that the "internal function"
> within Kyber that is an "actual KEM" is one that takes the shared
> key as input and produces the encapsulated blob as output (again,
> cannot confirm or reject).

Due to how KYBER internally works, the public key does contribute to
the final key (e.g., see page 10 of KYBER specification version 3.02).
This leads to both sides contributing to the key if public keys are
not reused (as is recommended). However, I don't think that that
generically holds for IND-CCA2 KEMs.


> > It was my understanding that TLS 1.3 didn’t do rekeys
> > (ChangeCipherSuite).  Instead, the key agreement is done only at
> > connection establishment time, and could be broken into:
> > 
> >   *   Full negotiation (the client not having any context)
> >   *   Resumption (0-RTT or 1-RTT) negotiation (where the client has
> >       some secret data from a previous full negotiation)
> > Because those are both fresh negotiations, I don’t see any
> > alternative to using a postquantum key exchange for both.
> 
> There's also KeyUpdate.
> And the PSK handshake mode that's just psk_ke, not psk_dhe_ke.
> But I don't think I understand PHB's proposed taxonomy yet, either.

I think the point was that even if PQC key material is just indirectly
chained, the thing is still PQC. Of course, only relying on indirect
chaning is not a great idea.

As for TLS 1.3, there is little problem doing direct PQC for both,
because psk_dhe_ke resumption is possible, and (hybrid) PQC KEMs look
like DH to TLS 1.3.



-Ilari