I'm deriving a shared secret using ECDH with Ed25519 keys. According to the specification (page 5), the shared secret then can be any valid Curve25519 public key, i.e. any valid 32 bytes. My environment is such that I need to map this shared secret to being only 31 bytes long. A simple solution to this would be to just perform e.g. SHA256 on it and take the leftmost 31 bytes. I am wondering however, is the hashing here mandatory? Would simply dropping a byte from the shared secret be appropriate here as well?

  • $\begingroup$ Depending on the context where you want to use the ECDH output, you may want to derive the result by hashing in the DH shares as well. i.e. $k = H(g^{xy}, g^x, g^y)$ $\endgroup$ Commented Nov 16, 2022 at 11:45
  • $\begingroup$ I remember a dupe, couldn't find it. Hash is mandatory, the reason is simple; the point encoding is not random on EC. So, direct using it can cause unwanted attacks. Applying hash before it is a simple countermeasure to keep the input mangled.. $\endgroup$
    – kelalaka
    Commented Nov 16, 2022 at 14:12
  • $\begingroup$ Related: crypto.stackexchange.com/questions/9418/… $\endgroup$ Commented Nov 16, 2022 at 15:37

2 Answers 2


You should apply the hash. If one follows the specification there are only roughly $2^{251}$ possible shared secret values and there is a simple test to see if a putative 32 bytes represents a possible shared secret. This is because each shared secret is the $x$-coordinate an element of a roughly 252-bit elliptic curve group written in Edwards form and each possible $x$-coordinate appears in exactly two elements. Moreover we do not expect these possible shared values to be evenly distributed across 248-bit prefixes/suffixes/interfixes.

Although we expect each 248-bit prefix/suffix/interfix to be associated with 8 possible shared secret values, some will be associated with none and others with dozens. This introduces a testable bias into shared secret values that allows us to distinguish shared secret values with advantage.

If we are presented with two 248-bit values and told that one is a truncation of a Ed22519 shared secret and the other is a uniform random number, then for each of the pair we can easily count how many possible extensions to full secret values are possible. We then choose the value form the pair with the most possible extensions and we will be right more than half of the time. This is undesirable from a cryptographic point of view where even small biases can lead to major vulnerabilities. Note that this also applies to non-truncated shared secrets.

Note that pages 5 and 6 of the specification suggest applying Salsa20 to shared secret values to produce derived keys.

  • $\begingroup$ Thanks so much for your answer - two followup questions: How did you find that there are only ~2^251 shared secret values? I got the possibility of the full 32 bytes from Thereom 2.1's {Curve25519 secret keys} × {Curve25519 public keys} → {Curve25519 public keys} statement. To your point about the non-uniform distribution of shared secrets: Assume I have a cryptographic hash h that maps to 248 bit values directly. Taking a 248-bit prefix/suffix/infix and hashing that using h should circumvent the problem as long as h distributes hash values uniformly, correct? $\endgroup$
    – user80785
    Commented Nov 16, 2022 at 9:51
  • 1
    $\begingroup$ I've added some words about where I got 251 from. Truncating then hashing feels like needlessly throwing away entropy. A biased input to a uniform function will produce biased output, but if $h$ is a cryptographic hash function the bias should not be computationally detectable/testable. $\endgroup$
    – Daniel S
    Commented Nov 16, 2022 at 10:41

You should hash your secret. (In fact, you should not just hash it, but process it with a key derivation function such as HKDF that has been specifically designed for this purpose.) Doing so preserves the entropy of the ECDH shared secret better than simple truncation and makes the security of your system easier to analyze, as you can rely on the output of the KDF being computationally indistinguishable from a uniform random bitstring.

All that said, as I noted earlier in this answer to a related question, skipping the hashing and just truncating the shared secret is unlikely to be a disastrous mistake. In particular, removing a byte from the secret can only reduce its entropy by at most 8 bits.

As Daniel S notes, an Ed25519 public key has about 251 bits of entropy. Truncating it by one byte thus leaves you with at least 251 − 8 = 243 bits of entropy.

Is that enough? Honestly, I can't think of any purpose for which it wouldn't be. For all currently foreseeable practical purposes, even 128 bits of entropy is enough (yes, even against quantum computers). A 243 bit secret is $2^{243 - 128} = 2^{115}$ times harder to crack by brute force than that.

Ps. Of course the back-of-the-envelope security analysis above considers only resistance to brute force guessing attacks. To be thorough, we should also consider the possibility of structural weaknesses, such as the possibility that the rest of your cryptosystem might somehow be secure except when its secret key happens to be a truncated Ed25519 shared secret.

In this particular case, however, that concern can be fairly easily dismissed by noting that a substantial fraction of all 31-byte strings — at least one in 32, to be precise — must be the truncation of some 32-byte Ed25519 shared secret, so that, if your cryptosystem was particularly vulnerable when used with such a string as its key, it would also have an unacceptably high chance of being vulnerable even when used with a perfectly random 31-byte key.

That said, here you can already see an example of what I meant about the lack of a proper KDF, and its guarantee of effective uniformity, complicating the analysis of the system. Basically, a KDF acts as a domain separator in your system, providing a guarantee that — as long as the KDF itself isn't broken and as long as you feed it something with enough entropy — you can safely analyze the rest of your system based on the assumption that the KDF outputs are indistinguishable from uniformly random. Without a KDF to provide this barrier, you now have to expand your security analysis to consider more details about exactly where your key material comes from and how its entropy is distributed.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.