On Tue, 21 Aug 2001, Alex Bligh - linux-kernel wrote:
> > No you don't, that's your whole complaint to start with. You're clearly
> > entropy-limited. If you were willing to block waiting for enough entropy,
> > you'd be fine with the current scheme.
>
> Yes I /do/. I want to wait for sufficient entropy. I count inter-IRQ
> timing from network as a source of entropy. IE if the entropy pool
> is exhausted, I'm prepared to, and desire to, block, until a few packets
> have arrived. However, I do not wish to block indefinitely (actually
> about 3 minutes as there's a little periodic block I/O) which is what
> happens if I do not count network IRQ timing as an entropy source
> (current /dev/random result, without Robert's patch, on most NICs).
> Equally, I do not want want to read /dev/urandom (and not block)
> which, in an absence of entropy, is (arguably) cryptographically weaker
> (see below).
You're throwing the baby out with the bathwater. If you overestimate the
entropy added by even a small amount, /dev/random is no better than
/dev/urandom.
Imagine your attacker has broken into your firewall and can observe all
packets on your network at high accuracy. She's also got an exact
duplicate of your operational setup, software, hardware, switches,
routers, so she's got a pretty good idea of what your interrupt latency
looks like, etc., and she can even try to simulate the loads you're
experiencing by replaying packets. She's also a brilliant statistician. So
on each network interrupt, when you're adding, say, 8 bits of entropy to
the count, she's able to reliably guess 1. Really she only needs to guess
one bit right more than half the time - so long as she can gather slightly
more information than we think she can. Since your app is occassionally
blocking waiting for entropy, you're giving it out faster than you're
taking it in. Assuming your attacker has broken the hash function (SHA and
then some), it's just a short matter of time before she has enough
information to correlate her guesses and what you've sent to figure out
exactly what's in the pool and start guessing your session keys. Assuming
she hasn't broken SHA, then /dev/urandom is just as good.
So the whole point of /dev/random is to be more secure than just the hash
function and mixing. Which do you think is easier, breaking the hash
function or breaking into your network operations center and walking off
with your server? If your NOC is so secure, then you can probably afford a
hardware entropy source..
Read Schneier's essay on attack trees if the above argument doesn't make
sense to you:
http://www.ddj.com/articles/1999/9912/9912a/9912a.htm?topic=security
> Measuring it there at least 16 network IRQs for the minimum
> SSL transaction. That generates 16x12 = 192 bits of
> entropy (each IRQ contributes 12 bits).
12 bits is a maximum and it's based on the apparent randomness of the
interrupt timing deltas. If your attacker is impatient, she can just ping
you at pseudo-random intervals tuned to clean your pool more rapidly.
You're also forgetting that TCP initial sequence numbers come from the
pool to prevent connection spoofing - more entropy lost.
> The point is simple: We say to authors of cryptographic applications
> (ssl, ssh etc.) that they should use /dev/random, because /dev/urandom
> is not cryptographically strong enough.
Who ever said that? /dev/random is a cute exercise in paranoia, not
practicality. It's nice for seeding personal GPG keys and ssh identities,
but was never intended for bulk cryptography. It's also nice for keys
you're going to reuse because if your attacker monitors all your traffic
and holds onto it for 50 years, and SHA happens to gets broken before El
Gamal, your GPG key is still safe.
-- "Love the dolphins," she advised him. "Write by W.A.S.T.E.."- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Aug 23 2001 - 21:00:43 EST