benchmarks

[Niels Möller]

Werner Koch <wk at gnupg.org> writes:

> But the whole discussion is moot; Nettle and Libgcrypt are very
> different and there is no need to merge them.

I imagine that it would be technically possible to write libgcrypt so
that parts of it is a thin layer on top of Nettle. For a simple example,
in libcgrypt/cipher/md5.c, either replace the transform function with a
call to _nettle_md5_compress (which is implemented in assembly on some
platforms, and somewhat internal).

Or write the internal (not visible in libgcrypt's ABI) MD5_CONTEXT as
something like

#include <nettle/md5.h>
typedef struct
{
  struct md5_ctx ctx;
  uint8_t digest[MD5_DIGEST_SIZE];
} MD5_CONTEXT;

and redefine _gcr_digest_spec_md5 to point to corresponding nettle
functions, or trivial wrappers if needed.

I see that there's some impedance mismatch, e.g.,
(init,write,final,read), vs (init,update,digest). I can't say if that's
a big deal, aesthetically or in terms of performance overhead.

Now, there may sure be good reasons why that's an undesirable change,
but I'd like to understand what the obstacles are. The advantage is
sharing of more low-level code. And if libgcrypt is faster than nettle
for some particular algorithm, we'd obviously want to get the faster
code into Nettle before changing libgcrypt.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.