LGPL library using only LGPL-parts of partially GPL shared library (gnutls, nettle)

[Nikos Mavrogiannopoulos]

On Tue, Feb 22, 2011 at 4:42 PM, Werner Koch <wk at gnupg.org> wrote:

>> My main issues were:
>> * performance... gcrypt is very slow in the software
>> implementation of AES and SHA-1, comparing to
> Depends on your hardware.  See my recent announcement.  In fact we did
> some work on CFB and CBC performace to help GnuPG and gnutls more than 2
> years ago.  SHA-2 performance was recently also improved.

My tests (march 2010) were with libgcrypt 1.4.4 and nettle 2.0 on a
dual core amd64...
Using the RSA (encryption)/AES-CBC/HMAC-SHA-1 ciphersuite of TLS. This is
quite a popular ciphersuite of TLS because it is fast (comparing to
diffie-hellman
ones). The tests were performed using siege (running from another machine)
and apache/mod_gnutls, running for 30 seconds.

gnutls+libgcrypt:
Response time:                  0.23 secs
Transaction rate:              63.88 trans/sec
Throughput:                    12.38 MB/sec

gnutls+nettle:
Response time:                  0.11 secs
Transaction rate:             131.63 trans/sec
Throughput:                    25.51 MB/sec

The response time is actually the time spent on a handshake, and
it seems that RSA decryption takes longer on libgcrypt than nettle.

On an individual speed test I got:
SHA1: nettle faster 20%
AES-128-CBC: nettle faster 40%
RC4: nettle faster 30%
3DES-CBC: gcrypt faster 10%

SHA256: nettle faster 30% (this is probably no longer true since
I used libgcrypt 1.4.4).

> Tuning of Libgcrypt is not not very complicated but it takes quite some
> time.  Thus if I have to do it, I need to have a real use case.
>> other libraries and nettle... Moreover it uses its
> Please recall that Libgcrypt is a core GNU project and requires CAs.
> Thus it is not possible to use some of the better tuned implementations.
> Many years ago I discussed this with Brian Gladman: Although he then
> allows to use his code under the GPL, we was not able to sign a
> disclaimer of CA.  Thus we have to do this work ourself.

I know and pretty understand that, but it seems that here it is limiting us
rather than allowing software re-use. I.e. if Niels or Brian have a
faster AES under
GPL why cannot we take advantage of that? Could we have a setup where
one could choose to have an FSF copyrighted work or a combination
of it? (I.e. at configure one selects whether the fsf version of the algorithms
will be included or the optimized but by another copyright holders?).

>> own gmp that prevents from including all optimizations
>> added to the original gmp library.
> Let's not repeat this over and over again.  In short: At the time the
> Libgcrypt code was written, tehre was no GMP development at all.  Later
> GMP change the entire configuration system; which made it hard to re-use
> the asm code.

I don't expect you to backport everything from the new gmplib, I don't even
think it is a good idea. The good thing with having separate projects is that
each one can optimize his part. I can work on optimizations on the TLS protocol,
you can work on the algorithms, and the gmp guys on the big number arithmetic.

For me there is no point in insisting in maintaining the old version
of gmp. You
could abolish the internal version for the actual gmplib, or even use another
bignumber library, that delegates the optimizations to another project.

>> * mandates how the library is going to be used by
>> using setuid etc... Why shouldn't a setuid application
> Libgcrypt is about security and thus it uses secure defaults.  The
> application is abale to chnage tehse defaults.
>> perform TLS? Indeed there are risks but it should be
>> the application developer to decide, not us.
> I disagree.  Look at all the failures we have seen over last 20 years
> with crypto code; most of them are due to "let the application developer
> make sure it is used properly".  Libgcrypt tries to minimize the risks.

But this issue is not about cryptography. A cryptographic library is about
cryptography and not security in general. Security is decided by the application
or by another security policy library. Libgcrypt is not such a library.
It is a library that people don't even know they are using (the same is for
gnutls). They want to do a secure connection somewhere, and
they happen to use us. If they cannot use us, because we set specific
policies for them, they'll use another library or fall-back to
unsecure connections.

They are not going to disable libgcrypt's policies because they might
not even know that libgcrypt is being used (maybe they just do an ldap
call or so).

>> * lack of low level functions to perform RSA/DSA/ECC.
> Please explain.

[this is of lower importance that the other points]

To do a DSA signature with libgcrypt it requires:
gcry_sexp_build("(private-key(dsa(p%m)(q%m)(g%m)(y%m)(x%m)))",...)
gcry_sexp_build("%m",...) //for the hash
gcry_pk_sign()
gcry_sexp_find_token("r"...)
gcry_sexp_nth_mpi() // get r
gcry_sexp_find_token("s"...)
gcry_sexp_nth_mpi() // get s
gcry_sexp_release(...)

with nettle I only need to use:
_dsa_sign(...)

Given that anyway there is no interface that can cope with
all public key algorithms in uniform (sexp doesn't either), having
access to the low-level public key algorithms is more efficient.

>> * gpg-error... adds a library dependence for something
>> that is really simple and could be part of libgcrypt
>> anyway. For non-gnupg applications there is nothing
>> to be gained by this shared library.
> Error management is not simple.  In fact, gnutls should have adopted
> gpg-error as well.  For example, gpg-error allows to figure out the
> subsystem which generated the error.  This is often very useful.  It is
> very easy to use and does not require many code changes as other error
> management systems do (look at GTK+).

I'll check it but gnutls has its own error subsystem. Detecting
the subsystem that caused the error, is not so important for
gnutls since we only have one. What is important is logging
and auditing something that we currently do with a logging
callback, but will try to improve in order to have auditing fascilities
as well (i.e. to know that in this connection from that IP illegal or
replayed packets were received in DTLS etc.).

regards,
Nikos