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

[Werner Koch]

On Wed, 23 Feb 2011 11:17, nmav at gnutls.org said:

> Using the RSA (encryption)/AES-CBC/HMAC-SHA-1 ciphersuite of TLS. This is

How do you handle the random requirements - has the RNG been seeded
prior to the tests?  Does Nettle use blinding?

> On an individual speed test I got:
> SHA1: nettle faster 20%

How do yo use it?  gcry_md_hash_buffer, or gcry_md_open, write, close?

> AES-128-CBC: nettle faster 40%

There is definitley room for improvements.  

> RC4: nettle faster 30%

Come one, no sane cryptographer will use arcfour.

> 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

We need to keep Libgcrypt legally safe.  Thus there we don't want to
change that.  Giving a choice of code variants will lead to high
maintenance costs and makes the code more complex and thus buggy.

> could abolish the internal version for the actual gmplib, or even use
> another bignumber library, that delegates the optimizations to another
> project.

There is no internal version libgmp.  The MPI code in Libgcrypt is very
different from GMP.  Only the asm code was pretty similar.  And right,
it is somewhat slower to help protect confidential data.

> 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

Nope.  You can't build security into a system if you don't start
implementing it in the foundation.  Thus is is not alone an application
issue.

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

Building a security system without knowing what's going on in all parts
of the system is a major engineering mistake.  I can't repeat it often
enough: A library is just a collection of code which makes things
easier.  It does not relieve you from knowing how to use this code
properly.

> Given that anyway there is no interface that can cope with
> all public key algorithms in uniform (sexp doesn't either), having

Right.  However, using s-expressions is quite flexible and allows its
use all over the place.  No more need to take care of all the nitty
gritty details of key parameters.  Only the protocol engine needs to
convert them - this conversions needs to be done anyway.

> access to the low-level public key algorithms is more efficient.

Sure low-level might is more efficient but only if you go into the
trouble to add the high-level code your self.  You will need it anyway
for solid engineering principles.

> 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

Thus you need to check all error codes form the subsystem and translate
them to gnutls error codes.  With a location as part of the error code,
it would be easy to see that for example not a certain curve is not
implemented or a low-level selftest has failed.  Anyway, for gnutls is
is not possible to use gpg-error due to ABI and API incompatibilities.  I
noted that merely to make clear that gpg-error may be used by other
projects.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.