DH_compute_key function

@RecordUse.new() @Native<Int Function(Pointer<Uint8>, Pointer<BIGNUM>, Pointer<DH>)>(ffi.Pointer<ffi.Uint8>, ffi.Pointer<BIGNUM>, ffi.Pointer<DH>)>(symbol: 'bssl_dart_DH_compute_key') int DH_compute_key(Pointer<Uint8> out, Pointer<BIGNUM> peers_key, Pointer<DH> dh)

DH_compute_key behaves like DH_compute_key_padded but, contrary to PKCS #3, returns a variable-length shared key with leading zeros. It returns the number of bytes written, or a negative number on error. out must have DH_size bytes of space.

WARNING: this differs from the usual BoringSSL return-value convention.

Note this function's running time and memory access pattern leaks information about the shared secret. Particularly if dh is reused, this may result in side channel attacks such as https://raccoon-attack.com/.

DH_compute_key_padded is the preferred variant and avoids the above attacks. However, the two functions are not drop-in replacements for each other. Using a different variant than the application expects will result in sporadic key mismatches.

Callers that expect a fixed-width secret should use DH_compute_key_padded instead. Callers that use either function should migrate to a modern primitive such as X25519 or ECDH with P-256 instead.

This function does not mutate dh for thread-safety purposes and may be used concurrently.

Implementation

@meta.RecordUse()
@ffi.Native<
  ffi.Int Function(ffi.Pointer<ffi.Uint8>, ffi.Pointer<BIGNUM>, ffi.Pointer<DH>)
>(symbol: 'bssl_dart_DH_compute_key')
external int DH_compute_key(
  ffi.Pointer<ffi.Uint8> out,
  ffi.Pointer<BIGNUM> peers_key,
  ffi.Pointer<DH> dh,
);