[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