benchmarks

Nikos Mavrogiannopoulos nmav at gnutls.org
Tue Dec 10 13:39:19 CET 2013


On Tue, Dec 10, 2013 at 11:15 AM, Werner Koch <wk at gnupg.org> wrote:

>> Well, I really want to think that it is also about collaboration.
> Right, I thought about the same lines but back then Niels decided to
> compile his own library without the need to comply to the strict GNU
> rules.  Thus he was able to use all kind of code while I was not.  A
> decade or more ago I had to reject Brian Gladman's offer to use his code
> due simply due to the CA requirement.  Latter then the GNU project seems
> to have concluded that CAs are not important anymore unless they are
> already in use.  The effect was that GNUTLS silently started to use
> Nettle instead of helping to convince the GNU towers to drop the CA
> requirement for Libgcrypt.

I thought that this was done quite vocally :) There was quite a long
discussion in this list about the issues I had back then, that if I
remember well were (a) libgcrypt could not be used in setuid
processes, and (b) that it was much slower -more than 2x- than openssl
(and nettle). The conclusion of that discussion was that libgcrypt
wouldn't change. I now understand that (b) was because you were
strictly following the gnu rules, but that provided no comfort to me
who was seeing gnutls being at the bottom of any benchmark. That's why
I switched to nettle and as it is now we are more than 2x faster
compared to openssl in public key operations.

>> While I understand that everyone has a different agenda on the things
>> that need to be done, schedules etc., a compromise that will benefit
>> everyone may be possible.
> Well, you removed all support for Libgcrypt from GNUTLS.  If you want to
> use it again, you only need to add that layer again.

I removed it because I changed the internal API and libgcrypt support
would be incomplete (gcm was missing at the time). I don't think it is
would be trivial to re-add, but it is not hard either. Nevertheless,
even if such a switch would be possible today, it would solve nothing,
as now we have some few parts that libgcrypt is better than nettle,
and other parts which nettle is better than libgcrypt. My
argumentation for the merging was with the intention to have the best
implementations of each library merged.

regards,
Nikos



More information about the Gcrypt-devel mailing list