Add EVP_HPKE_KDF_hkdf_md.

Some HPKE consumers call into the KDF directly. We don't have an EVP_KDF
abstraction and it's not clear to me how settled "KDF" is as an
interface. (HPKE specifically assumes an extract/expand pair.)

For now, just add EVP_HPKE_KDF_hkdf_md which is defined to only work for
HKDF KDFs. As we don't implement ID -> KDF lookup ourselves and expect
callers to decide which algorithms they want to export, any future
non-HKDF-based KDF won't affect existing callers anyway. If that
happens, we can make this return an EVP_KDF or just add
EVP_HPKE_KDF_{extract,expand} depending on universal this turns out to
be.

Change-Id: I93b9c8a5340472974a6f1bfc45154371d8971600
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54085
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>

crypto/hpke/hpke.c

@@ -319,6 +319,10 @@ const EVP_HPKE_KDF *EVP_hpke_hkdf_sha256(void) {
 
 uint16_t EVP_HPKE_KDF_id(const EVP_HPKE_KDF *kdf) { return kdf->id; }
 
+const EVP_MD *EVP_HPKE_KDF_hkdf_md(const EVP_HPKE_KDF *kdf) {
+  return kdf->hkdf_md_func();
+}
+
 const EVP_HPKE_AEAD *EVP_hpke_aes_128_gcm(void) {
   static const EVP_HPKE_AEAD kAEAD = {EVP_HPKE_AES_128_GCM,
                                       &EVP_aead_aes_128_gcm};

include/openssl/hpke.h

@@ -68,6 +68,11 @@ OPENSSL_EXPORT const EVP_HPKE_KDF *EVP_hpke_hkdf_sha256(void);
 // EVP_HPKE_KDF_id returns the HPKE KDF identifier for |kdf|.
 OPENSSL_EXPORT uint16_t EVP_HPKE_KDF_id(const EVP_HPKE_KDF *kdf);
 
+// EVP_HPKE_KDF_hkdf_md returns the HKDF hash function corresponding to |kdf|,
+// or NULL if |kdf| is not an HKDF-based KDF. All currently supported KDFs are
+// HKDF-based.
+OPENSSL_EXPORT const EVP_MD *EVP_HPKE_KDF_hkdf_md(const EVP_HPKE_KDF *kdf);
+
 // The following constants are AEAD identifiers.
 #define EVP_HPKE_AES_128_GCM 0x0001
 #define EVP_HPKE_AES_256_GCM 0x0002