> You might get a bit less pushback by just writing a proper draft, explaining things properly and writing proper security considerations.
I've been aligning with -hybrid-design and -ecdhe-mlkem, thanks On Sun, Mar 1, 2026, 6:33 PM Muhammad Usama Sardar < [email protected]> wrote: > On 01.03.26 18:18, Scott Fluhrer (sfluhrer) wrote: > > 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. > > FWIW just having a statement -- without proper justification -- in the > draft is insufficient. Even worse, security considerations (Section 5.3) is > talking about randomness, which is not even explained in the whole design. > I believe Section 3 MUST explain it before the security considerations can > talk about it. > > > 2 cents more: consider adding a diagram in Section 3 showing: > > 1. client does keygen resulting in (encaps_key, decaps_key) > 2. client sends over encaps_key to the server > 3. server does encaps on encaps_key resulting in ciphertext and > shared_key > 4. server sends over ciphertext to client > 5. client does decaps on decaps_key to get the same shared_key > > Then show a version with randomness, and explain in Section 3. > > > Then give proper reasoning for the statement in section 5.3 that Scott is > mentioning. > > > You *might* get a bit less pushback by just writing a *proper* draft, > explaining things properly and writing *proper* security considerations. > > > Thanks for consideration. > > > Sincerely, > > -Usama >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
