3

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.

vlp
  • 153
  • 7
Syrian Watermelon
  • 180
  • 9

2 Answers2

4

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...

K.G.
  • 4,617
  • 16
  • 32
  • 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}$ –  Oct 14 '13 at 00:27
  • 1
    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 06:41
-1

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.

e-sushi
  • 17,891
  • 12
  • 83
  • 229
Sebastian Mohr
  • 21
  • 1
  • 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