Re: [PATCH] random: add blocking facility to urandom

[Sasha Levin]

On Wed, 2011-09-07 at 14:26 -0400, Jarod Wilson wrote:
> Sasha Levin wrote:
> > On Wed, 2011-09-07 at 13:38 -0400, Jarod Wilson wrote:
> >> Certain security-related certifications and their respective review
> >> bodies have said that they find use of /dev/urandom for certain
> >> functions, such as setting up ssh connections, is acceptable, but if and
> >> only if /dev/urandom can block after a certain threshold of bytes have
> >> been read from it with the entropy pool exhausted. Initially, we were
> >> investigating increasing entropy pool contributions, so that we could
> >> simply use /dev/random, but since that hasn't (yet) panned out, and
> >> upwards of five minutes to establsh an ssh connection using an
> >> entropy-starved /dev/random is unacceptable, we started looking at the
> >> blocking urandom approach.
> >
> > Can't you accomplish this in userspace by trying to read as much as you
> > can out of /dev/random without blocking, then reading out
> > of /dev/urandom the minimum between allowed threshold and remaining
> > bytes, and then blocking on /dev/random?
> >
> > For example, lets say you need 100 bytes of randomness, and your
> > threshold is 30 bytes. You try reading out of /dev/random and get 50
> > bytes, at that point you'll read another 30 (=threshold) bytes
> > out /dev/urandom and then you'll need to block on /dev/random until you
> > get the remaining 20 bytes.
> 
> We're looking for a generic solution here that doesn't require 
> re-educating every single piece of userspace. [...]

A flip-side here is that you're going to break every piece of userspace
which assumed (correctly) that /dev/urandom never blocks. Since this is
a sysctl you can't fine tune which processes/threads/file-handles will
block on /dev/urandom and which ones won't.

> [..] And anything done in 
> userspace is going to be full of possible holes [..]

Such as? Is there an example of a case which can't be handled in
userspace?

>  [..] there needs to be 
> something in place that actually *enforces* the policy, and centralized 
> accounting/tracking, lest you wind up with multiple processes racing to 
> grab the entropy.

Does the weak entropy you get out of /dev/urandom get weaker the more
you pull out of it? I assumed that this change is done because you want
to limit the amount of weak entropy mixed in with strong entropy.


btw, Is the threshold based on a research done on the linux RNG? Or is
it an arbitrary number that would be set by your local sysadmin? 

-- 

Sasha.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/