# Is this ECC encryption key sharing method okay?

Is this encryption key sharing okay to use? Or is much better to use ECIES?

$G$ = base point
$a$ = Alice’s private key
$b$ = Bob’s private key
$A = aG$ = Alice’s public key
$B = bG$ = Bob’s public key
$C_x$ = x coordinate of $C$

Alice and Bob share an AES key:

• Alice makes $C = aB$
• Bob makes $C = bA$
• The common encryption key is $C_x$

I can follow and have implemented ECIES. But in the above method the common key can be computed locally leading to shorter message transmissions. This could be a significant savings if most messages are short. (I would use counter mode with the IV sent along with the ciphertext.)

But is there a problem using the above method?

-
I'd prefer hashing Cx before using it as key, but that's not a big issue. –  CodesInChaos Jul 5 '13 at 20:21
Thank you CodesInChaos. Hashing sounds good. I was already planning on providing an IV for AES in counter mode. I will hash Cx and the IV. Message length remains small. But anyone, is the method less secure than ECIES? –  Peter Butler Jul 5 '13 at 22:23
The key being used here is always the same which means that you're basically doing ECDH followed by regular symmetric encryption. Thus you need to be careful as to how much data you're going to encrypt with your key. –  Alexandre Yamajako Jul 5 '13 at 22:50
Also, you should take care of using different IVs for both directions ... or better derive different keys (by using a KDF after calculating $C_x$). –  Paŭlo Ebermann Jul 6 '13 at 12:17

## 1 Answer

To start things: Don't roll your own crypto.

What you're proposing is using standard static Diffie-Hellman for key-exchange, which by itself is a bad idea, as it will always result in the same key for each communcication between Alice and Bob. The key by itself should be safe, but as soon as it's broken all messages are as well. So if either the sender's public key is broken or the derived DH key is learned all communications are broken, whereas ECIES will still be safe (if the DH secret is learned one message is broken, if the public key is broken all messages to that person are broken and not all messages).

Next, ECIES provides authenticity and secrecy, meaning that if the message is altered in transit ECIES will output an error on decryption, using plain CTR + random IV doesn't provide this property.

So it's for these reasons (don't roll your own crypto, avoid static keys, think of authentication) that ECIES is the better choice.

-