[5341] in cryptography@c2.net mail archive
Re: linux-ipsec: /dev/random
daemon@ATHENA.MIT.EDU (John Denker)
Tue Aug 3 19:29:07 1999
Date: Mon, 02 Aug 1999 15:35:59 -0400
To: Paul Koning <pkoning@xedia.com>
From: John Denker <jsd@research.att.com>
Cc: cryptography@c2.net, linux-ipsec@clinet.fi
In-Reply-To: <199908021750.NAA12682@tonga.xedia.com>
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
