2
$\begingroup$

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

|improve this question|||||
$\endgroup$
  • 1
    $\begingroup$ Note that using GCM with random nonces, as you propose, gives people the heebie-jeevies. Since ECIES uses ephemeral per-message keys you're possibly safe in this one case, but you might want to stick to a counter nonce, or at least beware of carrying that assumption to other settings. $\endgroup$ – Luis Casillas Jul 17 '18 at 21:55
  • $\begingroup$ Yeah, using bytes from the hash of the shared key as the key and nonce now... seems to be the popular option. $\endgroup$ – Erik Aronesty Jul 19 '18 at 15:22
  • $\begingroup$ Random nonces is a lot safer than sequential nonces. The people for whom it has problems aren't looking at whole systems. Sequences are safer, but... how do you custody the sequence? Random numbers generally have operating system and sometimes hardware custody, and a 128 bit nonce offers enough collision detection to transmit yottabytes before there's a significant problem. Only sneaky gotcha is that the openssl lib will truncate your nonce to 96 bits unless you tell it not to. $\endgroup$ – Erik Aronesty Aug 14 '18 at 12:55
8
$\begingroup$

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.

|improve this answer|||||
$\endgroup$
  • $\begingroup$ That paper was not about AES GCM $\endgroup$ – Erik Aronesty Jul 17 '18 at 21:59
  • 1
    $\begingroup$ @ErikAronesty AES-GCM uses AES. My point is not that this specific paper demonstrates an attack on your specific application. Your specific application doesn't matter enough for anyone to publish a paper at a reputable cryptography conference demonstrating an attack. My point is that you have violated the security contract of AES (and anything built out of it like AES-GCM), and the paper shows an example of what goes wrong when you skimp on your contractual obligations. $\endgroup$ – Squeamish Ossifrage Jul 17 '18 at 22:03
  • 4
    $\begingroup$ @ErikAronesty NOOOOOOOOOO! EFAIL! $\endgroup$ – Squeamish Ossifrage Jul 17 '18 at 22:14
  • 1
    $\begingroup$ @ErikAronesty If you violate the security contract of the primitive or invent a bespoke composition of it, you are asking for a shot in the foot. If you want public-key encryption, you should use an existing construction that is credibly advertised to guarantee IND-CCA2/NM-CCA2. Tweaking it to replace a MAC of the message by a hash of the key is asking for trouble. $\endgroup$ – Squeamish Ossifrage Jul 17 '18 at 22:17
  • 1
    $\begingroup$ I'm not sure what @ErikAronesty means by "SHA3 on the key", but shouldn't it be OK (or even better) to use AES-GMAC with the key derived by the KDF, instead of using separated encryption and MAC schemes as specified by ECIES? $\endgroup$ – Conrado Jul 18 '18 at 11:53
1
$\begingroup$

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.

|improve this answer|||||
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.