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