[Cryptography] Random numbers only once

Jerry Leichter leichter at lrw.com
Tue Feb 4 20:07:00 EST 2014


On Feb 4, 2014, at 12:12 AM, Watson Ladd wrote:
> As DJB pointed out on another listhost, one only needs 256 random bits
> once, and can then use a PRF to generate an indefinite number forever.
Well, it's nice to know I'm in such illustrious company.  I made the same argument here a couple of weeks back.

> Why does /dev/random not do this and so avoid blocking after startup?
> It wouldn't be that hard to write to a defined block of a disk image
> these 32 random bytes.
Well, keep in mind that it's not just a fixed 32 random bytes.  You have to updated either the seed bytes, or some kind of counter or other varying input to the PRF, or you'll generate the same sequence of "random" values every time you boot.

There are a couple of problems with extending "forever" to encompass saving the values to disk:

1.  A saved disk can be silently copied.  No matter what kinds of protection your OS provides, while the disk is just sitting there with the power down, it can't control access, or even know about accesses.
2.  The same issue as 1 except concerning backup copies.
3.  If an attacker manages to keep you from writing a new seed or counter value, you'll generate the same "random" numbers the next time around.

Note that encrypting the disk image *seems* to block 1 and 2, but leaves you with the problem of getting the disk key to the machine securely at boot.  This is pretty much the problem you started with:  How to have a value that the machine can get to at boot, but which no one else can get to even while the machine is shut down.  Hardware solutions to this problem do exist; then again, hardware random number generators exist.  In fact, modern chipsets supply one or both.  The question comes down to what you want to assume is available - and what you trust.  Given the extremely high value an attacker could gain by compromising a central element like this, many people have become (understandably) wary of relying on them.

Note that attack 3 is more "active" than 1 or 2, so easier to detect and more difficult to pull off.

There are many details that depend on how you think these machines are actually physically realized and used.  Can you control physical access?  Or perhaps just *detect* that the machine may have been accessed?  That moves problems 1-3 to other domains:  How much you trust your physical access controls, how you recover if you detect that they've been bypassed.  At the other extreme, are you talking about a virtual machine, which may spend much of its time existing as just a disk image on someone else's disk - and is *intended* to be easy to copy?  How do you get each instance it's own seed value?  Again, solutions are possible, but there are many details to get - and keep - right.

Then again, one can say the same of a "true random number generator".

                                                       -- Jerry


> Sincerely,
> Watson Ladd
> _______________________________________________
> The cryptography mailing list
> cryptography at metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography



More information about the cryptography mailing list