# ECIES with ECDSA

I understand how ECIES work. I have a structure of message

[alices ephemeral public key, MAC tag, ciphertext]


I do not understand what I shoud do if I want to use ECIES with ECDSA. For example, each side in application network has static public/private key pair which are used for authentication. I want to know who send message. Which structure of message is more secure?

1. [alice ephemeral public key, alice static public key, ECDSA tag, ciphertext] where ECDSA tag = sign(ciphertext || Kmac, alice static private key)
2. [alice ephemeral public key, alice static public key, ECDSA tag, MAC tag, ciphertext] where ECDSA tag = sign(ciphertext, alice static private key)`

Or are these options similar?

Generally you need to use sign-then-encrypt. It is probably better to keep those separate.

So then the cryptographic message becomes: $$\text{ECIES}(P_B, M \| \text{ECDSA}(S_A, M))$$

where $A$ is alice, $B$ is bob, $P$ is a public key, $S$ is a private key, $\|$ is concatenation and $M$ is of course the message itself.

The generation of the ephemeral public key and authentication tag can be though to be part of $\text{ECIES}$, which requires a symmetric cipher and a mode of operation. This mode of operation could then be an authenticated mode of operation such as GCM with the authentication tag appended at the end of the encrypted message.

So the outcome of ECIES would be: $$\widetilde{P_A} \| C \| t$$

where the $\widetilde{P_A}$ is the ephemeral key of Alice (as part of ECIES), $C$ is the ciphertext containing the message and signature and $t$ is the authentication tag.

You may also want to include some kind of version number or domain parameter specification (but beware that an attacker may change those). You must make sure that you can determine which element is where in the data structure.

Notes:

• The option sign-then-encrypt-then-sign is more secure but also more obscure.
• It makes no sense to send a raw public key to $B$ as the receiver needs to trust the public key used for verification. Instead send a certificate with the public key included, and verify the certificate before extracting / using the public key.
• Using a container format such as CMS may make sense if you don't want to come up with a complete protocol specification / library yourself.

Warning: above explains how to implement sign-then-encrypt. It does not show how to implement a secure messaging protocol. For that replay attacks, impersonation attacks and many other attacks needs to be avoided.

• Beware redirection of a signed message to a different recipient. The protocol needs to bind the sender and recipient and message together in what is authenticated. Many historical protocols including PGP and CMS botched this, and it's not enough for the sender to choose sign/encrypt/sign or encrypt/sign/encrypt if the recipient is happy to accept sign/encrypt. So simply using CMS or S/MIME doesn't help. – Squeamish Ossifrage Jul 4 '18 at 1:26
• @SqueamishOssifrage Right, this was a direct answer to the given question. I've added a warning at the bottom. Same for CMS really; it can be used for secure messaging (e.g. SMIME) but CMS is then part of a complete solution. – Maarten Bodewes Jul 4 '18 at 10:08

Why do you need ECDSA? Do you need a third party to be able to verify the message's authenticity, or do you need only the recipient to be able to verify the message's authenticity?

Suppose Alice is trying to send a message to Bob, keeping it secret from Eve and preventing forgery by Mallory. Suppose Alice and Bob can a priori share public information about each other from the telephone book. It is sufficient for Alice to use an authenticated cipher under the secret that she and Bob share via static/static Diffie–Hellman key agreement. This is exactly the application in Whit Diffie and Martin Hellman's seminal 1976 paper on public-key cryptography.

If Alice's private key is $a$ and her public key is $A = g^a$, and likewise Bob with $B = g^b$, where $g$ is a standard base (say $2$, in $\mathbb Z/p\mathbb Z$ where $p$ is the 2048-bit RFC 3526 group #14 modulus, or $x^{-1}(9)$, in Curve25519), then Alice and Bob share the secret $$h = A^b = (g^a)^b = g^{ab} = g^{ba} = (g^b)^a = B^a.$$ If they derive $k = H(h)$ and use $k$ as the secret key for an authenticated cipher like NaCl crypto_secretbox_xsalsa20poly1305, then they can exchange messages under that secret key.

As long as the key is secret to Alice and Bob, nobody else can learn information about the content of messages transmitted with the authenticated cipher. As long as the key is secret to Alice and Bob, nobody else can forge messages that are verified by the authenticated cipher. Only Alice and Bob can verify messages—which, for private the authenticity of messages, is all you need.

There may be more to the story: compromising the long-term key $a$ or $b$ would allow an adversary to retroactively decrypt all past messages; to prevent that we need a protocol that allows the parties to promptly erase their keys. (This is sometimes called ‘forward secrecy’, a glib term that sweeps under the rug exactly when or how promptly the keys are erased.) But ECIES with static keys, or static ECIES composed with ECDH, has the same vulnerability to compromise of long-term keys.