Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I was wondering whether it is safe to use the same DH or ECDH key pair in more than one key agreement, particularly if these public keys are in a public registry. These public keys could be used by your counterparts (who also have their public keys in the same registry) to agree on a secret used to send you a message, even when you're not online. A user's public (EC)DH key is changed each time s/he goes online.

Is that system safe? Does reusing the same public key makes it more easy to solve its DLP?

EDIT : When I meant to use a public key in more than one key exchange, I meant it will be used with different counterparts.

share|improve this question
up vote 2 down vote accepted

Using DH when both sides have static public keys (always send the same message when running the DH protocol) doesn't make DLP easier. It does increase the value of the secret key.

There are some things to worry about. If the DH shared secret or one of the secret keys is compromised, the compromise is complete. This is mitigated if the static public keys are replaced often.

In ordinary DH, the shared secret is a one-time secret. With static public keys, you have a multiple-use secret. You need to be very careful when using this key.

You should also be aware that DH where only one side has a static public key is essentially equivalent to ElGamal encryption...

share|improve this answer
So, by having "static" public keys, I loose the perfect forward secrecy. But by rotating keys on each user connection, I still have (not perfect) forward secrecy. Is that right? – Syrian Watermelon Oct 13 '13 at 21:22
You also become subject to chosen-ciphertext attacks and malleating attacks. $\hspace{1.63 in}$ – Ricky Demer Oct 14 '13 at 0:27
I don't think there's a clear and accepted distinction between forward secrecy and perfect forward secrecy. I wouldn't expect anyone to call what you have forward secrecy. But as I said, the problem of not having forward secrecy (a not very descriptive term) is mitigated by rotating keys. – K.G. Oct 14 '13 at 6:41
Ok thanks @K.G. :) – Syrian Watermelon Oct 14 '13 at 9:16

Why don't you just use RSA? It's the common solution for that problem. User $a$ sends a message to $b$, signs it with $SK(a)$ and encrypts it with $PK(b)$. Read more at the Wikipedia article about DH.

The main problem I see (even when using RSA) is: how to verify that the published public key really belongs to the intended recipient and not an attacker. Trust on first use, PGP-like key signing or some kind of central authority. Which raises the question: what does the network look like? That should also be taken into considderation.

share|improve this answer
IMO RSA is inferior for most applications. 1) Its private key operation is slower, especially at high security levels. 2) It's size overhead is bigger, both for the encrypted key and for the public key. (32 bytes vs ~300 bytes). 3) It can't authenticate to the recipient without signing (deniable authentication) => I'd only use RSA for legacy application, or when you need its special properties (e.g. blind signatures) – CodesInChaos Oct 14 '13 at 10:55

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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