Bruno Haible <[EMAIL PROTECTED]> 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
_______________________________________________
bug-gnulib mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-gnulib
