> Alex Bligh - linux-kernel wrote:
>> OK; well in which case it doesn't solve the problem.
>
> I don't see why not. Apply this change, and use /dev/urandom.
> You'll never block, and the outputs should be thoroughly unpredictable.
> What's missing?
See message to Oliver - para on waiting for sufficient entropy;
/dev/urandom (before that arrives) is just as theoretically
vulnerable as before.
> (I don't see why so many people use /dev/random rather than /dev/urandom.
> I harbor suspicions that this is a misunderstanding about the properties
> of pseudorandom number generation.)
Things like (from the manpage):
When read, the /dev/random device will only return random
bytes within the estimated number of bits of noise in the
entropy pool. /dev/random should be suitable for uses
that need very high quality randomness such as one-time
pad or key generation. When the entropy pool is empty,
reads to /dev/random will block until additional environ
mental noise is gathered.
When read, /dev/urandom device will return as many bytes
as are requested. As a result, if there is not sufficient
entropy in the entropy pool, the returned values are theo
retically vulnerable to a cryptographic attack on the
algorithms used by the driver. Knowledge of how to do
this is not available in the current non-classified liter
ature, but it is theoretically possible that such an
attack may exist. If this is a concern in your applica
tion, use /dev/random instead.
So writers of ssh, ssl etc. all go use /dev/random, which is not
'theoretically vulnerable to a cryptographic attack'. This means,
in practice, that they are dysfunctional on some headless systems
without Robert's patch. Robert's patch may make them slightly
less 'perfect', but not as imperfect as using /dev/urandom instead.
Using /dev/urandom has another problem: Do we expect all applications
now to have a compile option 'Are you using this on a headless
system in which case you might well want to use /dev/urandom
instead of /dev/random?'. By putting a config option in the kernel,
this can be set ONCE and only degrade behaviour to the minimal
amount possible.
-- Alex Bligh - 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:40 EST