From: Seth Kurtzberg Date: 2003-02-28T01:24:35+09:00 Subject: Re: Objectify the mersenne twister in 1.8? Booker, Are you saying that the thermally generated random numbers on the P4 are not truly random? On Thursday 27 February 2003 09:20 am, bbense+comp.lang.ruby.Feb.27.03@telemark.slac.stanford.edu wrote: > -----BEGIN PGP SIGNED MESSAGE----- > > In article <20030226221756.GC23049@student.ei.uni-stuttgart.de>, > > Mauricio Fern�ndez wrote: > >On Thu, Feb 27, 2003 at 05:36:36AM +0900, gabriele renzi wrote: > >> il Wed, 26 Feb 2003 14:25:12 +0000 (UTC), > >> ha > >> > >> scritto:: > >> >_ As a side note, it's an open question whether there is > >> >ANY prng that is secure for cryptography. All you can do > >> >is show that a given prng is not suitable for cryptography. > >> >There is some very interesting work happening in this > >> >area based on the Yarrow paper by Bruce Schneier > >> >and John Kelsey. The EGADS system provided by > >> > > >> >http://www.securesoftware.com/auditing_tools_download.htm > >> > >> thanks for the hint! > >> > >> Acually I think having OS-level entropy gathering, and thus getting > >> ability to provide good random numbers is a must for crypto-level > >> randomness . > > - - Well, any system that doesn't is probably not good enough for > crypto, but you can do these things and still get it wrong. > > >> Freebsd 5.0 (maybe OpenBSD too?) and linux >> here> support yarrow for random, and they could even use hardware > >> PRNG devices, that's why I'd like to exploit this features, even if > >> missing some portability. > > > >Is reading /dev/random (under Linux) enough to assure the random numbers > >are cryptographically secure? > > - - There's a problem with that sentence > > "random numbers are cryptographically secure" > > - - The only truly cryptographically secure random number > generator is a gieger counter on a serial port and even then you have > to be careful with the implementation to get it right. > > The real question to ask is > > "Is /dev/random good enough?" > > and if they are using entrophy pools and something Yarrow > based, it's as good as anything that's currently publically > available. It's certainly better than the random number > generation in most currently deployed ssh implementations > and many other pieces of crypto software. > > > The random number generator gathers environmental noise from > > device drivers and other sources into an entropy pool. The generator > > also keeps an estimate of the number of bit of the noise in the > > entropy pool. From this entropy pool random numbers are created. > > > > When read, the /dev/random device will only return random bytes > > within the estimated number of bits of noise in the entropy pool. > > /dev/random should be suitable for uses that need very high > > quality randomness such as one-time pad or key generation. > > - - I would not use it for a one-time pad. I think it's fine for > key generation. > > > When the entropy pool is empty, reads to /dev/random will block > > until additional environmental noise is gathered. > > > >> Oh, and someone feels that Intel saying they put a "pure RNG" in their > >> cpu is hype? ;) > > > >If they got something like the Pentium division bug to bite randomly > >(by quantum effects or the like) it'd do the trick, wouldn't it? > >The chips run so hot it must be easy to gather some entropy there... > > - - Depends on what they did. A really small gieger counter would > be ideal, I'm sure there are things you could do to get > randomness from some quantum effects. I have no ideal what > Intel has done though. > > - - Booker C. Bense > > -----BEGIN PGP SIGNATURE----- > Version: 2.6.2 > > iQCVAwUBPl40EWTWTAjn5N/lAQGUkwP+KtD2hu90yLmPKNPDZ+JSL4iBn2zhYgfx > 4QCb86M08EvfgB/onavcHy/2eKdtxbVJFAgR+rOt9qPZzkuPj7AyvirJGNhpqruQ > lZUbLUf//TRmxJS0SK79uxl1qhuxg9Qodc33pCdy1WHn2KRdw2/xvK4s7fCMLYAX > Lt5rgAF0trc= > =9Cwd > -----END PGP SIGNATURE----- -- Seth Kurtzberg M. I. S. Corp. 480-661-1849 seth@cql.com