[Pkg-gnutls-maint] Multiple GnuTLS issues with exim4

[Ingo Saitz]

On Fri, Jul 07, 2006 at 11:21:28AM +0000, Marc Haber wrote:
> On Mon, Jun 26, 2006 at 11:50:40PM +0100, James Westby wrote:
> > Hopefully the amount of entropy used
> > could be decreased, which would help a lot.
> 
> openssl proves that it is possible. I suspect that they use "real"
> entropy to seed a PRNG and pull their randomness from there. Doing so
> in GNUtls might decrease entropy consumption by at least one order of
> magnitude.

What about using a PRNG in case the entropy pool is depleted? If you
feed it regularly with new entropy if available I doubt there is a good
chance to attack that.

I am thinking of /dev/urandom (man 4 urandom), which does use the
kernels entropy pool if entropy is available falls back to a PRNG if
not. Qouting urandom(4):

       As a result, if there is not sufficient entropy in the
       entropy pool, the returned values are theoretically 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.

I believe that all other methods used by gnutls might also theoretically
vulnerable to a cryptographic attack on the algorithms. No algorithm is
proved to be secure (except OTP), they are only not proved to be
insecure (cf. the recent attacks on md5 and sha1, which showed them to
actualle be more insecure than common believe did). Also, since
/dev/urandom actually uses entropy bits if available and may also be
used by other programs, it is no simple PRNG and should be even harder
to attack.

I'm asking because I never found a _good_ answer on why /dev/urandom
should not be used, except for imho paranoid reasons. Maybe you could
start by making the use of /dev/urandom for entropy configureable to the
admin.

> > I'm not sure what we can do to help you here without movement upstream.
> 
> Your only chance is probably to continue pestering upstream.

Did upstream ever consider using /dev/urandom?

Greetings
    Ingo
-- 
print<<''x2,$/
print<<''x2,$/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-gnutls-maint/attachments/20060727/cc5b5385/attachment.pgp