nisse@lysator.liu.se (Niels Möller) writes:
Hi,
Nikos Mavrogiannopoulos have been looking into support for Galois Counter Mode (GCM), see http://www.cryptobarn.com/papers/gcm-spec.pdf
Hi! NIST Has some other links for it:
http://csrc.nist.gov/groups/ST/toolkit/BCM/modes_development.html
My understanding of GCM is that the main point is a new MAC function which allows efficient hardware implementation. As far as I see, there's no clear advantage of using GCM instead of plain CTR mode combined with the same MAC function (applied to the plaintext).
Shouldn't you MAC the ciphertext? That's the proved secure approach.
- Naming: Is "gmac" a good enough name? Or "ghash" (the name of the primitive which takes a key and two inputs, in the paper)? Or do we need something more verbose, like galois_mac or gmac128 or so?
The name GMAC is well established:
http://en.wikipedia.org/wiki/Galois/Counter_Mode
- Specification: It's not entirely clear to me how the spec is to be interpreted when one of the input strings is empty. The most reasonable interpretation would be that there should be zero blocks to process (n or m equal to zero). This requires some bending of the notation in equation (2), for example, with m = 0, n = 1, we should have
If this is a real problem with latest specification, it might make sense to bring this up somewhere.
Interface: I think the basic use case with empty second input should be just like other MAC:s,
struct gmac_ctx;
/* Key size fixed to GMAC_KEY_SIZE == 16 */ void gmac_set_key(struct gmac_ctx *ctx, const uint8_t *key);
void gmac_update(struct gmac_ctx *ctx, unsigned length, const uint8_t *data);
void gmac_digest(struct gmac_ctx *ctx, unsigned length, uint8_t *digest);
The context struct and the set_key function is essential to be able to do any optimizations using key-dependant tables.
But then we need a function to mark the end of the first input and the start of the second. Name for that one?
void gmac_next(struct gmac_ctx *ctx);
This will pad the current input to a block boundary, and switch to using a different length counter.
How about gmac_authenticate?
Further, I'm wondering if some other authenticating MACs cannot process data in parallell, which would argue for an interface like this:
struct gmac_ctx;
/* Key size fixed to GMAC_KEY_SIZE == 16 */ void gmac_set_key(struct gmac_ctx *ctx, const uint8_t *key);
void gmac_update(struct gmac_ctx *ctx, unsigned length, const uint8_t *data);
void gmac_digest(struct gmac_ctx *ctx, unsigned length, uint8_t *digest);
void gmac_authenticate(struct gmac_ctx *ctx, unsigned length, const uint8_t *data);
Or something.
/Simon