Re: [Cryptography] Thoughts on hardware randomness sources
On 09/13/2013 11:32 PM, Jerry Leichter wrote: On Sep 12, 2013, at 11:06 PM, Marcus D. Leech wrote: There are a class of hyper-cheap USB audio dongles with very uncomplicated mixer models. A small flotilla of those might get you some fault-tolerance. My main thought on such things relates to servers, where power consumption isn't really much of an issue I'm not sure what servers you're talking about here. If by server you mean one of those things in a rack at Amazon or Google or Rackspace - power consumption, and its consequence, cooling - is *the* major issue these days. Also, the servers used in such data centers don't have multiple free USB inputs - they may not have any. If by server you mean some quite low-power box in someone's home ... power is again an issue. People want these things small, fan-free, and dead reliable. And they are increasingly aware of the electric bills always-on devices produce. About the only server for which power is not an issue is one of those extra-large desktops that small businesses use. -- Jerry I was mostly contrasting with mobile systems, where power consumption is at an absolute premium. The USB sound systems I'm thinking of consume 350mW while operating, and about 300uW when idle. A couple or three of those on even a stripped-down server would contribute in only the smallest way to extra power consumption. And the extra computational load? When these servers things are running flat-out serving up secured connections? I would guess the phrase an inconsiderable trifle would apply. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Thoughts on hardware randomness sources
On Sep 12, 2013, at 11:06 PM, Marcus D. Leech wrote: There are a class of hyper-cheap USB audio dongles with very uncomplicated mixer models. A small flotilla of those might get you some fault-tolerance. My main thought on such things relates to servers, where power consumption isn't really much of an issue I'm not sure what servers you're talking about here. If by server you mean one of those things in a rack at Amazon or Google or Rackspace - power consumption, and its consequence, cooling - is *the* major issue these days. Also, the servers used in such data centers don't have multiple free USB inputs - they may not have any. If by server you mean some quite low-power box in someone's home ... power is again an issue. People want these things small, fan-free, and dead reliable. And they are increasingly aware of the electric bills always-on devices produce. About the only server for which power is not an issue is one of those extra-large desktops that small businesses use. -- Jerry ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Thoughts on hardware randomness sources
At 08:32 PM 9/13/2013, Jerry Leichter wrote: If by server you mean one of those things in a rack at Amazon or Google or Rackspace - power consumption, and its consequence, cooling - is *the* major issue these days. Also, the servers used in such data centers don't have multiple free USB inputs - they may not have any. More to the point, the servers in the data centers aren't going to let you plug things in to them, especially if you're just renting a virtual machine or cloud minutes and don't get to connect to the real hardware at all (which also means you're not going to be able to use disk drive timing.) A tablet computer has lots of sensors in it; even turning the cameras on at boot time and hashing the raw pixels should give you a reasonable chunk of entropy; you're not going to turn your virtual machine upside down and shake it like an Etch-A-Sketch. I realize it's possible for somebody to try to manipulate this, but I've always assumed that ethernet packet timing ought to give you some entropy even so, and even though with virtual machines you may only get quantized versions of interrupt times. Startup processes are probably going to include pinging a router and a name server, or at least they could if you wanted. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Thoughts on hardware randomness sources
On 09/12/2013 10:38 PM, Thor Lancelot Simon wrote: The audio subsystem actually posed *two* obvious opportunities: amplifier noise from channels with high final stage gain but connected by a mixer to muted inputs, and clock skew between system timers and audio sample clocks. The former requires a lot of interaction with specific audio hardware at a low level, and with a million different wirings of input to mixer to ADC, it looks hard (though surely not impossible) to quickly code up anything generally useful. The latter would be easier, and it has the advantage you can do it opportunistically any time the audio subsystem is doing anything *else*, without even touching the actual sample data. Unfortunately, both of them burn power like the pumps at Fukushima, which makes them poorly suited for the small systems with few other sources of entropy which were one of my major targets for this. So they are still sitting on some back back back burner. Someday, perhaps... Thor There are a class of hyper-cheap USB audio dongles with very uncomplicated mixer models. A small flotilla of those might get you some fault-tolerance. My main thought on such things relates to servers, where power consumption isn't really much of an issue. Similarly these hyper-cheap ($10.00) DVB-T dongles based on the RTL2832U can be made to run in SDR mode, and give you a basebanded sample stream of a wide variety of tuned RF frequencies--put a terminator on the input, chose your frequency, crank up the gain, and pull samples until you're bored This topic has suddenly become interesting to me in my work life, so I'm currently looking at the sensors API for Android. I thought I had left Android work behind, but it's coming back to haunt me. I was playing with the sensor outputs on a Nexus tablet today, and it has an impressive array of sensors. I suspect each of them could contribute a few bits/second of entropy without too much trouble. More investigation is necessary. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Thoughts on hardware randomness sources
On Tue, Sep 10, 2013 at 10:59 AM, Marcus D. Leech mle...@ripnet.com wrote: I wonder what people's opinions are on things like the randomsound daemon that is available for Linux. I have not looked at that. A well thought out well documented RNG based on a sound card is: http://www.av8n.com/turbid/paper/turbid.htm I wrote a very simple one (perhaps not yet trustworthy because it has not had much analysis) based on timer calls. Its documentation discusses a few others: ftp://ftp.cs.sjtu.edu.cn:990/sandy/maxwell/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Thoughts on hardware randomness sources
On 09/10/2013 12:04 PM, Rob Kendrick wrote: I wonder what people's opinions are on things like the randomsound daemon that is available for Linux. Daniel Silverstone, the author, specifically advises people to not use it. :) I haven't actually looked at the code. Conceptually, anything with an ADC can produce thermal and or 1/f noise in the lowest-order bits. Even if it's somewhat biased (like having 60Hz hum embedded in it), with a suitable whitening function, it should produce high-quality entropy at rates of at least several hundred bits/second. The idea is to have *diversity* of physical random sources, to make it difficult for bad actors to subvert said hardware. It's fairly easy to audit these sources of random bits, since said bits won't have had any processing done to them in support of their random properties (unlike the Intel HW RNG). But this is just one aspect of a much-larger problem of trusting trust (in the Thompson sense). -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Thoughts on hardware randomness sources
On Tue, Sep 10, 2013 at 10:59:37AM -0400, Marcus D. Leech wrote: I wonder what people's opinions are on things like the randomsound daemon that is available for Linux. Daniel Silverstone, the author, specifically advises people to not use it. :) B. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
