[PATCH] Add CMAC mode (Cipher-based MAC)

Jussi Kivilinna jussi.kivilinna at iki.fi
Fri Nov 8 09:34:50 CET 2013


On 07.11.2013 09:59, Werner Koch wrote:
> On Thu, 31 Oct 2013 23:16, dbaryshkov at gmail.com said:
> 
>> Maybe we should just converge gcry_md_* and gcry_cipher_* spaces?
> 
> I would propose to add gcry_mac_* instead.  For a user of the library it
> is easier to use a dedicated set of functions for MACing than to figure
> out the right way to to this with gcry_cipher or gcry_md.  When I added
> HMAC (for my ssh implementation), I considered this but given that back
> then there was only one MAC in practical use, I used the hack with the
> HMAC flag.

I'm fine with this. So we'd be looking at adding gcry_mac_* interface with
CMAC, HMAC and GMAC modes. API might look something like this:

 /* mode = MAC mode, algo = depending on mode, either MD or cipher algo */
 gcry_error_t gcry_mac_open (gcry_mac_hd_t *h, int mode, int algo, unsigned int flags);

 void gcry_mac_close (gcry_mac_hd_t h);

 gcry_error_t gcry_mac_setkey (gcry_mac_hd_t h, const void *key, unsigned int keylen);

 /* reset buffer state (keep currently setkey) */
 gcry_error_t gcry_mac_reset (gcry_mac_hd_t h);

 /* GMAC needs IV */
 void gcry_mac_setiv (gcry_mac_hd_t h, const void *iv, unsigned int ivlen);

 /* name? write, authenticate ... */
 gcry_error_t gcry_mac_write(gcry_mac_hd_t h, const void *buf, size_t buflen);

 /* name? final, gettag (+checktag) ... */
 gcry_error_t gcry_mac_final(gcry_mac_hd_t h, void *tag_out, size_t taglen);

 /* Get mode/algo of handle */
 void gcry_mac_get_mode_algo(gcry_mac_hd_t h, int *mode_out, int *algo_out);

 /* Names for mac... CMAC_<cipher>, HMAC_<hash>, etc? */
 char *gcry_mac_algo_name (int mode, int algo, char *namebuf, int namebuflen);
 void gcry_mac_map_name (const char *name, int *mode_out, int *algo_out);

Comments?

-Jussi

> 
> Now with several MAC algorithms in practical use a dedicated set of
> MACing function might be useful.  It still does not solve technical
> problems but it will be easy to explain and in the long run easier to
> maintain.
> 
> Right, authenticated encryption is still separate and I can't see an
> easy way on how to merge that without giving up a clear separation
> between the functional blocks.  Eventually we will add a buffering layer
> on top of the existing functions which could the be used to do
> MAC+encrypt or encrypt+MAC in the various protocol dependent forms
> (e.g. for OpenPGP CFB plus a SHA-1 MDC).  But this is orthogonal to the
> existing building blocks.
> 
> 
> Salam-Shalom,
> 
>    Werner
> 




More information about the Gcrypt-devel mailing list