Does ECDH on secp256k produce a defined shared secret for two key pairs, or is it implementation defined?

fadedbee

7/24/24, 3:10 PM

Rust and NodeJS implementations of ECDH on secp256k1 produce different shared secrets, when using identical keypairs:

NodeJS:

sk1 <Buffer 71 17 9b 99 1d 76 93 de 81 3a ea a5 bf a2 41 a2 ac 9e 05 35 86 7e bf 8f 6b 1b 08 84 47 2e f4 a7>
pk1 02de4cba976ab77795c46c1c3b95afc077b17afe1bca02d28963a3bcdd9c082168
sk2 <Buffer 1e 11 4f 23 7e 3c 59 ba 2b 92 ae df 21 3f 11 27 c9 16 9c 03 97 52 49 5c 1f fb 64 9c b9 b9 05 98>
pk2 033415a4e45739e8f003450392793a15d3ad6cb49ff5b1943695f2cea92703aa64
sec1 <Buffer 23 55 7d 44 6a 48 23 d6 a3 2f b0 87 58 82 26 d1 e8 ef 4f 6b 7b 6d 26 09 13 13 84 0a 74 ed 0b 4d>
sec2 <Buffer 23 55 7d 44 6a 48 23 d6 a3 2f b0 87 58 82 26 d1 e8 ef 4f 6b 7b 6d 26 09 13 13 84 0a 74 ed 0b 4d>

Rust:

sk1: [71, 17, 9b, 99, 1d, 76, 93, de, 81, 3a, ea, a5, bf, a2, 41, a2, ac, 9e, 5, 35, 86, 7e, bf, 8f, 6b, 1b, 8, 84, 47, 2e, f4, a7]
pk1: [2, de, 4c, ba, 97, 6a, b7, 77, 95, c4, 6c, 1c, 3b, 95, af, c0, 77, b1, 7a, fe, 1b, ca, 2, d2, 89, 63, a3, bc, dd, 9c, 8, 21, 68]
sk2: [1e, 11, 4f, 23, 7e, 3c, 59, ba, 2b, 92, ae, df, 21, 3f, 11, 27, c9, 16, 9c, 3, 97, 52, 49, 5c, 1f, fb, 64, 9c, b9, b9, 5, 98]
pk2: [3, 34, 15, a4, e4, 57, 39, e8, f0, 3, 45, 3, 92, 79, 3a, 15, d3, ad, 6c, b4, 9f, f5, b1, 94, 36, 95, f2, ce, a9, 27, 3, aa, 64]
sec1: [45, b7, 3c, 8a, ac, 8b, cf, 65, 1d, ad, 11, f7, f0, 4f, 63, b9, f0, 34, 86, d0, 28, ab, 4d, 5c, 52, bd, d5, d6, 92, d7, c2, aa]
sec2: [45, b7, 3c, 8a, ac, 8b, cf, 65, 1d, ad, 11, f7, f0, 4f, 63, b9, f0, 34, 86, d0, 28, ab, 4d, 5c, 52, bd, d5, d6, 92, d7, c2, aa]

Both implementations work, i.e. they produce the same shared secret from (pk1, sk2) as from (pk2, sk1).

Should I expect these ECDH/secp256k1 shared secrets, produced by different implementations, to match?

203

1 + 0

diffie-hellman

secp256k1

Score:4

Crypto

Gilles 'SO- stop being evil'

7/24/24, 4:29 PM

ECDH produces a well-defined result given a specific private key and a specific public key. ECDH is very often used to generate the same shared secret from two programs that talk the same protocol, and those programs may not be implemented using the same code, so it really has to be interoperable.

The raw shared secret from ECDH is not directly suitable for many purposes because it has a fixed length and it's biased (for example, since it's a number between $1$ and $n-1$ where $n$ is between $2^{k-1}$ and $2^k$, the values $0$ and $\ge n$ are unreachable). So it must be processed by a key derivation function. The protocol definition must specify what key derivation function to use. There are many correct ways to do the derivation there, and there isn't one that's more standard than others.

What is happening here is that Rust is applying a specific KDF which I think is specific to how secp256k1 is used in Bitcoin.

In practice, you have to watch for several things, which unfortunately may not always be caught, depending on the API design:

You need to pass the keys in the correct format. In principle, there are a few standard formats, but some implementations may require a non-standard format. You'd normally get a runtime error, but sometimes not, for example if an embedded implementation that's optimized for a specific processor architecture wants a non-default endianness.

The standard format for private keys on SEC curves is a fixed-size big-endian representation of the private value. It may be encapsulated in a larger format with metadata.

The standard format for public keys on SEC curves is a one-byte header followed by a fixed-size representation of the coordinates. It may be encapsulated in a larger format with metadata. There are two possible representations for a valid public key: compressed (the byte 0x02 or 0x03, followed by a fixed-length big-endian representation of the $x$ coordinate) or uncompressed (the byte 0x04, followed by a fixed-length big-endian representation of the $x$ and $y$ coordinates in this order). See SEC1 §2.3.3 for details.
Likewise, the output format may be different. Mathematically, the shared secret is a point on the curve. The de facto standard is to use the $x$ coordinate of that point as the shared secret, in a fixed-length big-endian representation.
There are many correct ways to do the key derivation, and there isn't one that is an ubiquitous standard. So check the documentation of your implementation — or the code, if the documentation is bad, which unfortunately is common in cryptography implementations.

+ 2

fgrieu

7/24/24, 4:32 PM

Yes. I checked that the value output by NodeJS is the X coordinate of the raw ECDH point. And Reading The [Fantastic Manual](https://docs.rs/secp256k1-sys/latest/secp256k1_sys/) tells that the Rust implementation uses _"[EcdhHashFn](https://docs.rs/secp256k1-sys/latest/secp256k1_sys/type.EcdhHashFn.html) Hash function to use to post-process an ECDH point to get a shared secret"_, There's a [default such function](https://docs.rs/secp256k1-sys/latest/secp256k1_sys/static.secp256k1_ecdh_hash_function_default.html) but I can't tell which.

Gilles 'SO- stop being evil'

7/24/24, 4:47 PM

@fgrieu-onstrike Yes, see the linked [so] question. Specifically, it's hashing 0x02 concatenated with the standard x coordinate, using SHA-256. The existence of this post-processing of `SharedSecret` is mentioned in the [documentation of `shared_secret_point`](https://docs.rs/secp256k1/latest/secp256k1/ecdh/fn.shared_secret_point.html) but not in the documentation of `SharedSecret`. I RTFS for the exact postprocessing.

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: Does ECDH on secp256k produce a defined shared secret for two key pairs, or is it implementation defined?

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.