On 7/8/2026 11:53 AM, Dang, Quynh H. (Fed) wrote:
Hi Christian,
If one does not trust the RBG they use, they should add that hash to all
outputs of the RBG to protect their system and in this case the hash function
is considered a part of a new RBG which has this outer hash on top of the RBG
they don't trust.
Protecting the KEM alone and let the rest of the system broken would not be the
best I think.
Or, don't use that RBG, use the one you trust or develop your own RBG.
Yes, this is a generic issue, not an issue specifically related to
ML-KEM. On the other hand, pointing that RBG trust in the ML-KEM
document and suggesting potential mitigations would surely help cool
down the debate. Maybe add a reference to appendix C.1 of RFC 8446.
Maybe, as Nick Sullivan wrote, add a mention of RFC 8937 as a potential
mitigation for the concerns expressed in this debate, whatever their merits.
Looking at the generic issue, I would have loved to find a more recent
reference than RFC 4086, Randomness Requirements for Security.
-- Christian Huitema
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
