7

Reading the ECIES algorithms (and elgamal in general), the general wisdom is to use a KDF and MAC on the shared secret before using it for encryption of ciphertext.

I suspect, however, this was because the encryption used was XOR (for data sizes that were smaller than the original).

If you're using AES GCM with a random iv, I don't see the value of the KDF on the shared secret.

For some protocols, you don't want users decrypting the ciphertext with the wrong key (chosed ciphertext attacks)... so mac'ing the key could be helpful.

But with a random IV, chosen ciphertext seems to be useless here as long as you otherwise follow standards with the shared secret and symmetric portion of the algorithm.

And with GCM, the mac portion of ECIES also seems not useful. I think, maybe, deferring to better-tested AES/GCM for the authentication seems to be the better bet.

See: https://en.wikipedia.org/wiki/Integrated_Encryption_Scheme

Erik Aronesty
  • 470
  • 2
  • 15

2 Answers2

13

Do not skip the KDF step.

The output of an ECDH key agreement, as used inside ECIES, is some encoding of a point on a curve. Usually the encoding is highly structured and not uniformly distributed among bit strings. For example, it might be the encoding of any element $x \in \mathbb Z/(2^{255} - 19)\mathbb Z$ such that $x^3 + 486662 x^2 + x$ is square, or it might be the encoding of a pair of elements $x, y \in \mathbb Z/(2^{256} - 2^{32} - 977)\mathbb Z$ such that $y^2 = x^3 + 7$.

The security contract of a pseudorandom permutation family like AES is that the key must be uniformly distributed among bit strings. If you violate that contract, you might get in trouble with our friends Alex Biryukov and Dmitry Khovratovich.

Will the specific structure of the encoding you're using of points on the curve you're using get you in trouble with AES in particular? I don't know, but that's not something I would bet on even if I were a betting bird—it voids the security contract and lands you in uncharted territories where few cryptographers have set foot and no rewards are expected to be found.

If you have voided the contract of AES by using a nonuniform distribution on your keys, do not expect security.

Squeamish Ossifrage
  • 49,816
  • 3
  • 122
  • 230
3

It's now generally considered slightly better to use AES-GMAC than to use an HMAC during the key derivation step. For example: this is what Apple uses in its Secure Enclave.

While a hash of the key satisfies the "no structure" contract of an AES key input - using a KDF also performs other useful functions.

The KDF can produce additional bytes for use in AES-GCM's IV. A standard KDF provides flexible choices of hash algorithms to and a flexible amount of bytes to support the symmetric encryption.

In the end, this reduces the amount of data you need to transmit/store when doing encryption, and shifts more code to better tested and standardized libraries.

In summary for interchangeability with the most systems:

ECIES == ECDH -> X93KDF(SHARED_KEY, AES_LEN+IV) -> AES_GCM()

Using the public key in the auth tag of the GCM step can, additionally, provide some malleability defense.

Erik Aronesty
  • 470
  • 2
  • 15