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 <simon at josefsson.org>
wrote:

> "Ashish Gupta" <ashishg2dec at gmail.com> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20080428/246a779e/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: callgrind.out.24173.gz
Type: application/x-gzip
Size: 141532 bytes
Desc: not available
URL: </pipermail/attachments/20080428/246a779e/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: callgrind.out.25616.gz
Type: application/x-gzip
Size: 46589 bytes
Desc: not available
URL: </pipermail/attachments/20080428/246a779e/attachment-0001.bin>