| > A few weeks ago I asked for information on using the increasingly
| > prevalent built-in TPM chips in computers (especially laptops) as a
| > random number source. I got some good advice and want to summarize the
| > information for the benefit of others.
|
| Thanks for the useful summary! For the sake of completeness, let me also add
| that RNGs in tamper-proof hardware are potentially rather controversial, since
| there are several known ways to produce output which looks very random to
| anyone who doesn't know some secret, but allows those who do to predict what
| future outputs will be. I believe one straightforward way to do this would be
| to simply use a symmetric encryption function outputting "random" data blocks
|
| r_i=Encrypt(key, r_(i-1))
|
| If you don't know the secret key, the output will look at least somewhat
| random, but if you do, you can use any block to predict all subsequent and
| prior ones. (This topic has been discussed in the literature, and my
| off-the-cuff example may not be particularly strong.)
Your example would, in fact, be as strong as any. It's generally
considered a significant - often disqualifying - fault of a modern
cryptosystem if its output can be distinguished from that of a random
function. Feeding the input back is a common method for testing for
such non-randomness, since the expected cycle length for random
functions can be calculated and many older cryptographic functions
showed weaknesses here.
| I believe it's a fair summary to say that hardware RNG is a neat and useful
| feature, but may be unsuitable for the sufficiently paranoid when it comes in
| a tamper-proof package.
You're damned if you do and damned if you don't. Would you want to use a
hardware RNG that was *not* inside a tamper-proof package - i.e., inside
of a package that allows someone to tamper with it?
A "spiked" RNG of the kind you describe is at least somewhat fixable:
Choose a fixed secret key and encrypt the output of the generator with
the key before using it. Assuming the cryptographic function you use is
good - and in the end you're almost certain to make that assumption
somewhere - the resulting bits can be treated as random. (Note that you
don't ever have to share that key with anyone, nor do you have to fix it
for good.) (And, yes, on a theoretical level, there is only one block's
worth of entropy in such a generator, so it's not so good. Assuming the
same crypto algorithm throughout, one way or another, the best you can
get is the difficulty of a brute-force attack on the smaller of a key or
a block. For repeated uses, an attack on the generator, of course,
may give you access to much more than one key.)
As has been discussed here previously, there are other ways to "spike"
hardware, including an RNG, that are much more insidious. An RNG that
only covers a small fraction of the possible outputs is one possibility.
For example, r_i = Encrypt(key,i mod 2^32) will look quite random unless
you get more than 2^32 samples, but there's a trivial brute-force attack
against the output - which works just as well against the "encrypt before
using" fix.
-- Jerry
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
