[Pkg-gnutls-maint] Bug#448775: Uses too much entropy (Debian Bug #343085)

[Simon Josefsson]

Andreas Metzler <ametzler at downhill.at.eu.org> writes:

> On 2008-01-04 Simon Josefsson <simon at josefsson.org> wrote:
>> Andreas Metzler <ametzler at downhill.at.eu.org> writes:
>
>> > On 2008-01-04 Simon Josefsson <simon at josefsson.org> wrote:
>> > [...]
>> >>   2) To make exim link to and call libgcrypt's functions to read and
>> >>      update a random seed file instead?
>> > [...]
>> >> For simplicity and non-experimentalness, I would recommend 2).  I can
>> >> assist in implementing this in exim, if that would help.  We'd
>> >> definitely need a good example of how to do this in the gnutls manual
>> >> anyway.
>> > [...]
>
>> > Well, the basic patch for testing seems to be this one, basically
>> > identical to the skeleton you described. I gets down entropy-usage
>> > for a single STARTTLS to <300 bits from > 3000. 
>
>> Nice.  How much does a similar server consume using openssl?  Do openssl
>> used by exim use a seed file?
>
> Hello,
>
> testing with a exim linked against OpenSSL I get *slightly* less
> entropy usage (235 vs 289 bits in the first testrun) when connecting
> with swaks (perl/OpenSSL).

For my curiosity, what are those numbers if you run gnutls with a
NORMAL:%COMPAT priority?  Cipher padding needs one byte of randomness
for every encrypted packet, disabling padding may thus reduce the
randomness needed further.  This assumes you actually sent some data
back and forward, I don't whether you did.

> These numbers were generated with the most simple method possible. -
> Watch /proc/sys/kernel/random/entropy_avail when STARTTLSing from
> localhost. Then STARTTLS from localhost to a remote server to find out
> how much of the the total entropy usage was generated by the client,
> instead of the server.

So this result is both good and bad.

It is good because we are now on par with openssl on this.

It is bad because it suggests busier sites would run into the same
problem, with both gnutls and openssl.  However, that seems beyond the
current problem.

> OpenSSL does not safe any random seed.

Interesting, 235/8=29.375 bytes.  The minimum randomness needed per TLS
session would be 28 bytes for client hello random_bytes plus 46 bytes
for the PreMasterSecret (if RSA is used for key exchange).  If openssl
is using /dev/urandom, I think it is overly optimistic about the quality
of that data.

/Simon