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/crypto/hpke/hpke.c b/crypto/hpke/hpke.c
index 6e3d5e8..e49b46d 100644
--- a/crypto/hpke/hpke.c
+++ b/crypto/hpke/hpke.c
@@ -319,6 +319,10 @@
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};
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
