nisse at lysator.liu.se
Tue Dec 10 20:53:58 CET 2013
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
struct md5_ctx ctx;
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.
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
More information about the Gcrypt-devel