bug-gnulib
[Top][All Lists]
Advanced

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

Re: hmac-md5


From: Simon Josefsson
Subject: Re: hmac-md5
Date: Wed, 05 Oct 2005 15:58:00 +0200
User-agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux)

Bruno Haible <address@hidden> writes:

> Simon Josefsson wrote:
>> This is the HMAC-MD5 module, that depends on the MD5 module.
>> What do you think?  Ok to install?
>>
>> The reason I'm using hmac.h instead of hmac-md5.h is that I think
>> hmac.h should contain the prototype for hmac_sha1 too, eventually.
>> That would be a separate module with a hmac-sha1.c implementation,
>> though, but it would share the hmac.h header.
>
> This module is welcome. I like to see an interface that is easier to use
> than md5.h.

Yes, I found md5.h a bit cumbersome too.  Note that HMAC-MD5 is not
the same as MD5, I may be reading you incorrectly but I get the
impression that you think hmac-md5.c is a simpler interface for md5.c;
it is not.  Hmac-md5 implement the algorithm in RFC 2104, which do use
md5, but is very different in what it is used for.

> Regarding the different digest algorithms: It appears that most programs
> which offer one of these algorithms also offer other algorithms. MD5, SHA-1,
> etc. (md5sum/sha1sum, gpg --digest-algo, etc.) Therefore I would put
> hmac-md5.c and hmac-sha1.c into the same gnulib module. And then a single
> header file hmac.h will do.

Would work, but not if the sha1 stays under GPL.  I need LGPL'd crypto
libraries.  We can change this later, if I can re-license sha1 as
LGPL.

> You can then also add a function that takes the digest algorithm as a
> parameter:
>
>   enum { HMAC_MD5, HMAC_SHA1, HMAC_RIPEMD_128, HMAC_RIPEMD_160 };

Yes, this will come later, I'm submitting the functions as needed
one-by-one now.

>> I am unsure about the prototype here too.  I'm using 'void*', but I
>> considered using 'uint8_t*' because HMAC-MD5 is byte-oriented.
>
> I would prefer 'uint8_t*', because the contents of the memory block is
> not completely opaque: The result of md5 depends on the encoding of
> the values. If, for example, every byte is XORed with 0x77, the result
> will be different. Unlike, for example, memcmp, memcpy, hash_insert, ...
>
> For 'uint8_t', you can use the gnulib module 'stdint'. Or use 'unsigned char'
> if you don't want to.

The problem with uint8_t is that sooner or later it ends up in public
API's, and while I'm using ax_create_stdint_h.m4 in my projects,
something like it is not yet part of gnulib.

One problem with 'char*' (and 'unsigned char*') is that it isn't
guaranteed to be 8 bytes.  So it could be larger, e.g., 16 bytes.  I
have no idea whether the code will work at all in that case.

Further, using uint8_t in hmac-md5 and 'void*' and 'char*' in md5
(yes, it uses both) seem rather inconsistent.  Is it likely that we'll
be able to change the glibc API to use uint8_t?

>> It would be nice if the md5 module contained a '#define MD5_BLOCK_SIZE
>> 64' and '#define MD5_DIGEST_SIZE 16' so I don't have to hard code
>> those numbers.  Should I submit a patch?
>
> Yes, I think this would be useful in glibc's source code too.

I fixed this in gnulib (not synchronized to glibc cvs ), and
submitted <http://sourceware.org/bugzilla/show_bug.cgi?id=1423>.

>> Note that there are no hooks for using libgcrypt instead.  That will
>> came later on.  First I need the crypto functionality inside gnulib,
>> then I can write a layer on top of that to multiplex the functionality
>> to either the gnulib modules or to libgcrypt.
>
> Yes, this seems like the right approach.

Yes, that code is running locally here now.  Will submit later...

Thanks,
Simon




reply via email to

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