On Tue, 2013-10-22 at 00:07 -0700, Andy Isaacson wrote:

On Fri, Oct 18, 2013 at 11:42:21AM -0400, Sandy Harris wrote:

...

On Thu, Oct 17, 2013 at 12:56 PM, grarpamp wrote:

...

Problem is, apparently no one is solving it, so round and round it goes...

...

Now if someone would just sell a completely open discrete logic serial port hw entropy source for under $50... that would end a lot of the talk. Even with a more costly radiation source rather than other phenomena you'd still likely make good profit ...

If you have an audio device free or can add one and are using Linux, I'd say Turbid is the obvious solution: http://www.av8n.com/turbid/paper/turbid.htm

Open source, available for over a decade, well thought out and well documented. It even has a proof, using only some quite mild assumptions, that it gives almost perfect entropy in the output. What's not to like?

It's super frustrating that Turbid assumes you are going to reverse-engineer the amplifier stage of your sound card in order to set some difficult-to-understand parameters which apparently can completely break it's ability to extract entropy if set incorrectly. (See the installation instructions in section 12 of the paper linked above.)

It would be much better for it to have a default set of parameters (or an autotuned parameter engine) that have a very high likelihood of giving acceptable results upon "apt-get install turbid" on some arbitrary hardware.

I mean, seriously. The Turbid authors appear to assume that every person who installs Turbid is going to build a custom Y-audio cable and put a voltmeter (set to the correct mode of course!) on the outputs of their sound card. WTF?

It's fine if conservative, default settings result in Turbid getting only 100 bits of entropy per second rather than 100 Kbit/sec. Mix it into /dev/urandom and call it a day.

-andy

A while ago, a friend and I bought a smoke detector and a webcam, hacked them together, and built this: http://www.inventgeek.com/Projects/AlphaRad/OverView.aspx It actually works; when you view the webcam you can see the little points of light where an alpha particle hits the sensor. However, there wasn't really any software to support it as an RNG, so it's just sitting around. Is it possible to make an entropy source out of something like that? If so, it was a really simple (less than two hours IIRC) build, and it cost about $40. -- Sent from Ubuntu

Yeah. You just need a noisy channel. Radiation is really overkill. You probably could use quantum tunneling on a silicon chip to produce a reliably random noise source small enough for a an port. The issue, however becomes the computer itself. It isn't hard to muck up a serial port so that you wouldn't even know you aren't getting the true data. On Tuesday, October 22, 2013, Cathal Garvey wrote:

If the particle flux is high enough for it to be usefully rich in random data, you could just hash the image output and use the hash outputs as an entropy source.

However, you'd want to be careful that you: A) Use a good hash, and perhaps double-hash to be paranoid B) Try to measure and correct/alarm for the flux of your radioisotope as it decays, though depending on the isotope perhaps this isn't important.

Thinking all the thoughts on this channel through, I'm beginning to wonder if the easiest answer isn't just a vibrating surface covered in sand with a camera pointed at it, hashing the output. :)

On 22/10/13 16:15, Ted Smith wrote:

...

On Tue, 2013-10-22 at 00:07 -0700, Andy Isaacson wrote:

...

On Fri, Oct 18, 2013 at 11:42:21AM -0400, Sandy Harris wrote:

...

On Thu, Oct 17, 2013 at 12:56 PM, grarpamp javascript:;> wrote:

...

Problem is, apparently no one is solving it, so round and round it goes...

...

Now if someone would just sell a completely open discrete logic serial port hw entropy source for under $50... that would end a lot of the talk. Even with a more costly radiation source rather than other phenomena you'd still likely make good profit ...

If you have an audio device free or can add one and are using Linux, I'd say Turbid is the obvious solution: http://www.av8n.com/turbid/paper/turbid.htm

Open source, available for over a decade, well thought out and well documented. It even has a proof, using only some quite mild assumptions, that it gives almost perfect entropy in the output. What's not to like?

It's super frustrating that Turbid assumes you are going to reverse-engineer the amplifier stage of your sound card in order to set some difficult-to-understand parameters which apparently can completely break it's ability to extract entropy if set incorrectly. (See the installation instructions in section 12 of the paper linked above.)

It would be much better for it to have a default set of parameters (or an autotuned parameter engine) that have a very high likelihood of giving acceptable results upon "apt-get install turbid" on some arbitrary hardware.

I mean, seriously. The Turbid authors appear to assume that every person who installs Turbid is going to build a custom Y-audio cable and put a voltmeter (set to the correct mode of course!) on the outputs of their sound card. WTF?

It's fine if conservative, default settings result in Turbid getting only 100 bits of entropy per second rather than 100 Kbit/sec. Mix it into /dev/urandom and call it a day.

-andy

A while ago, a friend and I bought a smoke detector and a webcam, hacked them together, and built this: http://www.inventgeek.com/Projects/AlphaRad/OverView.aspx

It actually works; when you view the webcam you can see the little points of light where an alpha particle hits the sensor.

However, there wasn't really any software to support it as an RNG, so it's just sitting around.

Is it possible to make an entropy source out of something like that? If so, it was a really simple (less than two hours IIRC) build, and it cost about $40.

-- Kelly John Rose Toronto, ON Phone: +1 647 638-4104 Twitter: @kjrose Skype: kjrose.pr Gtalk: iam@kjro.se MSN: msn@kjro.se Document contents are confidential between original recipients and sender.

On Tue, Oct 22, 2013 at 06:47:40PM +0200, Krisztián Pintér wrote:

once you have your data stream in memory, you just need to use some whitening. that is the easy part. virtually every cryptographic primitive can be turned into a secure whitener.

for example, i have implemented a small toy/tool to generate random data from the noise of the sound card. it is pretty much the same thing, you just replace the line-in with your data source, and the whitening part is done. it is for windows only. check it out here:

https://github.com/krisztianpinter/rnd_wavein

It seems that rnd_wavein uses a small window (you document 256 samples as the default). One common silent-failure mode of video capture interfaces is to intermittently provide the same frame (around 1 MiB of data) twice! If your whitener doesn't chain blocks and you use the output directly as random data (worst case, as an OTP) then a long-term repeat like that is completely catastrophic, giving you a modern reprise of the Venona break: http://www.nsa.gov/about/_files/cryptologic_heritage/publications/coldwar/ve... If you do chain, it's merely reducing the entropy of the stream significantly. Also it's entirely possible that an attacker can influence the behavior of the system; depending on your threat model either through direct physical access or by causing CPU starvation through a network or algorithmic DoS to trigger misbehavior in the driver. It would be much better to implement a multi-stage entropy pool design with catastrophic mixing, such as Schneier et al's Fortuna: https://en.wikipedia.org/wiki/Fortuna_%28PRNG%29

disclaimer: the old rule "don't roll your own crypto" is still in effect.

Indeed. -andy

On 2013-10-23 04:27, Andy Isaacson wrote:

It seems that rnd_wavein uses a small window (you document 256 samples as the default). One common silent-failure mode of video capture interfaces is to intermittently provide the same frame (around 1 MiB of data) twice!

If your whitener doesn't chain blocks and you use the output directly as random data (worst case, as an OTP)

All whiteners chain. If they do not, it is a bug.

On Wed, Oct 23, 2013 at 09:01:18AM -0400, Sandy Harris wrote:

...

It's super frustrating that Turbid assumes you are going to reverse-engineer the amplifier stage of your sound card in order to set some difficult-to-understand parameters which apparently can completely break it's ability to extract entropy if set incorrectly. (See the installation instructions in section 12 of the paper linked above.)

It would be much better for it to have a default set of parameters ...

There is configuration info for some common sound devices.

Six discrete (ISA and PCI) sound cards manufactured before 2008, plus generic "intel-hda" and "usbaudio" profiles. That might cover as much as 20% of systems shipped in 2013. Also, AFAICS the .ctl files do not contain the Q, R, B, and K values computed in sections 12.1 - 12.8. There are sample values for a few (circa 2005) devices in table 4.

...

I mean, seriously. The Turbid authors appear to assume that every person who installs Turbid is going to build a custom Y-audio cable and put a voltmeter (set to the correct mode of course!) on the outputs of their sound card. WTF?

Only people with a device for which a configuration file does not already exist. If you have to do this, you can send your file to the Turbid maintainer so others can use it without having to do the measurements themselves.

The turbid.tgz download is unversioned and unsigned. Something between 60% and 90% of PCs sold today are not covered, since only one device that's included is still on the market (intel-hda).

Of course, then there is a trust issue. The maintainer may not have the device in question, so he cannot verify. If you want to verify, you are back to building a cable. Without verification, it looks as though someone could subvert Turbid for a device by submitting a suitably bogus parameter file.

...

It's fine if conservative, default settings result in Turbid getting only 100 bits of entropy per second rather than 100 Kbit/sec. Mix it into /dev/urandom and call it a day.

I'd also like to see a default parameter file, guaranteed to give some entropy on a lowest common denominator device. I'm not sure if that is possible.

The Turbid paper seems focused on generating a few KiB/sec of physical randomness, continuously. The actual problem facing users today is getting 100 bits of randomness, *ever*, to seed urandom. This seems like a classic example of engineering building a system that's far beyond spec for the problem it's actually supposed to solve, and incapable of adressing the actual problem due to overengineered complexity. Turbid fails the first rule: build systems for people to actually use. -andy

2013/10/18 James A. Donald

You can, however, be sure a microphone input is a reliable source of entropy, since fake entropy would interfere with its microphone function.

This is a syntatic non sequitur. Why would fake entropy interfere with a microphone's function? How is the microphone guaranteed to have "its microphone function"? Is a microphone input just the microphone's jack or an actual soundwave-modulated-magnetic-power-factor? In either case it's also a semantic non sequitor. If someone plays a darn loud sine wave in the serverroom you can be sure the microphone will replicate it. It'd be doable to make any microphone always output it's maximum value, through a plenty of means. The sad thing is that it's sound, so it might even be doable at distance! (scenario: people breaking into a running-but-physically-controlled server through manipulation of it's random numbers) I think an internal radioactive source such as a smoke alarm makes great sense. Be wary to isolate it very well to prevent outside interference. If it just goes to MAXINT if someone holds his cube of madam curie next to the server's case it'd be a shame. @Jim Bell: wouldn't such a ring oscillator aggregate be subject to patterns? If you have something that can create more out of fewer pieces of randomness, isn't there plenty bad-randomness-sources to go on? @Jon Callas: How is this random generator affected by CPU Interrupts? It seems to be a feature added for "more randomness", but given interrupts are far from guaranteed (especially in problematic systems) you cannot depend upon them. Especially because random numbers are harder on smaller systems I'm not sure I'd call this solution elegant. I believe stir-back is not always possible but a very strong feature. If you can always stir-back, can't you always generate something fairly random by simulating a x-times-stir-back? If you can't, how can you trust your stir-backs to be spaced enough for your -x-times-stir-back to not happen anyway? Lastly I feel your way of dealing with the pool-distiller model is finicky. If you hash a pool your hash will be able to fold onto itself very often and bits of entropy in different places can have different effects. You're placing an unusual amount of faith in your hash function on it being perfect. Diffusion with a partially known sourcetext is very, very murky business. And with predictable data going into your pool you're essentially creating a probably partially known plaintext. That's complex, and that'll do you good, but it is not the kind of nice randomness you'd go for. A suggestion I'd like to make is a laser & light strength measurement unit. Neatly self contained and accurate enough it can measure the bending of spacetime itself. I suppose anything even nearly that accurate will measure it's direct environment's noise so well it all doesn't matter anyway. Something like Delta(cpu_magneticness_mid_cycle) would do wonders. Anything dependent on the activity of the computer itself gives problems with people manipulating what the computer is doing. More rough it could measure minute changes in the movement and heat of flowing air. wow this became a lot longer than I expected.

2013/10/18 James A. Donald mailto:jamesd@echeque.com>

You can, however, be sure a microphone input is a reliable source of entropy, since fake entropy would interfere with its microphone function.

On 2013-10-22 08:43, Lodewijk andré de la porte wrote:

This is a syntatic non sequitur. Why would fake entropy interfere with a microphone's function?

If your device can hear sound, it will hear thermal noise. You cannot build a device that can hear sound, and not hear thermal noise.

In either case it's also a semantic non sequitor. If someone plays a darn loud sine wave in the serverroom you can be sure the microphone will replicate it.

Will replicate it imperfectly. Some of the imperfections being thermal noise.