[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Size of Libgcrypt (and other libraries) and subsequent performance

From: Simon Josefsson
Subject: Re: Size of Libgcrypt (and other libraries) and subsequent performance
Date: Fri, 25 Apr 2008 16:59:34 +0200
User-agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.2 (gnu/linux)

"Ashish Gupta" <address@hidden> writes:

> HI Simon,
> Thanks for the update. I am currently not in office, however will conduct
> more experiments once I am back.
> Meanwhile, the figures related to the run time overheads are most
> intriguing. Any comparisions on the way openssl handles its randoms?

I don't have openssl libraries with debug symbols, but if you want to do
the comparison for openssl that could help.

If libgcrypt randomness code isn't improved, I think we should start
thinking about adding our own PRNG and using it by default.  Here is how
I think it should work:

1. On initialization, read 32 bytes from /dev/urandom and seed a
AES-based PRNG.

2. For the two lesser randomness levels, nonce + random, read data from
the PNRG.

3. For the higher randomness level (e.g., for long-lived RSA keys), read
bytes directly from /dev/random.  Possibly XOR it against the
/dev/urandom based PRNG output?

As far as I recall, no part of a TLS handshake will require the
strongest randomness level, so all typical GnuTLS applications will at
most read 32 bytes from /dev/urandom.  GnuTLS applications that generate
long-lived keys (normally only 'certtool'?) will read data from

The good thing is that we can experiment with how much performance
improvement this would yield relatively easily, once the crypto.h rnd
code works.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]