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?