> That actually seems compatible with the view that securing the randomness > should be done by the application and not the algorithm. Note that just > hashing gives a very poor protection against compromised RNGs. If possible > you should include some additional entropy in the hash m = H(m, additional > entropy).
Um okay thanks for the suggestion. > > Simon Josefsson wrote: > >If you deviate, such as by taking the defense-in-depth approach to hash m > > Inserting a NIST-approved DRBG such as Hash_DRBG, HMAC_DRBG between your > potentially compromised entropy source and ML-KEM seems conformant to NIST > specifications. The Katzenpost free software project does not seek the approval of NIST. And quite frankly it is confusing to me to witness other free software projects that go along with NIST guidelines given that they could have been using hybrid post quantum constructions long before NIST said they approved of it. > Cheers, > John Preuß Mattsson > _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
