2
$\begingroup$

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?

$\endgroup$
4
  • $\begingroup$ I'd prefer hashing Cx before using it as key, but that's not a big issue. $\endgroup$ Jul 5, 2013 at 20:21
  • $\begingroup$ 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? $\endgroup$ Jul 5, 2013 at 22:23
  • 2
    $\begingroup$ 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. $\endgroup$ Jul 5, 2013 at 22:50
  • 1
    $\begingroup$ 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$). $\endgroup$ Jul 6, 2013 at 12:17

1 Answer 1

1
$\begingroup$

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.

$\endgroup$

Your Answer

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

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