[Top][All Lists]
[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
- Re: restrict qualifier and C++., (continued)
- Re: restrict qualifier and C++., Bruno Haible, 2011/04/10
- Re: restrict qualifier and C++., Nikos Mavrogiannopoulos, 2011/04/11
- memxor [was: restrict qualifier and C++.], Eric Blake, 2011/04/11
- Re: memxor, Bruno Haible, 2011/04/11
- Re: memxor, Nikos Mavrogiannopoulos, 2011/04/12
- Re: memxor, Bruno Haible, 2011/04/12
- Re: memxor, Simon Josefsson, 2011/04/12
- Re: memxor, Nikos Mavrogiannopoulos, 2011/04/12
- Re: memxor, Simon Josefsson, 2011/04/12
- Re: memxor, Nikos Mavrogiannopoulos, 2011/04/12
- Re: memxor,
Simon Josefsson <=