[gnutls-dev] Re: alternative /dev/random
ametzler at downhill.at.eu.org
Sat Mar 11 13:08:14 CET 2006
On 2006-03-01 Simon Josefsson <jas at extundo.com> wrote:
> "Nikos Mavrogiannopoulos" <nmav at gnutls.org> writes:
> > Thus if your system had one of the previously discussed problems,
> > we'd like to suggest you to try this kernel prng implementation
> > and discuss it in this list.
> In particular, I want to suggest that Debian look into adding this
> patch to their kernels. That would be the first step towards making
> GnuTLS and/or libgcrypt use those devices, and would solve the
> blocking issue.
There is no blocking issue in /current/ exim4 packages. RSA/DSA params
generation is done offline (using cron). And there is zero chance that
blocking issue in Debian stable (sarge) is going to be fixed by
applying a patch to the kernel (which is not approved by lkml).
I am also very reluctant to suggest that Debian's kernels are patched
to use the fortuna PRNG http://jlcooke.ca/random/ by default for a
couple of reasons:
- Debian's kernel team tries to limit divergence from upstream. Every
single additional patch increases workload.
- I am not qualified to judge the quality of the fortuna RPNG.
- I've read up on the fortuna discussions on LKML. I do not expect to
see the fortuna patch being accepted, replacing the current
/dev/(u)random implementation. Theodore Ts'o (the current
/dev/(u)random maintainer) prefers the current implementation for
various reasons. The current implentation does not require
CONFIG_CRYPTO, and "we simply have carefully designed /dev/random to
minimize its reliance on crypto primitives, since we have so much
entropy available to us from the hardware. Fortuna, in contrast, has
the property that if its cryptoprimitives are broken, you might as
well go home." The general feeling seems to be that the current
implemtation works, and fortuna is a nice concept but not better
than the current implementation.
The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal
vision of the emperor's, and its inclusion in this work does not constitute
tacit approval by the author or the publisher for any such projects,
howsoever undertaken. (c) Jasper Ffforde
More information about the Gnutls-devel