Am Montag, 19. Juni 2023, 12:53:32 CEST schrieb Bas Westerbaan: Hi Bas,
> Hi Stephan, > > From your e-mail it's unclear which attack you worry about, but in the > attached document, you describe the problem unique to the implementation of > Kyber in TLS as: > > If the random number generated > > > for the encryption operation is weak, an attacker may sniff the pk sent > > over the wire and “guess” the random number to obtain the shared secret > > ss. > > This is not unique to Kyber. If an attacker can successfully guess server > randomness, then they can guess the private key of the server's ephemeral > ECDH keypair (checking against the server keyshare), and compute the shared > secret as well. As I tried to outline in the end of section 1.3, the issue is not too much different from current DH-based or RSA-keywrapping-based TLS establishments. However, I would like to start a discussion whether this issue can now be addressed and fixed such that even if one side has insufficient entropy, the communication channel can still be cryptographically strong as stated in the first sentence in chapter 2. > > Adding an extra ephemeral server KEM keypair to which the client > encapsulates doesn't change the situation: the attacker you describe can > still guess the KEM private key, and then decrypt the extra shared secret. With the Kyber KEX, if you guess the servers entropy / random numbers, you can still not break the Kyber KEX shared secret as it in addition depends on the entropy / random number produced by the client, too. The key of the issue is: - Kyber adds entropy and thus security strength only with the Kyber encapsulation operation - the Kyber KEX operation ensures that the client and server independently perform a Kyber KEM encapsulation - the individual Kyber shared secrets derived from the indvidual Kyber KEM encapsulation/decapsulation are concatenated to derive a final shared secret that is returned to the caller for further use. Thanks Stephan _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
