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

[Ashish Gupta]

Hi,

Back again!

Firstly, the gcrypt version I am using is  1.4.0. I did strip the required libraries to more manageable sizes ('tis now 621K for TLS and 443K for gcrypt). Thanks for the input. Surprisingly libcrypto.so (with openssl) is 1.3M stripped! (will check that later).

Also, I ran the same program with openssl to see the results with kcachegrind. Attaching the corresponding callgrind.out for analysis.

Not suprisingly, the following points turned up -

1. As mentioned before the random is the culprit on gcrypt. Just the "transform" function is called a whopping 56.96% of the times. Compared to what openssl does is calls SHA1_Update to mix its randoms, which is much faster.
   
2. asn1_find_node is taking only 1.55% of the time, in the tests I have run. Unsure why asn1_find_node is taking about 14% in the details sent before.
   
3. Openssl takes about 53% of time just to load its error strings.
   
4. Another difference is that Openssl invokes its PRNG "after" starting the handshake, whereas in TLS this is a part of gnutls_global_init. Unsure what is the reason for this in case of Openssl (for that matter, why is it part of global init in case of TLS)

 It would make sense to source it from /dev/urandom on linux, however unsure how the same will be done on windows!. 

Regards,
Ashish

On Fri, Apr 25, 2008 at 8:29 PM, Simon Josefsson <address@hidden> wrote:

"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
/dev/random.

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.

Thoughts?

/Simon

callgrind.out.24173.gz
Description: GNU Zip compressed data

callgrind.out.25616.gz
Description: GNU Zip compressed data