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
