[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: Mon, 28 Apr 2008 18:31:34 +0200
User-agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.2 (gnu/linux)

"Ashish Gupta" <address@hidden> writes:

> 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 (with openssl) is
> 1.3M stripped! (will check that later).

Don't forget to count as well, for OpenSSL.  To be fair,
OpenSSL implements much more than what GnuTLS does.  On the other hand,
you can view this as better modularization -- the things that GnuTLS
doesn't implement is available from other libraries (libtasn1,
libgcrypt, libksba, gnupg2, etc).

> 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.

The reason is, as far as I understand, that libgcrypt initialize its
randomness pool in a more pessimistic way than openssl, and thus
requires much more hashes.

>    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.

Which libtasn1 version are you using?  Maybe the alloca->malloc change I
did recently had negative consequences... however, I'm not sure.  Also,
I'm not sure it is worth spending time on this -- loading certificates
is only done once.

>    3. Openssl takes about 53% of time just to load its error strings.

Translated error strings?  GnuTLS also has translated error strings, but
maybe it loads them differently.

>    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)

GnuTLS requests 1 random character during initialization, mostly to
trigger any installation problem with libgcrypt early on rather than
later during the handshake.  The order when this is done isn't that
important, IMHO, instead the time it takes is what is important.

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

The approach I mentioned would only be used under GNU/Linux.  The
/dev/*random devices on non-linux systems are sometimes known to be
completely broken.

On Windows, we could use its native PRNG interface, although that is
known to have several problems.  The simplest is to do what we do today,
require libgcrypt.


reply via email to

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