Generic de-/encoding of raw public keys via FFI (in particular for KEMs)?

[tobiasbrunner]

While trying to use FrodoKEM via FFI, I noticed that there is no botan_pubkey_view_frodokem_raw_key() function, analogous to the existing botan_pubkey_view_kyber_raw_key() function and the botan_pubkey_view_ml_kem_raw_key() function that's proposed in #3893 by @reneme.

Adding such a function for FrodoKEM would definitely be helpful, as using it via FFI is currently quite awkward (basically requires unwrapping a DER-encoded public key).

But then I wondered why there isn't a generic botan_pubkey_view_raw_key() function, which returns the raw key bits of any public key object that supports it. That would avoid having to call different functions for each algorithm, or having to extend the API every time a new key type is added (which can be missed as seen with FrodoKEM). Would it be possible to add that? Or is adding a type-specific function the way to go?

Similarly, either a specific botan_pubkey_load_frodokem() or a generic botan_pubkey_load_raw() function needs to be added, as having to encode the raw public key in DER format with a matching OID is again quite awkward. The proposed ML-KEM public key loading function (botan_pubkey_load_ml_kem()) already takes the name of the key type, so the same interface could possibly be used for a generic version. Is such a generic approach possible? Or do we need to add a FrodoKEM-specific function?

[randombit]

I believe we could just implement exactly botan_pubkey_view_raw_key with #3985 and avoid (further) algorithm specific functions.

[reneme]

#4368 introduced the generic raw serialization. The algorithm-specific decoding functions will be added independently with the post-quantum algorithms.

Thanks for reporting this @tobiasbrunner, not fully integrating this in the FFI really was an oversight on our side.

[tobiasbrunner]

Very nice! Really appreciate the quick update on this.

Regarding the missing botan_pubkey_load_frodokem() function, should I submit a PR? Or are you going to do that anyway? I guess botan_privkey_load_frodokem() would have to be added as well?

[reneme]

Regarding the missing botan_pubkey_load_frodokem() function, should I submit a PR?

Thanks! I'm already on it. I'm hoping to build this in a generic way to re-use the respective test code for ML-KEM and Classic McEliece. I'd appreciate a review (and/or test integration), though.

[tobiasbrunner]

Ah, great, thanks! I'm happy to test it, just tag me once it's ready.

[reneme]

@tobiasbrunner Please have a look at it here: #4373

[reneme]

For the record: With #4373 and the (open) pull requests for SLH-DSA (#4291), ML-DSA (#4270), ML-KEM (#3893) and Classic McEliece (#3883) we introduced the algorithm-specific loading functions into the FFI (and Python-bindings):

Here's an example for ML-KEM using the FFI, the other algorithms provide equivalent functions:

botan_privkey_t sk;
botan_pubkey_t pk;

// reading of raw byte array containing an ML-KEM key pair
botan_privkey_load_ml_kem(&sk, sk_bytes, 64 /* length of sk_bytes */, "ML-KEM-768" /* ML-KEM mode */);
botan_pubkey_load_ml_kem(&pk, pk_bytes, pk_bytes_len, "ML-KEM-768" /* ML-KEM mode */);

// encoding of ML-KEM key pair into raw byte array
// (these functions aren't algorithm specific)
botan_privkey_view_raw(sk, nullptr, sk_view_callback);
botan_pubkey_view_raw(pk, nullptr, pk_view_callback);

And another example using the Python bindings:

sk = botan.PrivateKey.load_ml_kem("ML-KEM-768", sk_bytes)
pk = botan.PublicKey.load_ml_kem("ML-KEM-768", pk_bytes)

sk_bytes2 = sk.to_raw()
pk_bytes2 = pk.to_raw()