Hi Jakob, >It is not fair to characterize as a recommendation John. It is raising >that NIST made a mistake in removing the hash from the original design >of Kyber and not accepting that mistake as well motivated is part of >what we should be doing in this working group. Why are you not skeptical >of the hash's removal?
I don't think it was a mistake. I was initially very sceptical during the public PQC forum discussion, but I changed my mind for several reasons: 1. The removal was proposed by Markku based on implementation experience. 2. Revealing randomness is very common in cryptographic protocols and algorithms, and this trend is increasing with the introduction of privacy and grease mechanisms. 3. Deterministic hashing in general, or adding a protection mechanism only in ML-KEM, are not good solutions. It may even create a false sense of security. Security designs should not assume that an attacker will behave in a particular way. The history of cryptography contains many examples where partial mitigations delayed proper fixes rather than solving the underlying issue. Examples include the TLS 1.0/1.1 patches after BEAST, RC4-drop mitigations, and attempts to hide PKCS#1 v1.5 padding errors. >Meanwhile coincidentally, TLS 1.3 just went out and I would observe that it >isn't systematically addressing this class of issues. Agreed. This is also true for most other IETF protocols. >the TLS draft should not silently inherit FIPS 203's approved-RBG assumption >without saying so. I agree that TLS and other protocols should follow NIST’s approach and mandate the use of a strong CSPRNG. However, I do not think that “the TLS draft” is the appropriate place to define such a requirement. >I am concerned that you don't accept this distinction and continue to confuse >the two issues. >This again mistakes the issue at hand for entropy when it is about hidden >algebraic structure. >Restoring Kyber's hash is safer. I did not confuse the issues. Deterministic hashing provides very limited protection against an attacker-controlled RNG. An attacker can simply choose a known seed, allowing them to recover the seed from H(m). Using H = Hash_DRBG or H = HMAC_DRBG provides essentially the same security properties as using H = SHA3-256 as in Kyber. Restoring Kyber’s original hashing step is not safer than using m = H(m, additional entropy). The construction m = H(m, additional entropy) provides protection against a significantly broader class of attacker-controlled RNGs, because it incorporates independent entropy that is not under the attacker’s control. >John Kelsey (NIST) I think this is a much better and more informative reference: https://csrc.nist.gov/csrc/media/projects/crypto-standards-development-process/documents/dualec_in_x982_and_sp800-90.pdf In addition to being out of scope for this list and this discussion, I do not think John Kelsey deserves personal attacks. He is one of the greatest cryptanalysts of his generation and has made remarkable contributions, including his work with Bruce Schneier and David Wagner. Kelsey was among the cryptanalysts who demonstrated that Merkle–Damgård hash functions had deeper structural weaknesses than collision resistance alone. His work fundamentally changed how researchers evaluate hash-function security and influenced the development of more robust designs such as SHA-3. More recently, he was part of the team that identified significant vulnerability in the SHA-2-based variant of SPHINCS+. I think it is a prime example of why you should not use non-standard cryptography. However, given the long history of structural concerns surrounding SHA-2-based constructions, I believe the better approach would have been to remove the SHA-2 dependency entirely rather than continue relying on it. https://eprint.iacr.org/2022/1061 Cheers, John Preuß Mattsson
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
