| |||||||||||||
True randomnessTrue randomnessPosted Mar 31, 2012 2:18 UTC (Sat) by engla (guest, #47454)In reply to: True randomness by man_ls Parent article: Russell: Sources of Randomness for Userspace
Why not use an encrypted stream with a random key?
Read a relatively short key off /dev/random, then generate a stream of bytes by encrypting /dev/zero using that key. With AES-NI you get more than 300 MB/s using AES-256 and this *should* be good enough.
(Log in to post comments)
True randomness Posted Mar 31, 2012 8:58 UTC (Sat) by man_ls (subscriber, #15091) [Link] Because you would be leaking key material like crazy. Even if you used a correct stream mode you would transform the business of running a PRNG into a known plaintext problem, which is about the easiest in cryptography.
True randomness Posted Mar 31, 2012 13:15 UTC (Sat) by intgr (subscriber, #39733) [Link]
> Because you would be leaking key material like crazy.
> you would transform the business of running a PRNG into a known plaintext > problem, which is about the easiest in cryptography.
Sorry, but this is nonsense. In practice, every cryptographic protocol transmits some known (e.g. predictable) plaintext. If a cipher is vulnerable to a known plaintext attack at all, the cipher is simply broken.
In fact, a stream cipher (or a block cipher in CTR mode) in its most basic form, *is* a PRNG -- put a key in and it spits out a pseudorandom keystream. Most cryptographic PRNG systems (Yarrow, Fortuna, CryptGenRandom) do use a cipher this way to generate the output stream -- because ciphers have well-known security properties.
True randomness Posted Mar 31, 2012 14:29 UTC (Sat) by man_ls (subscriber, #15091) [Link] Sorry about the confusion, I should have refreshed these things before answering. (This goes to show how non-trivial this random number generation business is.) The original suggestion was to just encrypt /dev/zero which had all the faults described above, because it was not using an IV and key material would be leaking. Correct block cipher modes (not "stream modes" as I said) such as CRT use an initialization vector, use the result of one operation to XOR the next value, and use a counter instead of /dev/zero. All these things are done to avoid a plaintext attack.Once you take care of these issues, then you have a cryptographic PRNG system. Even so you have to pick a correct cipher to avoid a plaintext attack. And even with good ciphers apparently there are attacks based on the regularity of the input.
|
|||||||||||||