Random number bug blights FreeBSD

Need non-deterministic randomness

RNGs need to take a peek once in a while at the real world for random numbers. Like packet arrival times, keystrokes, or sampled noise from the sound card. Something! It doesn't make sense to base cryptographic methods on flawed pseudo-random (i.e., non-random, repeating) algorithms.

I wonder why someone doesn't come up with a USB or card to generate pure white noise-derived numbers.

Better random number generators

There was once a suggestion that the best way to generate random numbers was to collect keyboard strokes, add in a little mouse movement, hash a few random files, and add the time since the operating system was booted, in milliseconds to the equation. The problem with the last suggestion is that an attacker can very easily figure out boot time, if your system has a predictable boot-to-on-the-network delay.

A better suggestion would be to collect a database of all machines on the internet that have BSOD'ed and their times. The time, machine name, windows version, login name, last application used, all of that could be used as "salt". The problem would be creating the database, in the first place. That, and eventually running out of disk space as the log fills up with multiple gigabytes of BSOD info.

C64 random, and a thought (yikes!)

The C64 used a pseudo-random number generator on-board the SID chip to produce white noise. I would assume that, given the technology at the time, this sequence would be easy to deduce.

I was thinking along the lines of the digital noise in a computer to provide random numbers. How about a simple USB-based (or even chipset based) RF receiver which uses some unused or used frequency from which to derive randomness. I imagine that the white noise in an unused frequency would generate crypto-sufficient randomness. It might even be enough to continually scan through the FM or AM radio bands. If an FM receiver can fit in my cell phone with all its other gadgetry, I would think that it could fit on a motherboard.

Considering the proliferation of 802.11g these days, maybe even using the output of a spectrum analyzer of the 2.4GHz band could do that (and then somehow avoiding the inevitable privacy concerns with active intercepting WiFi, and the potential hacks to actually listen in.)

For the scanning idea, maybe feeding the input into a state machine which would dictate which direction the scan would move: up, down, up by x, down by x, stay, etc.

And what about that idea of a sound card sample? Imagine a microphone on a sound card in a server room or data center. PLENTY of noise in there from fans, air conditioning, and the like.

Really Random

I proposed this in 1970s.

Include a zener diode & ADC.

Zener diodes are widely used as whitenoise generators.

Effective method.

My favoure method of generating random numbers is through the use of the mouse

Give the user an area 500*500 pixels and have them move the mouse around whilst you collect the co-ords of the mouse movement. Do this for about 30 seconds, or until you have enough data and there you go, random numbers.

Ed

@mage

but that's a hardware RNG - i thought the problem was that whilst we could fairly easily do it with hardware, it's virtually impossible in software.

also: didn't one of the old pentium chips have a hardware RND built in, seeded by temerature at any given time? i could be high on thermal paste again though.

Hardware RNG

Isn't there a device out there that samples atmospheric background radiation and uses that as a random number seed? Or something?

I probably could have Googled it in the time it took to write this comment, you know.

FreeBSD PRNG

A lot have commented here on user-generated randomness. FreeBSD has for a long time had an 'entropy pool' which is 'stirred' but a number of IRQs. So things like disk controllers, and network controllers provide a fairly good source of randomness to help stir things up a bit.

-Matt

Can't you just...

...use one pseudo-RNG to seed another? Or use one RNG to choose when to arbitrarily read least significant digits of a running clock, then use this to seed another RNG? Surely after a couple of levels of this it'd be pretty random?

A bug in GNU tar is a BSD problem first and foremost *how*?

So GNU tar had a security flaw. Great. So why is this being reported as news for FreeBSD? On FreeBSD, GNU tar is a niche application, as many of the people there prefer to use tools that anyone can convert to proprietary, rather than ones with restrictive licenses that prevent that, and most, if not all of the rest, prefer tools with minimal code bloat; gnu tar's --help option *alone* could make the program too bloated for the average BSDer's taste. However, the fact that the FSF have extended their tar program to the point where it actually *supports* all of the options that its help option indicates it can handle basically puts it in the 'right out' category for every BSDer that I have personally talked to about GNU tar.

Single-line fix

The patch was a trivial single-line fix. Looks like some developer made a silly mistake.