I’ve spent a few days by searching what structure does ECDH secret agreement have, but no success. I found in MSDN that the NCryptSecretAgreement function sets a pointer to an NCRYPT_SECRET_HANDLE variable that receives a handle that represents the secret agreement value. I’m not familar with WinAPI at all so I simply can’t do anything but reading docs.
I need to exchange keys between a Windows-based desktop app and a web app. What I need to know is how exactly CNG’s KDF uses (hashes in my case) the secret agreement value. I’m using the SHA-256 algorithm as KDF and trying to hash X and Y of the secret agreement but result doesn’t match to the one CNG computes. Any ideas?
Thank you.
I cannot vouch for what Microsoft found fit to implement, but there is a standard on ECDH called X9.63. In that standard, ECDH works like this:
You run the DH thing, yielding the common curve point (X, Y) (that’s the point you got from the peer, multiplied by your secret DH value).
You convert X (and only X; Y is discarded) into a sequence of bytes which we will call Z. Conversion is unsigned big-endian, and uses the field size: if X lives in field Fq, then the conversion yields exactly ceil(ceil(log q)/8). E.g. if you use the NIST P-521 curve, you work modulo a prime q which is such that 2520 < q < 2521, so ceil(log q) = 521 and the resulting byte sequence consists in exactly 66 bytes, whatever the value X. With the most commonly used elliptic curve (known as “P-256”), that’s 32 bytes.
To derive Z into a key, with a hash function H which has an output length of n bytes (e.g. n = 32 with SHA-256), you compute the potentially infinite string H1||H2||H3||… where “||” denotes concatenation, and Hi = H(Z||i) where “i” is represented as four bytes, using big-endian convention. In plain words, you hash Z along with a 32-bit counter, and do so again and again until you have enough bytes for your intended key length.