At 11:38 AM -0400 8/10/99, Paul Koning replied:
> >>>>> "Arnold" == Arnold G Reinhold <[EMAIL PROTECTED]> writes:
> Arnold> ...
> 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> ...
>
>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.
This is where I disagree most strongly and the reasons are somewhat a
mater of philosophy. It is relatively easy to design crypto systems
that protect against attacks you know. It is harder to defend against
unanticipated attacks. Maybe some future server box will have the
network controller integrated with the CPU and running off the same
clock so that all your sub-millisecond entropy goes bye-bye. Maybe
someone more clever than I will figure out how to goose the network
just so and get things to sync up a la V.90. I would be a whole lot
happier having the entropy come from two or more independent sources
and having it accumulated independently. If all it takes is a little
software, why not do that?
>
> Arnold> ... I think RC4 deserves further consideration. ...
>
>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?
I like RC4 for this application 'cause its fast and simple, but it's
a side issue. If you are satisfied with performance, there is no
reason to change.
>
> 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.
IPsec is going to spawn a whole industry and represents an
opportunity to get things done right. The software you are designing
today may be used unchanged for decades in very sensitive
applications. (The Y2K report for the Seabrook nuclear plant lists a
critical database running on a PDP-11). Maybe one compromise is to
define a set of quality levels for random number generation, say:
A = hardware RNG + ad hoc backup
B = hardware RNG alone
C = two or more ad hoc sources, e.g. disk and network,
independently collected
D = single ad hoc source
Then market pressure would drive vendors to level A.
Arnold
