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