2
$\begingroup$

I have two parties:

Alice who has a static public key PA

Bob who has a static public key PB

A static shared secret (S) is computed with ECDH.

Encryption and MAC keys are computed with a key derivation function: (KENC, KMAC) = KDF(S)

The two parties send messages to each other, encrypted and authenticated respectively using KENC and KMAC. The encrypted messages are also stored in this encrypted form.

My question: how secure is using these static derived keys (KENC and KMAC) in the long run if I want encryption and authenticity, but I do not care about forward secrecy.

$\endgroup$
2
  • 2
    $\begingroup$ This is basically what NaCl's crypto_box does. $\endgroup$
    – SEJPM
    Jan 26, 2017 at 11:14
  • $\begingroup$ You may want to look up the NIST document on (EC)DH. In there static-static DH actually does use a random component for deriving keys. This won't provide you forward secrecy of course, but it's at least more secure than just keeping the same key. $\endgroup$
    – Maarten Bodewes
    Jan 26, 2017 at 14:28

1 Answer 1

3
$\begingroup$

This usage is theoretically sound assuming you do not desire Perfect Forward Secrecy, but will exacerbate attacks on the block cipher by providing potentially very many messages encrypted under the same key, and will exacerbate side channel attacks by repeatedly deriving the static secret (allowing many chances to catch small fragments and re-assemble).

Consider also that if users A and B have a static secret, then party C who obtains either A or B's key, can recover the shared secrets in both directions, and thus impersonate either party, to either party.

Edit: Another notable attack: party D, who does not have either key but can capture packets, can replay any message that A or B sent, and they can send it in either direction at any time, of course the keys will still be valid so the message will appear authentic. This can be just as effective as a full break in many cases.

$\endgroup$
2
  • 2
    $\begingroup$ As A and B use not just static but also identical keys that it is impossible to distinguish between messages send by A or B. So you'd need additional security measures to make sure that messages from A are not replayed back to A. $\endgroup$
    – Maarten Bodewes
    Jan 26, 2017 at 14:26
  • 1
    $\begingroup$ Yes, I'm sure there's another subtle attack I've failed to mention as well. Of course rolling your own crypto inherently features this danger of overlooking subtle but fatal details. $\endgroup$ Jan 26, 2017 at 15:35

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.