Curious RNG stalemate [was: use of cpunks]

[Andy Isaacson]

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