Wait— if you _have_ the encaps randomness, you have everything the Encaps() side does, and _must_ have the shared secret(s), otherwise the KEM scheme is incorrect
On Sun, Mar 1, 2026, 12:18 PM Scott Fluhrer (sfluhrer) <[email protected]> wrote: > Actually, that's precisely the point I was attempting to make (and > apparently failing). > > Even though 8446 gives permission (by the SHOULD NOT not actually > forbidding it), in this specific case, it doesn't work (and although we > know the technical reasons, an implementor might not). Hence, in this > corner case, the requirements are stricter than what 8446 mandates. > > Oh, and I just noticed (and perhaps this is common knowledge): if you used > the same encapsulation randomness to encapsulate to two different public > keys (from the same parameter set), then it is fairly easy to recover both > shared secrets (assuming access to both ciphertexts and public keys). > Hence, the MUST NOT reuse encapsulation randomness statement is there for > an extremely good reason. > > ------------------------------ > *From:* Deirdre Connolly <[email protected]> > *Sent:* Saturday, February 28, 2026 8:17 PM > *To:* Scott Fluhrer (sfluhrer) <[email protected]> > *Cc:* Ilari Liusvaara <[email protected]>; <[email protected]> < > [email protected]> > *Subject:* Re: [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends > 2026-02-27) > > > At the very least, it should be obvious in this case that, even though > 8446 gives permission, the server cannot reuse the key share (ML-KEM > ciphertext) if the client uses different public keys. Hence, the text in > 8446 cannot be considered the final word, it may need to be adjusted > according to later requirements. > > An honest or non-buggy server peer could not/would not, as the ciphertext > would not decapsulate by the client. In the current text we say you cannot > reuse encapsulation randomness either. One certainly /can/ send collected > ciphertexts to a peer who cannot decapsulate them > > > > On Sat, Feb 28, 2026, 2:34 PM Scott Fluhrer (sfluhrer) <[email protected]> > wrote: > > Actually, I'm pretty sure a newer RFC can override an older one. > > At the very least, it should be obvious in this case that, even though > 8446 gives permission, the server cannot reuse the key share (ML-KEM > ciphertext) if the client uses different public keys. Hence, the text in > 8446 cannot be considered the final word, it may need to be adjusted > according to later requirements. > > Similarly, this draft could say "clients MUST NOT reuse an ML-KEM public > key, but instead MUST generate a fresh one for each exchange from fresh > randomness". > > On the other hand, the appropriate question is "should it?". That is the > question we should be asking ourselves. > > If you ask my opinion, I would lean towards "yes, it should". Generating > fresh ML-KEM public keys is cheap, and it gives several minor security > benefits (strong PFS if you don't forget to zeroize them when you're done > with this, and making side channel attacks stronger). > > ------------------------------ > *From:* Deirdre Connolly <[email protected]> > *Sent:* Friday, February 27, 2026 4:05 PM > *To:* Ilari Liusvaara <[email protected]> > *Cc:* <[email protected]> <[email protected]> > *Subject:* [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends > 2026-02-27) > > > Also, the text recommending not reusing keys could use RFC 2119 > keywords. > > Only -bis updates to 8446 can change normative requirements here. This was > already discussed and resolved for earlier documents (I'm pretty sure it > was regarding -hybrid). The latest 8446bis draft ( > https://www.ietf.org/archive/id/draft-ietf-tls-rfc8446bis-14.html) says > "Clients and Servers SHOULD NOT reuse a key share for multiple connections" > and that will flow down to hybrid kex and non-hybrid kex equally. > > On Fri, Feb 27, 2026, 8:17 PM Ilari Liusvaara <[email protected]> > wrote: > > On Thu, Feb 12, 2026 at 11:05:22AM -0800, Joseph Salowey wrote: > > This message starts the second Working Group Last Call for the pure > ML-KEM > > document (draft-ietf-tls-mlkem-07). > > > > > > The file can be retrieved from: > > > > https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/ > > > > The diff with the previous WGLC draft (-05) is here: > > > > > > > https://author-tools.ietf.org/iddiff?url1=draft-ietf-tls-mlkem-05&url2=draft-ietf-tls-mlkem-07&difftype=--html > > < > https://author-tools.ietf.org/iddiff?url1=draft-ietf-tls-mlkem-05&url2=draft-ietf-tls-mlkem-06&difftype=--html > > > > > > > > The main focus of this WGLC is to review new text providing more context > > around the use of pure ML-KEM. For those who indicated they wanted this > > text, please let us know if the new text satisfies you and if you support > > publication. This working group last call will end on February 27, 2026. > > Some comments: > > - The document could expand on impact of key reuse. Known impacts > include: > > * Linking connections from the same client, which may be a privacy > risk. > * Making exploiting side channel attacks and implementation flaws > much easier. > > Also, the text recommending not reusing keys could use RFC 2119 > keywords. > > > - Also the document could expand on applicability. Known use cases > include: > > * ML-KEM-512: Constrained systems that nevertheless require security > against quantum adversaries. ML-KEM-512 is among the most efficient > quantum-resistant key exchanges known (at least among the not-too- > exciting ones). > * ML-KEM-1024: Protecting classified data (up to TOP SECRET level) in > United States. ML-KEM-1024 is the only key exchange in the CNSA2 > profile. > > > And some notes, mainly on why I disagree with comments that this draft > should not be published: > > > - There does not seem to be any evidence that ML-KEM is weak. I think > that if ML-KEM gets badly broken, it will be for unforeseeable reasons > (which is a risk for any cryptographic algorithm, including prime- > field ECC). > > This is in contrast to things like RC4, where evidence that it is > bad did exist at the time TLS 1.0 was developed. > > Futhermore, I regard the inclusion of ML-KEM-1024 in CNSA2 as a > serious endorsement. > > I personally think that using hybrids for encryption is worth it, but > it is close a call, and I can see that even relatively small weight > differences may tip the scale the other way. > > > - I do not think ML-DSA FO design is bad. While possibly not optimal, > I think it is very decent. I do not think passing raw entropy is > significant problem, as it seems to matter only with backdoored RNG, > which is something the extra hash in Kyber can not defend against. > > In short, I think the differences between Kyber and ML-KEM are > improvements. > > > - There are already 6 references on the construction, and I did try > giving it some good blows myself, obviously that did nothing to > stand-alone ML-KEM. > > > So I support publication. > > > > > -Ilari > > _______________________________________________ > 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]
