On Wed, 13 Feb 2008 20:38:49 -0800 [EMAIL PROTECTED] wrote: > > > ----- Original Message ----- > > From: "Pat Farrell" <[EMAIL PROTECTED]> > > To: > > Subject: Re: Toshiba shows 2Mbps hardware RNG > > Date: Sun, 10 Feb 2008 17:40:19 -0500 > > > > > > Perry E. Metzger wrote: > > > [EMAIL PROTECTED] (Peter Gutmann) writes: > > >> I've always wondered why RNG speed is such a big deal for > > >> anything but a few highly specialised applications. > > > > > > Perhaps it isn't, but any hardware RNG is probably better than > > > none for many apps, and they've managed to put the whole thing in > > > a quite small bit of silicon. The speed is probably icing on the > > > cake. > > > > One of the benefits of speed is that you can use cleanup code to > > control bias. Carl Ellison put some out on his website last century. > > > > > > It is a HUGE win for designing a crypto system to have a really > fast (and good) HW RNG. Being able to generate 10-20,000 AES keys > per second means that you can engineer things that were impossible > to do otherwise. You can generate as many keys as you like, throw > away keys after one time use, treat them as ephemeral authentication > keys (say give a few million or so to a user), etc. Or you could > hand a sender 10 MBytes (less than a minute to generate), which then > can be used to create billions of keys (say using Ueli Maurer's > Bounded Storage Model). The sender could then use each key to > uniquely encrypt (AES CTR) each message of a series of messages or > packets to a receiver (AES key setup is fast). No need for an IV or > worrying about message ordering (each one has a key id), or even the > compromise of a key or two. > > Randomness is the most fundamental underpinning of a crypto system > and having lots of it on demand is really fabulous to have in our > system security design tool box. > Leaving aside whether or not your scenarios make sense, why must this be done via a hardware RNG?
I ran 'openssl speed aes' on a 3.4 Ghz single-core Pentium. On 16-byte blocks with AES-128 -- i.e., running AES in counter mode to generate 128-bit keys -- it ran at about 3.4M encryptions/second. That's more than two orders of magnitude better than you say is needed. Why do I need hardware? Hardware RNGs are great for producing initial seeds. They're also great for producing new randomness to stir into the pot (i.e., via something like Yarrow). But they're lousy for ongoing work because they're relatively low assurance. As others have noted, software has a big advantage: it's deterministic. Once you know its working, you have much higher assurance that it will continue to work the same way. (Aside: I know quite a bit about the problem of certifying complex software. A cryptographically strong PRNG doesn't fall into that category if you have confidence in the algorithm.) Remember the Clipper chip? According to Dorothy Denning, the escrowed keys -- that is, the entire security of the basic scheme -- was generated by several applications of the Skipjack, the underlying block cipher -- see http://catless.ncl.ac.uk/Risks/14.52.html#subj1 for details. (Note: that statement was later disavowed. I'm not sure I believe the disavowal; it looked secure to me.) --Steve Bellovin, http://www.cs.columbia.edu/~smb --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
