True Random Number Generator
in [Cryptography]
|
From: unruh on 21 Jan 2010 12:57 On 2010-01-21, jmorton123 <jmorton123(a)rock.com> wrote: > The clock time used is 1000 ticks per second. If there is a bias it > must be incrediblly small because a computer cannont fuction with any > significant clock bias nor can an operating system. Furthermore, any But that is not relevant. The computer for example could visit the mouse only once every 1/10 second, and then the quantization would be 1/10 sec. And people's habits are predictable-- they press the button regularly ot randomly, and move the mouse with a set velocity. All those introduce huge biases into the "random numbers" > insignifiant bias which you indicate that may be present is completely > washed out by the randomness of the click moments entered by the They are NOT random. > user. Lastly, you need to ask youself: can these random numbers be > reproduced? I think not. Thank you. Much of the statistics can be reproduced, yes. People are in fact very predictable. It is precisely such naive statements ( my mouse clicks seem unpredictable to me, so they must be) that indicates that noone should trust anything you do in the field. >
From: unruh on 21 Jan 2010 12:58 On 2010-01-21, Noob <root(a)127.0.0.1> wrote: > Tom St Denis wrote: > >> You do realize the most modern OSes trap interrupts and events to >> harvest entropy from right? Even Windows has a CSP function >> CryptGenRandom() [or something like that] for reading RNG output. In >> most *NIX OSes you'd use /dev/urandom. > > Or /dev/random depending on the situation. I would say, never use /dev/random. There are virtually no situations where it buys you anything, and lots where it can totally screw you. > > http://en.wikipedia.org/wiki//dev/random
From: rossum on 21 Jan 2010 13:46 On Wed, 20 Jan 2010 08:50:30 -0800 (PST), jmorton123 <jmorton123(a)rock.com> wrote: >When you start the program it saves the system time. Each time you >click the mouse or press the enter key, the time is once again >stored. Then the start time is subtracted from the mouse click time. >Then this difference is used to access an array that contains the >binary numbers from 0 - 255. And if the attacker has a hidden microphone in your office or is bouncing a laser off the office windows they will be able to hear, and time, mouse clicks and key strokes. You need a source of randomness that can more easily be protected from an attacker. Your idea may possibly be of use in a Fortuna-style RNG as one among many entropy sources. Fortuna is designed to be usable with low-quality entropy sources. rossum
From: Gordon Burditt on 21 Jan 2010 15:21 >The clock time used is 1000 ticks per second. If there is a bias it >must be incrediblly small because a computer cannont fuction with any >significant clock bias nor can an operating system. I don't agree. I've seen a computer with time-of-day clocks off by a rather large factor, so it lost about 58 minutes an hour (although this wasn't the CPU clock, so it didn't run 30 times too slow). The user of this computer hadn't noticed. I only noticed because the time stamp on a diagnostic report for an unrelated problem (dirty floppy drive heads) had the wrong year. Some users didn't even bother to set the clock in the first place. Example: Suppose you start timing the mouse click by using a finer- resolution clock, such as the Pentium Time Stamp Counter. This clock increments at a much faster speed, say, 1GHz. Or perhaps you go the expensive route using an atomic clock calibrated to national standards. (No, I don't mean you sync to an atomic clock once a day, I mean you *buy* one and use it, in addition to careful sync'ing.) Mouse clicks and keystrokes on some computers are transmitted through an 8052 (or similar) keyboard coprocessor, and the event travels on a serial line clocked at about 30kHz to 50kHz (and it takes about 10 bit times or so to transmit an event). The arrival times of mouse clicks are now limited to about 3 - 5 kHz, and you lost most of the finer-resolution randomness. It gets worse if the clock you're using and the keyboard serial clock are divided down from the same master clock. There are hardware components and timing in the mouse driver that limit how close mouse clicks can be to each other (two clicks a microsecond apart are switch bounce), and how far apart they can be from each other (what's the difference between two clicks and one double click?) Browsers may be awoken from waiting for input based on a task scheduler, which may be using scheduling time quanta that are much larger than 1 millisecond. Even Windows does task scheduling. This information is being sent over a network. There are possibilities here for bias to be introduced that's different for each user of the web site generating the numbers, coming from the sender's ISP, the web site's ISP, and every router in between. Suppose every packet was held up by an ISP doing bandwidth throttling (which you may not even know about!) to collect a bunch of packets from you and release them all at once on a multiple of one second. You'd lose a lot of randomness, but probably not enough throughput to notice, and this might be happening to only *SOME* users of the web site, so the fact that someone else did a complex certification of the random numbers generated by the site doesn't mean that's what YOU get. It's possible that network traffic variability can under some circumstances introduce *more* randomness, but it's not something the user or site owner can control or predict. It's also possible that the people at No Such Agency (or perhaps a botnet operator) could have your connection to this web site run through their router just to spoil the randomness you get from the site, and you'd never know about it. >Furthermore, any >insignifiant bias which you indicate that may be present is completely >washed out by the randomness of the click moments entered by the >user. Have you ever watched a TV show called "The Amazing Race"? Teams of people race around the world. It seems that whenever they have to get on an airplane, teams that were "close together" (due to small differences related to their skill in navigating or completing odd tasks that are part of the race) are now "exactly together" or several hours apart depending on the airline schedule. There are a lot of things that tend to sync up signals in computers. It tends to work the other way: things that sync up signals wash out much if not all of the randomness entered by the user, in much the same way that a big (automobile) traffic jam syncs the commuters. >Lastly, you need to ask youself: can these random numbers be >reproduced? I think not. Thank you. Probably not exactly. But it might be a lot easier than it seems. If you want proof, use the random numbers generated by such a site to gamble with real money at high stakes, announce how you do it, and someone will figure out how to break it well enough to win a lot of money.
From: amzoti on 21 Jan 2010 23:31
On Jan 20, 10:50 am, "Dave -Turner" <ad...(a)127.0.0.1> wrote: > i take it you haven't actually tested it against Diehard (etc) :) Try: http://www.iro.umontreal.ca/~simardr/testu01/tu01.html |