4
$\begingroup$

After looking at this bitcoin-related ECIES repo I believe the intention is that, at least in some cases, the recipient would know that the message is intended for them and use an secp256k1 public key that they know belongs to you to perform the key derivation process on their end. Even if that is not their intent, I am curious about the security implications of such a schema.

That is, a recipient of ECIES ciphertext data (containing an IV, AES ciphertext, and a HMAC), performs key derivation with a known, static sending public key and their private key. As is done in this library, they compute the diffie-hellman shared secret and use SHA-512 as a key derivation function. The first half of this has is used as an AEC-CBC decryption key, but before that the second half is used to authenticate the ciphertext with HMAC-SHA256.

Assuming all goes well they are confident of both the origin of the message (by virtue of the key derivation being successful and the HMAC authenticating the ciphertext) and of the data itself.

The primary issue I see with this schema is that that encryption/HMAC keys will be the same for any messages sent between the two parties. However, assuming the IV is chosen intelligently I believe this should be safe, though it removes any forward secrecy provided by using an ephemeral sending key.

Are there any other downfalls of this approach? Is this regarded as just a form of ECIES or is it possibly something different since the sending key is not ephemeral? (At the very least, Wikipedia seems to imply the key should be ephemeral.)

Finally, it seems to me that a saner way to achieve the goals of this library would be to generate an ephemeral key for the key derivation process, send that ephemeral public key with the cipher text, and include a signature with the known key either as a part of the message plaintext (to avoid the possibility of the public key being derived from the signature) or simply included with the ciphertext data. What trade-offs exists with this alternate approach?

Improve this question
$\endgroup$
2
  • 1
    $\begingroup$ Do you have a protocol description for that library. Because you've created a textual description, but a formal description is really preferred. For instance, it isn't mentioned if the IV is also included in the HMAC. If not, the protocol that the library implements is already broken. $\endgroup$
    – Maarten Bodewes ♦
    Jun 2, 2020 at 22:11
  • 1
    $\begingroup$ @MaartenBodewes No formal description, unfortunately, I was involved in an effort to port that code and we were just digging through the code itself. I can confirm that the IV is in the HMAC preimage, though. I believe it's the IV concatenated with the full AES ciphertext. I suppose for the purposes of this question I'm more concerned about the high-level protocol (though important low-level details would be good to know). I would be fine with an answer assuming that the IV and other similar things are handled well, though stating those kinds of assumptions would be a nice plus. $\endgroup$
    – thesquaregroot
    Jun 2, 2020 at 22:17

1 Answer 1

Reset to default
1
$\begingroup$

What trade-offs exists with this alternate approach?

Unless you need the non-repudiability you produce a larger ciphertext in a slower way for no interesting gain in security when signing and encrypting over using the static keys (apart from the "other downfalls" below).

Are there any other downfalls of this approach?

Indeed if now either of your long term secret is compromised all ciphertexts can be decrypted unlike in traditional PKE schemes where only one party has such a long-term secret.

Is this regarded as just a form of ECIES or is it possibly something different since the sending key is not ephemeral?

Technically speaking it doesn't fit the traditional signature of a public key encryption scheme because there the encryption isn't allowed to maintain state and obviously a sender secret can't be part of the public key. The most common name for this I know would probably be crypto_box (taken from NaCl's naming) which does essentially this. Academically speaking the correct name is "public-key authenticated encryption" because it is the public-key equivalent of authenticated encryption.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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