[146802] in cryptography@c2.net mail archive
Re: [Cryptography] [cryptography] Random number generation
daemon@ATHENA.MIT.EDU (John Kelsey)
Sun Sep 8 02:52:36 2013
X-Original-To: cryptography@metzdowd.com
In-Reply-To: <20130907202632.GJ29404@leitl.org>
From: John Kelsey <crypto.jmk@gmail.com>
Date: Sat, 7 Sep 2013 23:06:44 -0400
To: Eugen Leitl <eugen@leitl.org>
Cc: Cryptography List <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
There are basically two ways your RNG can be cooked:
a. It generates predictable values. Any good cryptographic PRNG will do this if seeded by an attacker. Any crypto PRNG seeded with too little entropy can also do this.
b. It leaks its internal state in its output in some encrypted way. Basically any cryptographic processing of the PRNG output is likely to clobber this.
The only fix for (a) is to get enough entropy in your PRNG before generating outputs. I suspect Intel's RNG and most other hardware RNGs are extremely likely to be better than any other source of entropy you can get on your computer, but you don't have to trust them 100%. Instead, do whatever OS level collection you can, combine that with 256 bits from the Intel RNG, and throw in anything else likely to help--ethernet address, IP address, timestamp, anything you can get from the local network, etc. Hash that all and feed it into a strong cryptographic PRNG--something like CTR-DRBG or HMAC-DRBG from SP 800-90. If you do that, you will have guarded against both (a) and (b).
--John
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
