3

In my opinion, it's not a good idea to use (symmetric/asymmetric) keys as Additional Authentication Data (AAD) in GCM as AAD is only authenticated but not encrypted. The key will be protected from modification but will not be confidential anymore. Is my understanding correct? (But maybe using a public key as AAD would be okay?)

Another side question is that, could the output of GCM, authentication tags, be referred to as digest?

kelalaka
  • 48,443
  • 11
  • 116
  • 196
HY Lin
  • 31
  • 2
  • 2
    (Fun fact: if anyone is surprised by this question, this is exactly what DLMS / COSEM does. In that case the key is not transmitted, so it's not unsafe, but it does not make sense either) – Conrado Apr 06 '21 at 18:47

1 Answers1

1

Yes, we don't send the keys directly. One must keep the keys secret, all the time!

Instead, we send the key with a public key cryptosystem like RSA-KEM or better apply key agreement like Diffie-Hellman Key Exchange (DHKE) and better use Elliptic Curve version (ECDH). If you looking at some existing libraries look at libsodium or the age libraries for existing good implementations.

AAD is not mean to be secret, rather open and can be a part of the protocol like the record number, etc. It is additional information incorporated into the authentication tag calculation. Thus any change in AAD will be detected.

Digest commonly referred to as keyless hash, the GHASH, on the other hand, uses a 128-bit key to derive the authentication tag. If you insist, you can use it as a keyed hash function, too. But rather prefer HMAC instead of GHASH.

kelalaka
  • 48,443
  • 11
  • 116
  • 196
  • 1
    It can be a decent idea to include a one-way hash (eg Blake3) of the key in the AAD, to provide key-commitment. That's not always a desired property though, it depends on the use. But it's safe: it's infeasible to find the key from the hash output, and it's infeasible to create the same hash output (and thus AAD, and thus tag) without knowing the key. If indistinguishability is needed one can instead use the key as the IV of a MAC, with the message as the key of the MAC, and then stuff the output in the AAD or ciphertext. Blake3 or HMAC-SHA2 work fine there. – SAI Peregrinus May 06 '21 at 14:18
  • @SAIPeregrinus What do we expect from the receiver with the key commitment? To test the correctness of the exchanged key? – kelalaka May 06 '21 at 14:32
  • Correc. AES-GCM and ChaCha20-Poly1305 aren't natively key committing, so it's possible to find messages (with tags) that successfully decrypt under more than one key (to different plaintexts, of course.) This post is a good easy explanation, and links the original paper. – SAI Peregrinus May 06 '21 at 16:36
  • @SAIPeregrinus it is well used in the partition oracle attack – kelalaka May 06 '21 at 16:40
  • Yep, that too. Though partition oracles are mostly only useful for keys derived from low-entropy input like weak passwords. The KDF input from ECDH or RSA-KEM should be high entropy, so partition oracles wouldn't matter there. – SAI Peregrinus May 06 '21 at 17:04
  • @SAIPeregrinus yes, the authors already told that and they worked on the pwnded passwords. I've looked, however, failed to find non-hashed passwords. Good passwords are the secure form that attacks and even there should be a mechanism that prevents multiple requests for the same. – kelalaka May 06 '21 at 17:07