I do have to add to Thom's remarks that KEMTLS (a.k.a. AuthKEM) offers an advantage here. If the private key of the leaf cert is not compromised (for instance when it was generated elsewhere), then the attacker Stephan describes cannot learn the shared secret.
On Mon, Jun 19, 2023 at 5:02 PM Thom Wiggers <t...@thomwiggers.nl> wrote: > Hi all, > > The attack that is described by Stephan is something that we considered > while we were initially designing KEMTLS (in the papers, we also covered > the ephemeral key exchange). I'll quickly write what we were thinking of > and why we did not choose to do anything similar to what Stephan proposes. > > I will be correcting for the misunderstanding in the document put forward > by Stephan, which suggests that Kyber is an asymmetric encryption scheme. > Encapsulation and Decapsulation should not be confused with encryption and > decryption, which are not part of the public API of Kyber and will not be > part of the NIST standard as far as I'm aware. > > I believe we can summarize the argument as follows: in the straightforward > replacement of ECDH by a KEM, the client generates a keypair and the server > (through the encapsulate operation) computes a shared secret and a > ciphertext. If either the secret key or the shared secret are made public, > for example, due to an implementation flaw of either keygen or > encapsulation, then the ephemeral handshake key is no longer secret. > > Bas correctly points out that this is not different from ECDH, where > compromise of one of the two exponents leads to shared secret computation, > but that in itself shouldn't necessarily be a reason not to investigate if > we can do better. > > But, in my view, the proposed defense and the argument put forward assumes > that the flaw that affects encapsulation does not affect the key generation > (or vice versa); in particular, in the scenario of the broken server-side > random number generator it seems far-fetched that the busted random number > generator or implementation flaw affecting encapsulation won't *also* > affect the keygen (or in other scenarios such as side-channel > vulnerabilities, decapsulate) operation of the server. This, in my view, > makes the additional security offered by the additional key exchange very > marginal. > > The reason why we were investigating this issue was a bit different: > having two KEM key exchanges gives the server more control to ensure that > there will be at least one freshly-generated KEM keypair in the mix. This > could improve the forward secrecy for handshakes (modeled via secret key > exposure) in which the client just re-uses the ephemeral keypair every > single time. But we also saw this as not significant enough to suffer the > additional, significant transmission requirement of another full Kyber key > exchange. Hopefully, we now have enough experience with evaluating > implementations of TLS to find and fix these sorts of key-reuse flaws more > easily, earlier, and in automated ways [1]. And again, this is the same > situation with ECDH today. > > Cheers, > > Thom Wiggers > PQShield > > [1] see e.g. https://github.com/tls-attacker/TLS-Scanner. Relying on > implementers not to make mistakes is a dangerous game, but I do believe > that it needs to factor into the cost/benefit analysis. > > PS: for marketing reasons I oppose comparisons between the post-quantum > KEM schemes (which are primitives that easily can be used in fully > ephemeral ways) and RSA key wrapping (which pretty much exclusively refers > to the much-derided non-forward-secure RSA transport in TLS-old). ;-) > > Op ma 19 jun 2023 om 16:01 schreef Stephan Mueller <smuel...@chronox.de>: > >> Am Montag, 19. Juni 2023, 15:56:57 CEST schrieb Scott Fluhrer (sfluhrer): >> >> Hi Scott, >> >> > I do not believe that Müller is correct - we do not intend use the >> Kyber CPA >> > public key encryption interface, but instead the Kyber CCA KEM >> interface. >> > And, with that interface, the server does contribute to the shared >> secret: >> > >> > The shared secret that Kyber KEM (round 3) generates on success is: >> > >> > KDF( G( m || H(pk)) || H(c) ) >> > >> > where: >> > - m is the hash of a value that the server selects >> > - pk is the public key selected by the client >> > - c is the server's keyshare >> > - H is SHA3-256, G is SHA3-512, KDF - SHAKE-256 >> > Note that this formula includes a value (pk) that is selected solely by >> the >> > client; hence we cannot say that this value contains only values >> selected >> > by the server. (reference: algorithms 8, 9 of the round 3 Kyber >> submission) >> >> My concern is that the security strength cannot depend on the pk, because >> the >> PK is sent in clear over the wire. Thus it cannot contain entropy. Thus, >> entropy only comes from the message m in your listing which is a random >> number >> that is generated by the server. Further, c depends on m and thus does >> not add >> any entropy either. >> >> Ciao >> Stephan >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
