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
