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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
