Peter Gutmann wrote: > Christian Huitema <huit...@huitema.net> writes: > >>On 7/25/2017 4:57 PM, Peter Gutmann wrote: >>> Are we talking about the same thing here? >> >>Not sure. > > OK, I'd say we are :-). This isn't about which PRNG or randomness source to > use but the need for a separation between PRNG-for-secret-values and PRNG-for- > public-values. In particular you don't want to feed large amounts of output > from your PRNG-for-secret-values to an attacker for analysis via nonces, > client/server randoms, and other things, in case they can use that to attack > your PRNG state. > > The prime example of this is the EC-DRBG fiasco, which relied on the attacker > seeing the client/server random just before the same PRNG was used to generate > the master secret. If the client/server random had come from PRNG instance #1 > and the master secret from PRNG instance #2, it would have been... well, still > a bad PRNG, but not as catastrophic a failure. > > So the advice was to seed the public-PRNG from the private-PRNG and use the > public-PRNG for nonces, sequence numbers, and so on, and the private-PRNG for > encryption keys and the like.
Whenever you're using "some" CPRNG as a black box, you should very probably take 4x to 16x of CPRNG native output size and run it through a cryptgraphic compression function (such as a secure hash or PRF) to produce 1x output size (a) as a safety precaution and (b) to obtain reasonable entropy. Just look at the Intel RDRAND fiasko. It isn't just a bad design, it is a clearly documented bad design. They openly admit that they're artificially inflating the output by factor of 2x, i.e. that an output of 256 bits is based on entropy of _at_best_ 128 bits. Since you also have no idea whether and how the internal hardware design behind Intel RDRAND is backdoored, you should not be using any of its output without an at least 10x cryptographic compression in any case. -Martin _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
