bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: memxor


From: Simon Josefsson
Subject: Re: memxor
Date: Wed, 13 Apr 2011 07:36:07 +0200
User-agent: Gnus/5.110016 (No Gnus v0.16) Emacs/23.2 (gnu/linux)

Nikos Mavrogiannopoulos <address@hidden> writes:

> On 04/12/2011 03:50 PM, Simon Josefsson wrote:
>
>>>> I'm surprised the gnulib memxor ends up being used by GnuTLS at all.
>>>> Nikos, shouldn't the Nettle implementation be used instead?  Is this a
>>>> question of the GnuTLS (gnulib) memxor symbol replacing the memxor that
>>>> is shipped with Nettle?  Maybe the solution is to fix the Nettle
>>>> namespace.
>>> GnuTLS uses gnulib memxor, because it might be compiled either with
>>> nettle or libgcrypt.
>> But the performance critical uses of memxor is only through Nettle,
>> isn't it?  And by accident Nettle ends up using the gnulib memxor
>> instead of its own.  That could be fixed by either changing Nettle's
>> namespace, or do an '#define memxor gl_memxor' inside GnuTLS.
>
> I don't quite understand your point. Is it that gnulib doesn't need
> a fast version of memxor?

Yes that is what I'm considering.  Gnulib just uses memxor for HMAC-MD5
and HMAC-SHA1 and these interfaces require that you give it the entire
buffer at the same time:

int
hmac_md5 (const void *key, size_t keylen,
          const void *in, size_t inlen, void *resbuf)
int
hmac_sha1 (const void *key, size_t keylen,
           const void *in, size_t inlen, void *resbuf)

This interface is not useful for anything speed critical anyway.  And as
far as I can tell, GnuTLS is not using this interface either.  So there
is no need for a fast memxor in gnulib.

> I mentioned that example with the effect it had on gnutls once I
> replaced the memxor version in nettle with the optimized one.

I'm confused.  Nettle already has an optimized memxor?  At least in my
nettle CVS code.

> GnuTLS can indeed solve its requirements alternatively, but I
> suggested the fix we used in nettle, in case other projects might be
> interested (since memxor.c was in gnulib I thought this was the case).

We could add a fast memxor to gnulib if you write the patch and work out
the legal aspect.  Then Nettle could copy the file from gnulib, and
possibly others too, for code re-use.

The immediate problem as I see it is that gnulib's memxor replaces the
efficient Nettle memxor, which makes Nettle slow.  Fixing that is easy:
just remove the inefficient gnulib memxor from GnuTLS, or at least
rename it so that it doesn't replace Nettle's code.

/Simon



reply via email to

[Prev in Thread] Current Thread [Next in Thread]