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

Nikos Mavrogiannopoulos nmav at gnutls.org
Wed Feb 23 18:14:13 CET 2011


On Wed, Feb 23, 2011 at 4:03 PM, Werner Koch <wk at gnupg.org> wrote:

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

The RNG has been seeded using /dev/urandom in both cases. Nettle uses
yarrow as an RNG, and the locking is done on the gnutls level. The gnutls
code that uses nettle RSA does RSA 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?

open/write/close...

>> RC4: nettle faster 30%
> Come one, no sane cryptographer will use arcfour.

RC4 is used in TLS.

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

I disagree on that. When designing a system, you design the architecture
on the high level and you don't care about the implementation. You may
have a crypto component, but you don't care if this is libgcrypt, libcrypto,
or libtomcrypt. It's just a component of your design. If libgcrypt wants to
enforce policies in my design, I replace it with a component that follows
the policies I set.

If my design consists of:

* an http client
* an http library that does HTTPS and compression
* a TLS library
* a crypto library
* a compression library

You don't want the http client to even know it is using that crypto or
compression library. It shouldn't care.

regards,
Nikos




More information about the Gnutls-devel mailing list