1

I'm using ECDH (X25519 or X448) between two parties that already have a shared secret. Because of the shared secret, I don't need any public key signatures to prevent man-in-the-middle attacks, authenticated encryption does that just fine. The purpose of ECDH is to provide perfect forward secrecy: I want past captured communications to remain secret even if the shared secret is somehow leaked (which would only allow man-in-the-middle and other impostor attacks if leaked).

One thing I'm worried about is that ECDH is heavily dependent on the quality of the random number generator. Nothing else in my crypto requires good random numbers apart from creating the already agreed shared secret (but it can be created in a machine that has lots of entropy and maybe a hardware true random number generator in addition to that entropy). So ECDH could create a weakness: if the random numbers are poor, an attacker could be able to predict the ephemeral key, without even having to know the shared secret.

So I'm planning that maybe the private key used in ECDH could be created, not from pure (pseudo)random numbers, but from a combination of (pseudo)random numbers and the already agreed shared secret.

So specifically, I'm planning that the private key used in X25519 or X448 would be:

prk = hkdf_sha512_extract(salt=csprng_generate(length=64), ikm=shared_secret)
ecdh_private_key = hkdf_sha512_expand(prk=prk, info="ecdh-private-key", length=ecdh_private_key_len)

(with suitable postprocessing as dictated by X25519 and X448 too, omitted from the example)

This would combine the shared secret with pseudorandom data. The theory is that an attacker would need to predict both the output of the CSPRNG, and also the shared secret, to be able to predict the private key. So my theory is that this would increase security instead of reducing it.

Is my theory correct? Or does usage of HKDF to create ECDH private keys have some weakness I did not foresee? Is having the only randomness in the salt, with no randomness in input keying material, adequate?

juhist
  • 1,643
  • 1
  • 13
  • 18

0 Answers0