>>>>> "Arnold" == Arnold G Reinhold <[EMAIL PROTECTED]> writes:
Arnold> I have found this discussion very stimulating and
Arnold> enlightening. I'd like to make a couple of comments:
Arnold> 1. Mr. Kelsey's argument that entropy should only be added in
Arnold> large quanta is compelling, but I wonder if it goes far
Arnold> enough. I would argue that entropy collected from different
Arnold> sources (disk, network, sound card, user input, etc.) should
Arnold> be collected in separate pools, with each pool taped only
Arnold> when enough entropy has been collected in that pool.
Arnold> Mixing sources gives an attacker added opportunities. For
Arnold> example, say entropy is being mixed from disk accesses and
Arnold> from network activity. An attacker could flood his target
Arnold> with network packets he controlled, insuring that there would
Arnold> be few disk entropy deposits in any given quanta release. On
Arnold> the other hand, if the entropy were collected separately,
Arnold> disk activity entropy would completely rekey the PRNG
Arnold> whenever enough accumulated, regardless of network
Arnold> manipulation. Similarly, in a system with a hardware entropy
Arnold> source, adding disk entropy in a mixing mode would serve
Arnold> little purpose, but if the pools were kept separate, disk
Arnold> entropy would be a valuable backup in case the hardware
Arnold> source failed or were compromised.
I think this makes sense only if the "entropy source" under
consideration isn't actually any good. If if is reasonably sound (and
in particular, its entropy amount estimated conservatively) then there
isn't a problem. For example, if an attacker floods with network
messages, and you use network timing as an entropy source, the design
job was to pick a conservative lower bound of entropy per arrival
given that the arrivals may all be controlled by an attacker. If
you've done that, then the attack doesn't hurt.
Arnold> 2. It seems clear that the best solution combines strong
Arnold> crypto primitives with entropy collection. I wonder how much
Arnold> of the resistance expressed in this thread by has to do with
Arnold> concerns about performance. For this reason, I think RC4
Arnold> deserves further consideration. It is very fast and has a
Arnold> natural entropy pool built in. With some care, I believe RC4
Arnold> can be used in such a way that attacks on the PRNG can be
Arnold> equated to an attacks on RC4 as a cipher. The cryproanalytic
Arnold> significance of RC4's imperfect whiteness is questionable and
Arnold> can be addressed in a number of ways, if needed. I have some
Arnold> thoughts on a fairly simple and efficient multi-pool PRNG
Arnold> design based on RC4, if anyone is interested.
Well, yes, but /dev/{u,}random already does use strong crypto (a
strong cryptographic hash, to be precise). I expect RC4 could do the
job but is there any reason to replace what's there now (MD5 and
SHA-1) with RC4 or anything else?
Arnold> 3. With regard to diskless nodes, I suggest that the
Arnold> cryptographic community should push back by saying that some
Arnold> entropy source is a requirement and come up with a
Arnold> specification (minimum bit rate, maximum acceptable color,
Arnold> testability, open design, etc.). An entropy source spec would
Arnold> reward Intel for doing the right thing and encourage other
Arnold> processor manufacturers to follow their lead.
Obviously an entropy source is required, but I'm not prepared to
translate that into a requirement for dedicated hardware. I still
believe (based on experiments -- though not on PC hardware) that
network arrival timing done with low order bits from a CPU cycle
counter supply non-zero entropy.
Arnold> A hardware RNG can also be added at the board level. This
Arnold> takes careful engineering, but is not that expensive. The
Arnold> review of the Pentium III RNG on www.cryptography.com seems
Arnold> to imply that Intel is only claiming patent protection on its
Arnold> whitening circuit, which is superfluous, if not harmful. If
Arnold> so, their RNG design could be copied.
There are probably plenty of designs; at the block diagram level they
are pretty simple and pretty obvious. The devil is in the details.
By the way, various crypto accelerator chips now come with an RNG
built-in. Some may be subject to export control, which would make
them unuseable in a Linux contents, but perhaps not all of them.
paul
