Simon Josefsson simon@josefsson.org writes:
http://csrc.nist.gov/groups/ST/toolkit/BCM/modes_development.html
I was just wondering what an "authoritative" reference would be.
Shouldn't you MAC the ciphertext? That's the proved secure approach.
I'm not familiar with those subtleties. Intuitively, it makes sense to me to MAC the cleartext, since that's closest to the *meaning* of the message. IIRC I picked up this (possibly outdated) advice from Applied Cryptography years ago.
If you can trick the receiver to use the wrong key or iv for decryption, then the receiver gets a garbled message, and if the MAC is applied to cryptotext rather than cleartext, the message will still apear to be authentic. So some care is needed when applying the MAC to ciphertext only (and I'm talking about the general combination of encryption and MAC, not the specific combination in GCM which I hope gets things right).
E.g., in ssh the mac is done as
mac = MAC(key, sequence_number || unencrypted_packet)
and replacing the unencrypted_packet by the corresponding ciphertext, with no other changes, would likely cause some trouble.
- 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:
Ok. gmac it should be then. Or perhaps gmac128, in case anyone is using 64-bit gmac or planning for larger sizes?
If this is a real problem with latest specification, it might make sense to bring this up somewhere.
I'd have to check the NIST version of the spec.
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.
I'm not sure I understand what you are referring to. At least for gmac, I don't think one can mix the two inputs, one must complete one before starting on the other. And I'd prefer that this restriction is clearly expressed in the interface.
Regards, /Niels