At 01:50 PM 8/2/99 -0400, Paul Koning wrote:
>
>I only remember a few proposals (2 or 3?) and they didn't seem to be
>[unduly weak]. Or do you feel that what I've proposed is this
>weak? If so, why? I've seen comments that say "be careful" but I
>don't remember any comments suggesting that what I proposed is
>completely bogus...
>
> We can waste lots of cycles having cosmic discussions,
> but that's not helping
>matters. What we need is a minimum of ONE decent quality additional
>entropy source, one that works for diskless IPSEC boxes.
OK, I see four proposals on the table. (If I've missed something, please
accept my apologies and send a reminder.)
1) Hardware TRNG
2) Network timing
3) Deposits from a "randomness server"
4) Just rely on PRNG with no reseeding.
Discussion:
1) Suppose we wanted to deploy a jillion of these things. Suppose they
have hardware TRNGs at an incremental cost of $10.00 apiece. That comes to
ten jillion dollars, and I don't want to pay that unless I have to.
2) Network timing may be subject to observation and possibly manipulation
by the attacker. My real-time clocks are pretty coarse (10ms resolution).
This subthread started with a discussion of software to estimate the
entropy of a bitstream, and I submit that this attack scenario is a perfect
example of a situation where no software on earth can provide a useful
upper bound on the entropy of the offered bit-stream.
3) Deposits from a server are conspicuously ineffective for terminating a
continuation attack. If we can't do better than that, we might as well go
for option (4) and not even pretend we are defending against continuation
attacks.
4) I don't think my customers would be very happy with a system that could
not recover from a transient read-only compromise.
So... What have I missed? What's your best proposal?
Thanx --- jsd
