David Stainton <[email protected]> writes: > Hi Kris, No. Let’s not move the discussion away from the draft and > from the extremely relevant context of TLS. > > Restoring the hash is reasonable and NIST’s removal wasn’t well > motivated or justified, their silence to reasonable questions now is > suspicious when we consider the relevant history. > > There may be better designs but they will only slow down deployment. > The best course of action is restoring the hash over m. It lasted for > three rounds without a security issue being found by NIST or NSA. > > I am going to update the golang hpqc library and the katzenpost mixnet > project will take the defense in depth route.
The NIST Kyber patent license only grants you a license to use ML-KEM when implemented according to NIST specifications. If you deviate, such as by taking the defense-in-depth approach to hash m to improve robustness against a compromised PRNG, the NIST patent license does not cover your usage. People in the IETF used to prefer patent un-encumbered technology, but things are different today. https://csrc.nist.gov/csrc/media/Projects/post-quantum-cryptography/documents/selected-algos-2022/nist-pqc-license-summary-and-excerpts.pdf /Simon > David Stainton > Founder and core developer, Katzenpost post quantum mixnet > > On Sun, Jul 12, 2026 at 1:08 PM Kris Kwiatkowski <[email protected]> wrote: >> >> >> On 12/07/2026 09:06, John Mattsson wrote: >> >> >> Regarding Jakob Appelbaum's suggested text, I agree that wording >> along the lines of "the m value is recoverable by the decapsulating >> peer" should be added to draft-ietf-tls-ecdhe-mlkem, >> draft-ietf-tls-mlkem, and likely to future IETF KEM specifications >> as well. >> >> >> I agree with the points below, including that the broader CSPRNG >> guidance discussion belongs in a wider IETF context such as an >> RFC4086bis effort. >> >> On where the suggested text about 'm' being recoverable by the >> decapsulating peer should go: I think >> draft-sfluhrer-cfrg-ml-kem-security-considerations is the proper >> home for it, rather than the documents that merely define code >> points for TLS. The TLS drafts could then simply reference >> it. Duplicating ML-KEM security considerations across >> draft-ietf-tls-ecdhe-mlkem, draft-ietf-tls-mlkem, and every future >> KEM code point document seems fragile, and a single CFRG document >> keeps the guidance consistent. This follows the same logic as your >> RFC4086bis suggestion: put the guidance where it can be referenced, >> not in each protocol-specific draft. >> >> For the same reason, the discussion itself belongs in CFRG, where it >> would get review from the crowd focused on cryptographic mechanisms. >> >> Cheers, >> Kris >> >> _______________________________________________ >> TLS mailing list -- [email protected] >> To unsubscribe send an email to [email protected] > > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected]
signature.asc
Description: PGP signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
