Botan MC-Eliece implementation fails because of deprecated implementation example - c++

Question

I have problems with my c++ mc-eliece implementation from Botan crypto library. There seems to be virtually only one example of it in the whole internet, with a link to it.
https://www.cryptosource.de/docs/mceliece_in_botan.pdf
But this example is 6 years old, hence it is totally outdated and the Botan docs do not provide any other.
The problem is basically, that unfortunatelly function names and specs have changed over time, hence i get a couple of compiler errors while i try to use them. I managed to demystify some of them by looking into the header implementations. But now i'm, frankly said, in front of a wall.
It would be great if anybody familar with the Botan MC-Eliece implementation, could give me a hint, how the current functions are called.
This is my code with marks. I removed a lot of unnecessary code and other implementations, to make it more readable. You will also not be able to make it run without the necessary modules, but i will try to write it down in a way, that somebody with Botan library should be able to run it.
//to compile: g++ -o mc_eliece mc_eliece.cpp -Wall -I/usr/local/include/botan-2/ -I/home/pi/projects/RNG_final/ -ltss2-esys -ltss2-rc -lbotan-2
#include <iostream>
#include <botan/rng.h>
#include <botan/system_rng.h>
#include <botan/mceies.h>
#include <botan/mceliece.h>
int main() {
Botan::size_t n = 1632; // Parameters for key generation
Botan::size_t t = 33;
// initialize RNG type
Botan::System_RNG rng; // is a standard Botan RNG
// create a new MCEliece private key with code length n and error weigth t
Botan::McEliece_PrivateKey sk1(rng, n, t); // actually works!
// derive the corresponding public key
Botan::McEliece_PublicKey pk1(*dynamic_cast<Botan::McEliece_PublicKey*>(&sk1)); // actually works!
// encode the public key
std::vector<uint8_t> pk_enc = pk1.subject_public_key(); // actually works!
// encode the private key
Botan::secure_vector<uint8_t> sk_enc = sk1.private_key_bits(); // had to replace sk1.pkcs8_private_key()
// encryption side: decode a serialized public key
Botan::McEliece_PublicKey pk(pk_enc);
McEliece_KEM_Encryptor enc(pk); // does not work, can't find a working corresponding function in the header
// perform encryption -> will find out if it works after upper case had been solved
std::pair<secure_vector<Botan::byte>,secure_vector<Botan::byte> > ciphertext__sym_key = enc.encrypt(rng);
secure_vector<Botan::byte> sym_key_encr = ciphertext__sym_key.second;
secure_vector<Botan::byte> ciphertext = ciphertext__sym_key.first;
// code used at the decrypting side: -> will find out if it works after upper case had been solved
// decode a serialized private key
McEliece_PrivateKey sk(sk_enc);
McEliece_KEM_Decryptor dec(sk);
// perform decryption -> will find out if it works after upper case had been solved
secure_vector<Botan::byte> sym_key_decr = dec.decrypt(&ciphertext[0],
ciphertext.size() );
// both sides now have the same 64-byte symmetric key.
// use this key to instantiate an authenticated encryption scheme.
// in case shorter keys are needed, they can simple be cut off.
return 0;
}
Thx for any help in advance.

Answer 1

I have now updated the example code in https://www.cryptosource.de/docs/mceliece_in_botan.pdf to reflect these the changes to Botan's new KEM API.
Please note that it is unnecessary to provide a salt value for the KDF when used in the context of a KEM for a public key scheme such as McEliece. That the KDF can accept a salt value here is a mere artefact of the API, owing to that fact that KDFs can be used also in other contexts. Specifically, a salt value is only necessary when deriving keys of secrets that potentially lack entropy, such as passwords. Then it mitigates attacks based on precomputed tables.

Answer 2

The McEliece unit test can be taken as reference (link).
Based on that code, your example can be rewritten as follows:
#include <botan/auto_rng.h>
#include <botan/data_src.h>
#include <botan/hex.h>
#include <botan/mceies.h>
#include <botan/mceliece.h>
#include <botan/pkcs8.h>
#include <botan/pubkey.h>
#include <botan/x509_key.h>
#include <cassert>
#include <iostream>
int main() {
// Parameters for McEliece key
// Reference: https://en.wikipedia.org/wiki/McEliece_cryptosystem#Key_sizes
Botan::size_t n = 1632;
Botan::size_t t = 33;
// Size of the symmetric key in bytes
Botan::size_t shared_key_size = 64;
// Key-derivation function to be used for key encapsulation
// Reference: https://botan.randombit.net/handbook/api_ref/kdf.html
std::string kdf{"KDF1(SHA-512)"};
// Salt to be used for key derivation
// NOTE: Pick salt dynamically, Botan recommds for example using a session ID.
std::vector<Botan::byte> salt{0x01, 0x02, 0x03};
Botan::AutoSeeded_RNG rng{};
// Generate private key
Botan::McEliece_PrivateKey priv{rng, n, t};
std::vector<Botan::byte> pub_enc{priv.subject_public_key()};
Botan::secure_vector<Botan::byte> priv_enc{Botan::PKCS8::BER_encode(priv)};
// Encrypting side: Create encapsulated symmetric key
std::unique_ptr<Botan::Public_Key> pub{Botan::X509::load_key(pub_enc)};
Botan::PK_KEM_Encryptor encryptor{*pub, rng, kdf};
Botan::secure_vector<Botan::byte> encapsulated_key{};
Botan::secure_vector<Botan::byte> shared_key1{};
encryptor.encrypt(encapsulated_key, shared_key1, shared_key_size, rng, salt);
std::cout << "Shared key 1: " << Botan::hex_encode(shared_key1) << std::endl;
// Decrypting side: Unpack encapsulated symmetric key
Botan::DataSource_Memory priv_enc_src{priv_enc};
std::unique_ptr<Botan::Private_Key> priv2{
Botan::PKCS8::load_key(priv_enc_src)};
Botan::PK_KEM_Decryptor decryptor{*priv2, rng, kdf};
Botan::secure_vector<Botan::byte> shared_key2{
decryptor.decrypt(encapsulated_key, shared_key_size, salt)};
std::cout << "Shared key 2: " << Botan::hex_encode(shared_key2) << std::endl;
assert(shared_key1 == shared_key2);
return 0;
}
I tested this code against 2.15.0. Example output:
$ g++ -g $(pkg-config --cflags --libs botan-2) test.cpp
$ ./a.out
Shared key 1: 32177925CE5F3D607BA45575195F13B9E0123BD739580DFCF9AE53D417C530DB115867E5E377735CB405CDA6DF7866C647F85FDAC5C407BB2E2C3A8E7D41A5CC
Shared key 2: 32177925CE5F3D607BA45575195F13B9E0123BD739580DFCF9AE53D417C530DB115867E5E377735CB405CDA6DF7866C647F85FDAC5C407BB2E2C3A8E7D41A5CC
Some notes on what I changed compared to the code you gave:
Every Botan::Private_Key is also a Botan::Public_Key (reference). Therefore, we do not need to cast the generated private key to a public key. Instead, we can call subject_public_key directly on the private key to obtain the public key encoding.
Using private_key_bits to obtain the raw private key bits for serialization works, but using PKCS8 might be more robust in terms of interoperability. So I would use Botan::PKCS8::BER_encodeon the private key for that reason.
Constructing the McEliece_PublicKey directly from the public key encoding did not work for me, as the constructor expects the raw public key bits and not the x509 public key encoding. For this reason, I had to use Botan::X509::load_key.
The McEliece_KEM_Encryptor has been removed (reference):
Add generalized interface for KEM (key encapsulation) techniques. Convert McEliece KEM to use it. The previous interfaces McEliece_KEM_Encryptor and McEliece_KEM_Decryptor have been removed. The new KEM interface now uses a KDF to hash the resulting keys; to get the same output as previously provided by McEliece_KEM_Encryptor, use "KDF1(SHA-512)" and request exactly 64 bytes.
Instead you would use Botan::PK_KEM_Encryptor, which takes the public key as a parameter and infers the encryption algorithm to be used from the public key. You can see from the code that it becomes more flexible this way, we do not have to reference McEliece after the key has been generated. If we want to switch to a different algorithm, we only have to change the key generation part, but not the key encapsulation part.
The same applies for McEliece_KEM_Decryptor.
As noted in the above quote, the new KEM interface allows to specify the key-derivation function to be used for KEM, as well as the desired size of the symmetric key. Also, you can pass a salt that will be used for key derivation. For the salt, you would use some value that is unique to your application or even better unique to the current session (reference):
Typically salt is a label or identifier, such as a session id.