-
The shareKey generated by using p256.getSharedSecret does not match the sharekey generated by OpenSSL ECDH_compute_key, nor does it match the sharekey generated by using subarray(1). |
Beta Was this translation helpful? Give feedback.
Answered by
paulmillr
Feb 27, 2024
Replies: 1 comment 4 replies
-
I have no idea. noble multiplies point B by secret scalar A, which is the general definition of shared secret / ecdh. It must always be the same between all implementations. Ensure the output is compressed / uncompressed depending on your needs. noble-curves/src/abstract/weierstrass.ts Lines 921 to 926 in a1a7dc9 |
Beta Was this translation helpful? Give feedback.
4 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
if it's 32 bytes, then it's either:
a. SLICED:
res.slice(1, 33)
b. HASHED:
sha256(res.slice(1, 33))
c. HKDFED:
hkdf_sha256(res.slice(1, 33))
d. SLICED and HASHED/HKDFED: b or d, but replace
res.slice(1, 33)
withdecompRes.slice(1, 65)
,res.slice(0, 33)
ordecompRes.slice(0, 65)
There is no standard for ECDH. 32 bytes, 33 bytes, hashing or kdfing all make sense depending on ones needs. We provide the most flexible output, that can be converted to anything you'd like.