bug-gnulib
[Top][All Lists]
Advanced

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

Re: [bug-gnulib] hmac-md5


From: Bruno Haible
Subject: Re: [bug-gnulib] hmac-md5
Date: Wed, 5 Oct 2005 15:08:29 +0200
User-agent: KMail/1.5

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.

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.

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 };

> 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.

> 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.

> 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.

Bruno





reply via email to

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