Simon Josefsson <[email protected]> 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:
>
> http://en.wikipedia.org/wiki/Galois/Counter_Mode
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
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
_______________________________________________
nettle-bugs mailing list
[email protected]
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
