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>
diff --git a/include/openssl/hpke.h b/include/openssl/hpke.h
index 5b0373d..c90dfb4 100644
--- a/include/openssl/hpke.h
+++ b/include/openssl/hpke.h
@@ -68,6 +68,11 @@
// 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
