[email protected] (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 _______________________________________________ nettle-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
