RE: Trivial OPT generation method?
hi, > You probably know this if you use it, but > /dev/random is the most > "random" one, as it always uses system entropy, > rather than falling > back on an algorithm to generate more bits than are > available in > the pool. Its always better to choose an algorithm because it has *known* properties-such as period of the generator,whether it passes the die hard test and so on.Once we know it by using a one way function we can say with some confidence that the generated output has good random properties. Regards Sarath. Using the output to seed MD5 for the next block exposes that part of the state of the RNG. Might be better to use half the MD5 output as seed for the next block, and the other half as output data. * Your RNG takes input from an attackable source. I can significantly reduce the entropy of your system by placing a transmitter near your machine (even if -J Since you only need 8 bytes of random seed > (and if you > don't need to generate many OTPs at a time...) it > might be worth > using it instead. > Can't help you on the entropy quality though. > > -- > Vincent Penquerc'h > __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/
Re: Trivial OPT generation method?
At 10:55 AM 2/26/03 -0500, you wrote: He only needs a pseudo-random seed, though. The real random comes from the radio white-noise. [...] After that, you actually want to feed the entropy you're getting from the radio tuner *into* /dev/[u]random. He may wish to pre-process the raw bits to remove any potential bias they may have. Here's what I do for random bits: http://www.etoan.com/random-number-generation/index.html Cheers, Dan
Re: Trivial OPT generation method?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Feb 26, 2003 at 03:37:10PM -, Vincent Penquerc'h wrote: > > 1) Get 8 bytes from /dev/urandom. (Just for sure.) Put them into the > You probably know this if you use it, but /dev/random is the most > "random" one, as it always uses system entropy, rather than falling > back on an algorithm to generate more bits than are available in > the pool. He only needs a pseudo-random seed, though. The real random comes from the radio white-noise. I'd say it'd be better to not waste the system's random bytes on this at all, but just to gen your own pseudo-random bytes using /dev/urandom's out-of-entropy function from your OS of choice (audit, I guess, but it's mostly just to blank the memory of anything useful). After that, you actually want to feed the entropy you're getting from the radio tuner *into* /dev/[u]random. - -- gabriel rosenkoetter [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (NetBSD) iD8DBQE+XONt9ehacAz5CRoRAl9yAJ40RRX2GqexHdYa76owwab8sjd+bQCfRn6s pv5PaYjQB4fkCE8QefC+u8g= =3OKq -END PGP SIGNATURE-
RE: Trivial OPT generation method?
> 1) Get 8 bytes from /dev/urandom. (Just for sure.) Put them into the You probably know this if you use it, but /dev/random is the most "random" one, as it always uses system entropy, rather than falling back on an algorithm to generate more bits than are available in the pool. Since you only need 8 bytes of random seed (and if you don't need to generate many OTPs at a time...) it might be worth using it instead. Can't help you on the entropy quality though. -- Vincent Penquerc'h
Re: Trivial OPT generation method?
> There is no weakness in it that I could come up with (presuming the audio > input is sufficiently random, which in case of badly tuned station it > seems to be; white noise generator would be better, though). Sounds good to me. you should certainly get 16 good bytes from 128, and while assuming a higher entropy would be faster, it is better to be conservative if you can afford it.
