-1

I am trying to replace a openssl code to CNG winapi code. Below is the barebone openssl code which i have. 

const char *generator = ""; // 256 character hex string
const char *prime     = ""; // 256 character hex string

dh = DH_new();

// Initialize dh's generator and prime
BN_hex2bn(&(dh->g), generator);
BN_hex2bn(&(dh->p), prime);

// Generate public and private keys
DH_generate_key(dh);

// Extract server's public key from init_msg's 'key'
BIGNUM *server_pub_key = BN_new();
BN_hex2bn(&server_pub_key, " *** 256 character server public key as hex string ***");

// Use DH to calculate the shared key
vector<unsigned char> shared_key;
shared_key.resize(DH_size(dh));
err = DH_compute_key(shared_key.data(), server_pub_key, dh);

the above code generated a shared key of 256 characters hex string(128 Bytes). What is the key agreement function used by openssl to create such key. Thanks in advance.

Prakash N
  • 1,020
  • 1
  • 8
  • 20
  • OpenSSL mostly follows the RFCs. See [RFC 5246, The Transport Layer Security (TLS) Protocol Version 1.2](https://www.ietf.org/rfc/rfc5246.txt) – jww Sep 26 '17 at 19:33
  • can you please specify the Derivative function used by openssl to derive the Agreed secret key from private and public keys. Something like this. https://msdn.microsoft.com/en-us/library/windows/desktop/aa375393(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/aa375534(v=vs.85).aspx – Prakash N Sep 26 '17 at 21:38
  • For the code you showed above, it looks like non-authenticated Diffie-Hellman. Its just an exponentiation. What OpenSSL uses in TLS depends upon the cipher suite selected and to some extent, the X509 certificate. Once a cipher suite is selected and the client has some security parameters from the X509 certificate, the client and server will proceed as described in RFC 5246. If a non-ephemeral cipher suite is selected, then key transport will be used and Diffie-Hellman will not be performed. – jww Sep 27 '17 at 08:43
  • Thanks jww. like you said it is non-autheticated Diffie-Hellman. – Prakash N Sep 27 '17 at 15:20
  • Related: https://stackoverflow.com/q/38115602/589259. By the way, I asked for a more compatible way of derivation for TLS 1.3. It uses HKDF on the secret value, without removing possible leading `00` bytes. – Maarten Bodewes Sep 28 '17 at 00:14

2 Answers2

3

It doesn't. Or "the NULL KDF", or f(x) -> x.

DH_compute_key does the raw DH operation and returns the result.

None of the documented KDF values to BCryptDeriveKey return the raw value. It's always possible that they've added BCRYPT_KDF values that haven't made it to docs yet, you'd need to check bcrypt.h from the latest SDK releases.

bartonjs
  • 30,352
  • 2
  • 71
  • 111
  • Thanks batonjs. I checked the bcrypt.h file from SDK. they dont have support for raw values yet. May i know how you would do this with native windows library? – Prakash N Sep 27 '17 at 15:17
2

What you get is just the direct result of Diffie-Hellman (DH) key agreement, before any KDF is being used. I'm not sure what you expect us to say besides this. It's an unsigned big endian number in the range up to the size of the key (1024 bits) in bytes (128 bytes).

That would be BCRYPT_DH_ALGORITHM of course.

Maarten Bodewes
  • 90,524
  • 13
  • 150
  • 263
  • Do you know how to derive such values using BcryptDeriveKey? what value should i pass in for pwszKDF parameter? – Prakash N Sep 27 '17 at 14:28