Curious RNG stalemate [was: use of cpunks]
On Thu, Oct 17, 2013 at 2:29 AM, Eugen Leitl <eugen@leitl.org> wrote:
If we had good PRNGs everywhere, with lots of trustable physical entropy stirred in then nobody would care about talking about these. It would be boring, since a solved problem.
Now show me a cryptographic quality PRNG with a few MBytes of internal state. Best, a whole robust family of them. See? That's some quality trolling, right there.
Problem is, apparently no one is solving it, so round and round it goes... physical entropy, rdrand, reboot state, prng code. I'd guess that with good sources, today's prng code is sufficiently strong and at least some unix systems do save state across reboot. 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 in quantity from China at that price. Sell other/cheaper/slower phenomena for a little less and make even more profit. Seal some up in a pretty wrapper and call it the corporate version for $1500.
On Thu, Oct 17, 2013 at 12:56:01PM -0400, grarpamp wrote:
Problem is, apparently no one is solving it, so round and round it goes... physical entropy, rdrand, reboot state, prng code. I'd guess that with good sources, today's prng code is sufficiently strong and at least some unix systems do save state across reboot. Now if someone would just sell a completely open discrete logic serial port hw entropy source for under $50... that would end
There's an ARM system in there: http://www.entropykey.co.uk/ but in principle you can resurrect something like that, or wait until the company sees fit to sell that product again.
a lot of the talk. Even with a more costly radiation source rather
You don't need radiation. 12 USD USB SDR can sample 1.5 Msamples/s at 8 bit, and http://www.maximintegrated.com/app-notes/index.mvp/id/3469 is as simple as it gets, and is amplifies effectively quantum noise. I'm not sure how complex http://www.realtek.com.tw/products/productsView.aspx?Langid=1&PFid=35&Level=4&Conn=3&ProdID=257 is, but you can certainly decap a representative sample from each lot to validate it.
than other phenomena you'd still likely make good profit in quantity from China at that price. Sell other/cheaper/slower phenomena for a little less and make even more profit. Seal some up in a pretty wrapper and call it the corporate version for $1500.
Seems like a decent business idea.
On Thu, Oct 17, 2013 at 12:56 PM, grarpamp <grarpamp@gmail.com> 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? If you are on Linux, getting Turbid into your distro might well be the most important RNG work you could do. For Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591472 If you are concerned with other systems, it might well be worth considering whether Turbid could be ported. It appears better than anything else I have seen because it is the only one with a proof of randomness, and as far as I can tell the proof is solid.
On Fri, Oct 18, 2013 at 11:42:21AM -0400, Sandy Harris wrote:
On Thu, Oct 17, 2013 at 12:56 PM, grarpamp <grarpamp@gmail.com> 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
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 <grarpamp@gmail.com> 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
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 <grarpamp@gmail.com> 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.
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 <grarpamp@gmail.com<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.
Ted Smith (at Tuesday, October 22, 2013, 5:15:09 PM):
It actually works; when you view the webcam you can see the little points of light where an alpha particle hits the sensor.
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.
you can make entropy source out of anything that you can access from your computer. accessing is actually the harder part. you need to find out how to attach. you need to find out what access interface to use, how to be cross platform if you want to, how to test it on different platforms, how to retest if after new releases of said platforms, and so on. you can run into all sort of driver problems. another hard-ish part is to estimate the true entropy content. it might be much smaller than it looks like. understanding the physics of the underlying phenomenon helps. 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 disclaimer: the old rule "don't roll your own crypto" is still in effect.
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:
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
Andy Isaacson (at Tuesday, October 22, 2013, 8:27:16 PM):
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
that is interesting, but does not hurt my tool too much, because my whitener does chain blocks. i use a keccak sponge that is never cleared or reset. even if you feed it with all zeros, the output is indistinguishable from random for a very long time.
It would be much better to implement a multi-stage entropy pool design
certainly, but such tools have their purpose. for example a online lotteries might want to have high throughput random number generator. if you really feed some visual noise to a camera, the entropy production can even be multiple megabytes per second. it dwarfs any randomness harnessed from a regular desktop.
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.
Andy Isaacson <adi@hexapodia.org> wrote:
On Fri, Oct 18, 2013 at 11:42:21AM -0400, Sandy Harris wrote:
Now if someone would just sell a completely open discrete logic serial port hw entropy source for under $50...
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, ... 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 ...
There is configuration info for some common sound devices.
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. 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.
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
Am Mittwoch, 23. Oktober 2013, 23:46:26 schrieb Andy Isaacson: Hi Andy,
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.
Maybe CPU Jitter RNG provided on www.chronox.de helps here? The test results are prepared on a plethora of different CPUs, operating systems and compilers and thus should cover 95% of all users (I am trying to get test results for iOS to cover 99% of all users). (disclaimer: I wrote the code and I may be biased in the judgment) Ciao Stephan
On 2013-10-17, at 16:56, grarpamp <grarpamp@gmail.com> wrote:
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.
Open design doesn't mean it hasn't been undermined in manufacturing. If you didn't built it yourself, you can't be sure. cf http://cm.bell-labs.com/who/ken/trust.html Being on this list again is making me paranoid. On the bright side, my tinfoil hats are becoming quite fashionable. -- ~j
On 2013-10-19 04:46, Joseph Holsten wrote:
Open design doesn't mean it hasn't been undermined in manufacturing. If you didn't built it yourself, you can't be sure. cf http://cm.bell-labs.com/who/ken/trust.html Being on this list again is making me paranoid. On the bright side, my tinfoil hats are becoming quite fashionable. -- ~j
You can, however, be sure a microphone input is a reliable source of entropy, since fake entropy would interfere with its microphone function. When you hold a seashell to your ear, you are hearing thermal noise.
2013/10/18 James A. Donald <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.
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.
After I had posted my idea, I realized that there would be a possibility of ring-oscillator/ring-oscillator interactions if the delays of the individual inverters were of identical technology. (invertor delay). I thought of an idea to vary the size of the transistors (and/or capacitive loading) in the invertors such that the shortest-loop oscillator inverters were smaller, having perhaps 1-2% less delay, while the longest-loop oscillator inverters had a 4-5% greater delay, and the two intermediate-loop oscillators had 0-1% greater and 2-3% greater delays. I think this would tend to prevent inadvertent synchronization between these four ring-oscillators. Naturally, this would have to be tested, or at least characterized by the manufacturer. Another, belt-and-suspenders, approach would be to add a long-period LFSR to the above circuitry (48-64 bits, say) and XOR the ring-oscillator outputs with themselves, as well as with that LFSR. If the resulting signal had some sort of pattern, it would be of extraordinarily-long pattern. Jim Bell ________________________________ From: Lodewijk andré de la porte <l@odewijk.nl> To: James A. Donald <jamesd@echeque.com> Cc: "cypherpunks@cpunks.org" <cypherpunks@cpunks.org> Sent: Monday, October 21, 2013 3:43 PM Subject: Re: Curious RNG stalemate [was: use of cpunks] 2013/10/18 James A. Donald <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. 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?
2013/10/18 James A. Donald <jamesd@echeque.com <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.
At 11:46 AM 10/18/2013, Joseph Holsten wrote:
On 2013-10-17, at 16:56, grarpamp <grarpamp@gmail.com> wrote:
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. Open design doesn't mean it hasn't been undermined in manufacturing. If you didn't built it yourself, you can't be sure.
That's particularly true if you're getting cheap electronic hardware manufactured in China. Not because of security risks, but just because a lot of people who've gotten cheap stuff built over there have found that the local manufacturers often "improve" designs to make them more manufacturable or substitute parts for stuff they've got on hand.
participants (14)
-
Andy Isaacson -
Bill Stewart -
Cathal Garvey -
Eugen Leitl -
grarpamp -
James A. Donald -
Jim Bell -
Joseph Holsten -
Kelly John Rose -
Krisztián Pintér -
Lodewijk andré de la porte -
Sandy Harris -
Stephan Mueller -
Ted Smith