ECDH between identical public keys

We are using libsodium and regarding exchanging secrets we would like to use the so-called crypto_box (https://libsodium.gitbook.io/doc/public-key_cryptography/authenticated_encryption). Under the hood, ECDH is used. The problem is that it can be possible as well, that I encrypt this secret by myself. In that case, Alice and Bob would be the same person and the public keys will not differ. Is that a security problem, because DH was not designed for this kind of use case?

There's an elegant argument that the computational Diffie-Hellman problem with repeated keys is no harder than the generic computational Diffie-Hellman problem.

We write $\mathrm{CDH}(G,aG,bG)$ for the generic computational Diffie-Hellman problem of computing $abG$ given $g$, $aG$ and $bG$ and $\mathrm{rCDH}(G,aG)$ for the repeated key computational Diffie-Hellman problem of computing $a^2G$ given $G$ and $aG$. Suppose that we have an advantageous way of solving $\mathrm{rCDH}$ and a $\mathrm{CDH}$ instance $\mathrm{CDH}(G,A,B)$. I can compute $A+B=(a+b)G$ and $A-B=(a-b)G$ and call my $\mathrm{rCDH}$ solver twice to get $\mathrm{rCDH}(G,A+B)=(a^2+2ab+b^2)G$ and $\mathrm{rCDH}(G,A-B)=(a^2-2ab+b^2)G$. Subtracting these two return values gives me the point $4abG$ and scalar multiplying by $4^{-1}\mod \ell$ where $\ell$ is the group order gives $abG$ and thus solves the $\mathrm{CDH}(G,A,B)$ problem.

I would never recommend using crypto_box as it has a number of limitations:

• It doesn't provide sender authentication, only message authentication, because the public keys are not included in the key derivation, as recommended in RFC 7748.
• It uses HSalsa20 for key derivation. Firstly, this causes the above problem, which was also an issue I reported in Monocypher. Secondly, HSalsa20/HChaCha20 should really be supplied a uniformly random key, whereas shared secrets are not.
• It uses XSalsa20-Poly1305 instead of XChaCha20-Poly1305. This isn't a security problem as both are secure, but (X)ChaCha20 is far more popular now, and ChaCha20 is slightly more efficient and has better diffusion.

Instead, you can do the following:

1. Use crypto_box_keypair to randomly generate an ephemeral key pair (ephemeralPrivateKey, ephemeralPublicKey).
2. Use crypto_scalarmult to perform a key exchange between your privateKey and ephemeralPublicKey. This produces sharedSecret.
3. Erase the ephemeralPrivateKey (e.g. using sodium_memzero or the equivalent in your programming language).
4. Derive an encryption key for XChaCha20-Poly1305 using crypto_generichash, with sharedSecret || your publicKey || ephemeralPublicKey as the message.
5. Encrypt the plaintext using XChaCha20-Poly1305 with the above key and a randomly generated nonce.
6. Prepend ephemeralPublicKey and the nonce to the ciphertext.

If the crypto_kx API is accessible, that does key derivation similarly for you, just use crypto_kx_client_session_keys to derive one key rather than two. There's no need to use crypto_kx_server_session_keys because there's no second party involved.

This provides sender authentication, uses a hash function for key derivation (HKDF or the personalised BLAKE2b KDF API could be used instead), derives a unique key each time, and uses a newer AEAD.

Documentation

• crypto_box
• crypto_scalarmult
• crypto_generichash
• crypto_kx