Public Key Cryptography¶
Public key cryptography (also called asymmetric cryptography) is a collection of techniques allowing for encryption, signatures, and key agreement.
Key Objects¶
Public and private keys are represented by classes Public_Key
and it’s
subclass Private_Key
. The use of inheritance here means that a
Private_Key
can be converted into a reference to a public key.
None of the functions on Public_Key
and Private_Key
itself are
particularly useful for users of the library, because ‘bare’ public key
operations are very insecure. The only purpose of these functions is to
provide a clean interface that higher level operations can be built on. So
really the only thing you need to know is that when a function takes a
reference to a Public_Key
, it can take any public key or private key, and
similarly for Private_Key
.
Types of Public_Key
include RSA_PublicKey
, DSA_PublicKey
,
ECDSA_PublicKey
, ECKCDSA_PublicKey
, ECGDSA_PublicKey
, DH_PublicKey
, ECDH_PublicKey
,
Curve25519_PublicKey
, ElGamal_PublicKey
, McEliece_PublicKey
, XMSS_PublicKey
and GOST_3410_PublicKey
. There are corresponding Private_Key
classes for each of these algorithms.
Creating New Private Keys¶
Creating a new private key requires two things: a source of random numbers (see Random Number Generators) and some algorithm specific parameters that define the security level of the resulting key. For instance, the security level of an RSA key is (at least in part) defined by the length of the public key modulus in bits. So to create a new RSA private key, you would call

RSA_PrivateKey
::
RSA_PrivateKey
(RandomNumberGenerator &rng, size_t bits)¶ A constructor that creates a new random RSA private key with a modulus of length bits.
Algorithms based on the discretelogarithm problem use what is called a group; a group can safely be used with many keys, and for some operations, like key agreement, the two keys must use the same group. There are currently two kinds of discrete logarithm groups supported in botan: the integers modulo a prime, represented by DL_Group, and elliptic curves in GF(p), represented by EC_Group. A rough generalization is that the larger the group is, the more secure the algorithm is, but correspondingly the slower the operations will be.
Given a DL_Group
, you can create new DSA, DiffieHellman and ElGamal key pairs with

DSA_PrivateKey
::
DSA_PrivateKey
(RandomNumberGenerator &rng, const DL_Group &group, const BigInt &x = 0)¶

DH_PrivateKey
::
DH_PrivateKey
(RandomNumberGenerator &rng, const DL_Group &group, const BigInt &x = 0)¶

ElGamal_PrivateKey
::
ElGamal_PrivateKey
(RandomNumberGenerator &rng, const DL_Group &group, const BigInt &x = 0)¶ The optional x parameter to each of these constructors is a private key value. This allows you to create keys where the private key is formed by some special technique; for instance you can use the hash of a password (see Password Based Key Derivation for how to do that) as a private key value. Normally, you would leave the value as zero, letting the class generate a new random key.
Finally, given an EC_Group
object, you can create a new ECDSA, ECKCDSA, ECGDSA,
ECDH, or GOST 34.102001 private key with

ECDSA_PrivateKey
::
ECDSA_PrivateKey
(RandomNumberGenerator &rng, const EC_Group &domain, const BigInt &x = 0)¶

ECKCDSA_PrivateKey
::
ECKCDSA_PrivateKey
(RandomNumberGenerator &rng, const EC_Group &domain, const BigInt &x = 0)¶

ECGDSA_PrivateKey
::
ECGDSA_PrivateKey
(RandomNumberGenerator &rng, const EC_Group &domain, const BigInt &x = 0)¶

ECDH_PrivateKey
::
ECDH_PrivateKey
(RandomNumberGenerator &rng, const EC_Group &domain, const BigInt &x = 0)¶

GOST_3410_PrivateKey
::
GOST_3410_PrivateKey
(RandomNumberGenerator &rng, const EC_Group &domain, const BigInt &x = 0)¶
Serializing Private Keys Using PKCS #8¶
The standard format for serializing a private key is PKCS #8, the operations
for which are defined in pkcs8.h
. It supports both unencrypted and
encrypted storage.

secure_vector<uint8_t>
PKCS8
::
BER_encode
(const Private_Key &key, RandomNumberGenerator &rng, const std::string &password, const std::string &pbe_algo = "")¶ Takes any private key object, serializes it, encrypts it using password, and returns a binary structure representing the private key.
The final (optional) argument, pbe_algo, specifies a particular password based encryption (or PBE) algorithm. If you don’t specify a PBE, a sensible default will be used.
The currently supported PBE is PBES2 from PKCS5. Format is as follows:
PBEPKCS5v20(CIPHER,PBKDF)
. Since 2.8.0,PBES2(CIPHER,PBKDF)
also works. Cipher can be any block cipher with /CBC or /GCM appended, for example “AES128/CBC” or “Camellia256/GCM”. For best interop with other systems, use AES in CBC mode. The PBKDF can be either the name of a hash function (in which case PBKDF2 is used with that hash) or “Scrypt”, which causes the scrypt memory hard password hashing function to be used. Scrypt is supported since version 2.7.0.Use PBEPKCS5v20(AES256/CBC,SHA256) if you want to ensure the keys can be imported by different software packages. Use PBEPKCS5v20(AES256/GCM,Scrypt) for best security assuming you do not care about interop.
For ciphers you can use anything which has an OID defined for CBC, GCM or SIV modes. Currently this includes AES, Camellia, Serpent, Twofish, and SM4. Most other libraries only support CBC mode for private key encryption. GCM has been supported in PBES2 since 1.11.10. SIV has been supported since 2.8.

std::string
PKCS8
::
PEM_encode
(const Private_Key &key, RandomNumberGenerator &rng, const std::string &pass, const std::string &pbe_algo = "")¶ This formats the key in the same manner as
BER_encode
, but additionally encodes it into a text format with identifying headers. Using PEM encoding is highly recommended for many reasons, including compatibility with other software, for transmission over 8bit unclean channels, because it can be identified by a human without special tools, and because it sometimes allows more sane behavior of tools that process the data.
Unencrypted serialization is also supported.
Warning
In most situations, using unencrypted private key storage is a bad idea, because anyone can come along and grab the private key without having to know any passwords or other secrets. Unless you have very particular security requirements, always use the versions that encrypt the key based on a passphrase, described above.

secure_vector<uint8_t>
PKCS8
::
BER_encode
(const Private_Key &key)¶ Serializes the private key and returns the result.

std::string
PKCS8
::
PEM_encode
(const Private_Key &key)¶ Serializes the private key, base64 encodes it, and returns the result.
Last but not least, there are some functions that will load (and decrypt, if necessary) a PKCS #8 private key:

Private_Key *
PKCS8
::
load_key
(DataSource &in, RandomNumberGenerator &rng, const User_Interface &ui)¶

Private_Key *
PKCS8
::
load_key
(DataSource &in, RandomNumberGenerator &rng, std::string passphrase = "")¶

Private_Key *
PKCS8
::
load_key
(const std::string &filename, RandomNumberGenerator &rng, const User_Interface &ui)¶

Private_Key *
PKCS8
::
load_key
(const std::string &filename, RandomNumberGenerator &rng, const std::string &passphrase = "")¶
These functions will return an object allocated key object based on the data
from whatever source it is using (assuming, of course, the source is in fact
storing a representation of a private key, and the decryption was
successful). The encoding used (PEM or BER) need not be specified; the format
will be detected automatically. The key is allocated with new
, and should
be released with delete
when you are done with it. The first takes a
generic DataSource
that you have to create  the other is a simple wrapper
functions that take either a filename or a memory buffer and create the
appropriate DataSource
.
The versions taking a std::string
attempt to decrypt using the password
given (if the key is encrypted; if it is not, the passphase value will be
ignored). If the passphrase does not decrypt the key, an exception will be
thrown.
The ones taking a User_Interface
provide a simple callback interface which
makes handling incorrect passphrases and such a bit simpler. A
User_Interface
has very little to do with talking to users; it’s just a
way to glue together Botan and whatever user interface you happen to be using.
Note
In a future version, it is likely that User_Interface
will be
replaced by a simple callback using std::function
.
To use User_Interface
, derive a subclass and implement:

std::string
User_Interface
::
get_passphrase
(const std::string &what, const std::string &source, UI_Result &result) const¶ The
what
argument specifies what the passphrase is needed for (for example, PKCS #8 key loading passeswhat
as “PKCS #8 private key”). This lets you provide the user with some indication of why your application is asking for a passphrase; feel free to pass the string throughgettext(3)
or moral equivalent for i18n purposes. Similarly,source
specifies where the data in question came from, if available (for example, a file name). If the source is not available for whatever reason, thensource
will be an empty string; be sure to account for this possibility.The function returns the passphrase as the return value, and a status code in
result
(eitherOK
orCANCEL_ACTION
). IfCANCEL_ACTION
is returned inresult
, then the return value will be ignored, and the caller will take whatever action is necessary (typically, throwing an exception stating that the passphrase couldn’t be determined). In the specific case of PKCS #8 key decryption, aDecoding_Error
exception will be thrown; your UI should assume this can happen, and provide appropriate error handling (such as putting up a dialog box informing the user of the situation, and canceling the operation in progress).
Serializing Public Keys¶
To import and export public keys, use:

std::vector<uint8_t>
X509
::
BER_encode
(const Public_Key &key)¶

std::string
X509
::
PEM_encode
(const Public_Key &key)¶

Public_Key *
X509
::
load_key
(DataSource &in)¶

Public_Key *
X509
::
load_key
(const secure_vector<uint8_t> &buffer)¶

Public_Key *
X509
::
load_key
(const std::string &filename)¶ These functions operate in the same way as the ones described in Serializing Private Keys Using PKCS #8, except that no encryption option is available.
DL_Group¶
As described in Creating New Private Keys, a discrete logarithm group can be shared among many keys, even keys created by users who do not trust each other. However, it is necessary to trust the entity who created the group; that is why organization like NIST use algorithms which generate groups in a deterministic way such that creating a bogus group would require breaking some trusted cryptographic primitive like SHA2.
Instantiating a DL_Group
simply requires calling

DL_Group
::
DL_Group
(const std::string &name)¶ The name parameter is a specially formatted string that consists of three things, the type of the group (“modp” or “dsa”), the creator of the group, and the size of the group in bits, all delimited by ‘/’ characters.
Currently all “modp” groups included in botan are ones defined by the Internet Engineering Task Force, so the provider is “ietf”, and the strings look like “modp/ietf/N” where N can be any of 1024, 1536, 2048, 3072, 4096, 6144, or 8192. This group type is used for DiffieHellman and ElGamal algorithms.
The other type, “dsa” is used for DSA keys. They can also be used with DiffieHellman and ElGamal, but this is less common. The currently available groups are “dsa/jce/1024” and “dsa/botan/N” with N being 2048 or 3072. The “jce” groups are the standard DSA groups used in the Java Cryptography Extensions, while the “botan” groups were randomly generated using the FIPS 1863 algorithm by the library maintainers.
You can generate a new random group using

DL_Group
::
DL_Group
(RandomNumberGenerator &rng, PrimeType type, size_t pbits, size_t qbits = 0)¶ The type can be either
Strong
,Prime_Subgroup
, orDSA_Kosherizer
. pbits specifies the size of the prime in bits. If the type isPrime_Subgroup
orDSA_Kosherizer
, then qbits specifies the size of the subgroup.
You can serialize a DL_Group
using

secure_vector<uint8_t>
DL_Group
::
DER_Encode
(Format format)¶
or

std::string
DL_Group
::
PEM_encode
(Format format)¶
where format is any of
ANSI_X9_42
(orDH_PARAMETERS
) for modp groupsANSI_X9_57
(orDSA_PARAMETERS
) for DSAstyle groupsPKCS_3
is an older format for modp groups; it should only be used for backwards compatibility.
You can reload a serialized group using

void
DL_Group
::
BER_decode
(DataSource &source, Format format)¶

void
DL_Group
::
PEM_decode
(DataSource &source)¶
Code Example¶
The example below creates a new 2048 bit DL_Group
, prints the generated
parameters and ANSI_X9_42 encodes the created group for further usage with DH.
#include <botan/dl_group.h>
#include <botan/auto_rng.h>
#include <botan/rng.h>
#include <iostream>
int main()
{
std::unique_ptr<Botan::RandomNumberGenerator> rng(new Botan::AutoSeeded_RNG);
std::unique_ptr<Botan::DL_Group> group(new Botan::DL_Group(*rng.get(), Botan::DL_Group::Strong, 2048));
std::cout << std::endl << "p: " << group>get_p();
std::cout << std::endl << "q: " << group>get_q();
std::cout << std::endl << "g: " << group>get_q();
std::cout << std::endl << "ANSI_X9_42: " << std::endl << group>PEM_encode(Botan::DL_Group::ANSI_X9_42);
return 0;
}
EC_Group¶
An EC_Group
is initialized by passing the name of the
group to be used to the constructor. These groups have
semistandardized names like “secp256r1” and “brainpool512r1”.
Key Checking¶
Most public key algorithms have limitations or restrictions on their parameters. For example RSA requires an odd exponent, and algorithms based on the discrete logarithm problem need a generator > 1.
Each public key type has a function

bool
Public_Key
::
check_key
(RandomNumberGenerator &rng, bool strong)¶ This function performs a number of algorithmspecific tests that the key seems to be mathematically valid and consistent, and returns true if all of the tests pass.
It does not have anything to do with the validity of the key for any particular use, nor does it have anything to do with certificates that link a key (which, after all, is just some numbers) with a user or other entity. If strong is
true
, then it does “strong” checking, which includes expensive operations like primality checking.
As key checks are not automatically performed they must be called manually after loading keys from untrusted sources. If a key from an untrusted source is not checked, the implementation might be vulnerable to algorithm specific attacks.
The following example loads the Subject Public Key from the x509 certificate cert.pem
and checks the
loaded key. If the key check fails a respective error is thrown.
#include <botan/x509cert.h>
#include <botan/auto_rng.h>
#include <botan/rng.h>
int main()
{
Botan::X509_Certificate cert("cert.pem");
std::unique_ptr<Botan::RandomNumberGenerator> rng(new Botan::AutoSeeded_RNG);
std::unique_ptr<Botan::Public_Key> key(cert.subject_public_key());
if(!key>check_key(*rng.get(), false))
{
throw std::invalid_argument("Loaded key is invalid");
}
}
Encryption¶
Safe public key encryption requires the use of a padding scheme which hides the underlying mathematical properties of the algorithm. Additionally, they will add randomness, so encrypting the same plaintext twice produces two different ciphertexts.
The primary interface for encryption is

class
PK_Encryptor
¶ 
secure_vector<uint8_t>
encrypt
(const uint8_t *in, size_t length, RandomNumberGenerator &rng) const¶

secure_vector<uint8_t>
encrypt
(const std::vector<uint8_t> &in, RandomNumberGenerator &rng) const¶ These encrypt a message, returning the ciphertext.

size_t
maximum_input_size
() const¶ Returns the maximum size of the message that can be processed, in bytes. If you call
PK_Encryptor::encrypt
with a value larger than this the operation will fail with an exception.

secure_vector<uint8_t>
PK_Encryptor
is only an interface  to actually encrypt you have
to create an implementation, of which there are currently three available in the
library, PK_Encryptor_EME
, DLIES_Encryptor
and
ECIES_Encryptor
. DLIES is a hybrid encryption scheme (from
IEEE 1363) that uses the DH key agreement technique in combination with a KDF, a
MAC and a symmetric encryption algorithm to perform message encryption. ECIES is
similar to DLIES, but uses ECDH for the key agreement. Normally, public key
encryption is done using algorithms which support it directly, such as RSA or
ElGamal; these use the EME class:

class
PK_Encryptor_EME
¶ 
PK_Encryptor_EME
(const Public_Key &key, std::string eme)¶ With key being the key you want to encrypt messages to. The padding method to use is specified in eme.
The recommended values for eme is “EME1(SHA1)” or “EME1(SHA256)”. If you need compatibility with protocols using the PKCS #1 v1.5 standard, you can also use “EMEPKCS1v1_5”.


class
DLIES_Encryptor
¶ Available in the header
dlies.h

DLIES_Encryptor
(const DH_PrivateKey &own_priv_key, RandomNumberGenerator &rng, KDF *kdf, MessageAuthenticationCode *mac, size_t mac_key_len = 20)¶ Where kdf is a key derivation function (see Key Derivation Functions) and mac is a MessageAuthenticationCode. The encryption is performed by XORing the message with a stream of bytes provided by the KDF.

DLIES_Encryptor
(const DH_PrivateKey &own_priv_key, RandomNumberGenerator &rng, KDF *kdf, Cipher_Mode *cipher, size_t cipher_key_len, MessageAuthenticationCode *mac, size_t mac_key_len = 20)¶ Instead of XORing the message a block cipher can be specified.


class
ECIES_Encryptor
¶ Available in the header
ecies.h
.Parameters for encryption and decryption are set by the
ECIES_System_Params
class which stores the EC domain parameters, the KDF (see Key Derivation Functions), the cipher (see Cipher Modes) and the MAC.
ECIES_Encryptor
(const PK_Key_Agreement_Key &private_key, const ECIES_System_Params &ecies_params, RandomNumberGenerator &rng)¶ Where private_key is the key to use for the key agreement. The system parameters are specified in ecies_params and the RNG to use is passed in rng.

ECIES_Encryptor
(RandomNumberGenerator &rng, const ECIES_System_Params &ecies_params)¶ Creates an ephemeral private key which is used for the key agreement.

The decryption classes are named PK_Decryptor
,
PK_Decryptor_EME
, DLIES_Decryptor
and
ECIES_Decryptor
. They are created in the exact same way, except
they take the private key, and the processing function is named decrypt
.
Botan implements the following encryption algorithms and padding schemes:
 RSA
 “PKCS1v15”  “EMEPKCS1v1_5”
 “OAEP”  “EMEOAEP”  “EME1”  “EME1(SHA1)”  “EME1(SHA256)”
 DLIES
 ECIES
 SM2
Code Example¶
The following Code sample reads a PKCS #8 keypair from the passed location and subsequently encrypts a fixed plaintext with the included public key, using EME1 with SHA256. For the sake of completeness, the ciphertext is then decrypted using the private key.
#include <botan/pkcs8.h>
#include <botan/hex.h>
#include <botan/pk_keys.h>
#include <botan/pubkey.h>
#include <botan/auto_rng.h>
#include <botan/rng.h>
#include <iostream>
int main (int argc, char* argv[])
{
if(argc!=2)
return 1;
std::string plaintext("Your greatgrandfather gave this watch to your granddad for good luck. Unfortunately, Dane's luck wasn't as good as his old man's.");
std::vector<uint8_t> pt(plaintext.data(),plaintext.data()+plaintext.length());
std::unique_ptr<Botan::RandomNumberGenerator> rng(new Botan::AutoSeeded_RNG);
//load keypair
std::unique_ptr<Botan::Private_Key> kp(Botan::PKCS8::load_key(argv[1],*rng.get()));
//encrypt with pk
Botan::PK_Encryptor_EME enc(*kp,*rng.get(), "EME1(SHA256)");
std::vector<uint8_t> ct = enc.encrypt(pt,*rng.get());
//decrypt with sk
Botan::PK_Decryptor_EME dec(*kp,*rng.get(), "EME1(SHA256)");
std::cout << std::endl << "enc: " << Botan::hex_encode(ct) << std::endl << "dec: "<< Botan::hex_encode(dec.decrypt(ct));
return 0;
}
Signatures¶
Signature generation is performed using

class
PK_Signer
¶ 
PK_Signer
(const Private_Key &key, const std::string &emsa, Signature_Format format = IEEE_1363)¶ Constructs a new signer object for the private key key using the signature format emsa. The key must support signature operations. In the current version of the library, this includes RSA, DSA, ECDSA, ECKCDSA, ECGDSA, GOST 34.102001. Other signature schemes may be supported in the future.
Note
Botan both supports nondeterministic and deterministic (as per RFC 6979) DSA and ECDSA signatures. Deterministic signatures are compatible in the way that they can be verified with a nondeterministic implementation. If the
rfc6979
module is enabled, deterministic DSA and ECDSA signatures will be generated.Currently available values for emsa include EMSA1, EMSA2, EMSA3, EMSA4, and Raw. All of them, except Raw, take a parameter naming a message digest function to hash the message with. The Raw encoding signs the input directly; if the message is too big, the signing operation will fail. Raw is not useful except in very specialized applications. Examples are “EMSA1(SHA1)” and “EMSA4(SHA256)”.
For RSA, use EMSA4 (also called PSS) unless you need compatibility with software that uses the older PKCS #1 v1.5 standard, in which case use EMSA3 (also called “EMSAPKCS1v1_5”). For DSA, ECDSA, ECKCDSA, ECGDSA and GOST 34.102001 you should use EMSA1.
The format defaults to
IEEE_1363
which is the only available format for RSA. For DSA, ECDSA, ECGDSA and ECKCDSA you can also useDER_SEQUENCE
, which will format the signature as an ASN.1 SEQUENCE value.

void
update
(const uint8_t *in, size_t length)¶

void
update
(const std::vector<uint8_t> &in)¶

void
update
(uint8_t in)¶ These add more data to be included in the signature computation. Typically, the input will be provided directly to a hash function.

secure_vector<uint8_t>
signature
(RandomNumberGenerator &rng)¶ Creates the signature and returns it

secure_vector<uint8_t>
sign_message
(const uint8_t *in, size_t length, RandomNumberGenerator &rng)¶

secure_vector<uint8_t>
sign_message
(const std::vector<uint8_t> &in, RandomNumberGenerator &rng)¶ These functions are equivalent to calling
PK_Signer::update
and thenPK_Signer::signature
. Any data previously provided usingupdate
will be included.

Signatures are verified using

class
PK_Verifier
¶ 
PK_Verifier
(const Public_Key &pub_key, const std::string &emsa, Signature_Format format = IEEE_1363)¶ Construct a new verifier for signatures associated with public key pub_key. The emsa and format should be the same as that used by the signer.

void
update
(const uint8_t *in, size_t length)¶

void
update
(const std::vector<uint8_t> &in)¶

void
update
(uint8_t in)¶ Add further message data that is purportedly associated with the signature that will be checked.

bool
check_signature
(const uint8_t *sig, size_t length)¶

bool
check_signature
(const std::vector<uint8_t> &sig)¶ Check to see if sig is a valid signature for the message data that was written in. Return true if so. This function clears the internal message state, so after this call you can call
PK_Verifier::update
to start verifying another message.

bool
verify_message
(const uint8_t *msg, size_t msg_length, const uint8_t *sig, size_t sig_length)¶

bool
verify_message
(const std::vector<uint8_t> &msg, const std::vector<uint8_t> &sig)¶ These are equivalent to calling
PK_Verifier::update
on msg and then callingPK_Verifier::check_signature
on sig.

Botan implements the following signature algorithms:
 RSA
 DSA
 ECDSA
 ECGDSA
 ECKDSA
 GOST 34.102001
 Ed25519
 SM2
Code Example¶
The following sample program below demonstrates the generation of a new ECDSA keypair over the curve secp512r1 and a ECDSA signature using EMSA1 with SHA256. Subsequently the computed signature is validated.
#include <botan/auto_rng.h>
#include <botan/ecdsa.h>
#include <botan/ec_group.h>
#include <botan/pubkey.h>
#include <botan/hex.h>
#include <iostream>
int main()
{
Botan::AutoSeeded_RNG rng;
// Generate ECDSA keypair
Botan::ECDSA_PrivateKey key(rng, Botan::EC_Group("secp521r1"));
std::string text("This is a tasty burger!");
std::vector<uint8_t> data(text.data(),text.data()+text.length());
// sign data
Botan::PK_Signer signer(key, rng, "EMSA1(SHA256)");
signer.update(data);
std::vector<uint8_t> signature = signer.signature(rng);
std::cout << "Signature:" << std::endl << Botan::hex_encode(signature);
// verify signature
Botan::PK_Verifier verifier(key, "EMSA1(SHA256)");
verifier.update(data);
std::cout << std::endl << "is " << (verifier.check_signature(signature)? "valid" : "invalid");
return 0;
}
Key Agreement¶
You can get a hold of a PK_Key_Agreement_Scheme
object by calling
get_pk_kas
with a key that is of a type that supports key
agreement (such as a DiffieHellman key stored in a DH_PrivateKey
object), and the name of a key derivation function. This can be “Raw”,
meaning the output of the primitive itself is returned as the key, or
“KDF1(hash)” or “KDF2(hash)” where “hash” is any string you happen to
like (hopefully you like strings like “SHA256” or “RIPEMD160”), or
“X9.42PRF(keywrap)”, which uses the PRF specified in ANSI X9.42. It
takes the name or OID of the key wrap algorithm that will be used to
encrypt a content encryption key.
How key agreement works is that you trade public values with some
other party, and then each of you runs a computation with the other’s
value and your key (this should return the same result to both
parties). This computation can be called by using
derive_key
with either a byte array/length pair, or a
secure_vector<uint8_t>
than holds the public value of the other
party. The last argument to either call is a number that specifies how
long a key you want.
Depending on the KDF you’re using, you might not get back a key
of the size you requested. In particular “Raw” will return a number
about the size of the DiffieHellman modulus, and KDF1 can only return
a key that is the same size as the output of the hash. KDF2, on the
other hand, will always give you a key exactly as long as you request,
regardless of the underlying hash used with it. The key returned is a
SymmetricKey
, ready to pass to a block cipher, MAC, or other
symmetric algorithm.
The public value that should be used can be obtained by calling
public_data
, which exists for any key that is associated with a
key agreement algorithm. It returns a secure_vector<uint8_t>
.
“KDF2(SHA256)” is by far the preferred algorithm for key derivation in new applications. The X9.42 algorithm may be useful in some circumstances, but unless you need X9.42 compatibility, KDF2 is easier to use.
Botan implements the following key agreement methods:
 ECDH over GF(p) Weierstrass curves
 ECDH over x25519
 DH over prime fields
 McEliece
 NewHope
Code Example¶
The code below performs an unauthenticated ECDH key agreement using the secp521r elliptic curve and applies the key derivation function KDF2(SHA256) with 256 bit output length to the computed shared secret.
#include <botan/auto_rng.h>
#include <botan/ecdh.h>
#include <botan/ec_group.h>
#include <botan/pubkey.h>
#include <botan/hex.h>
#include <iostream>
int main()
{
Botan::AutoSeeded_RNG rng;
// ec domain and
Botan::EC_Group domain("secp521r1");
std::string kdf = "KDF2(SHA256)";
// generate ECDH keys
Botan::ECDH_PrivateKey keyA(rng, domain);
Botan::ECDH_PrivateKey keyB(rng, domain);
// Construct key agreements
Botan::PK_Key_Agreement ecdhA(keyA,rng,kdf);
Botan::PK_Key_Agreement ecdhB(keyB,rng,kdf);
// Agree on shared secret and derive symmetric key of 256 bit length
Botan::secure_vector<uint8_t> sA = ecdhA.derive_key(32,keyB.public_value()).bits_of();
Botan::secure_vector<uint8_t> sB = ecdhB.derive_key(32,keyA.public_value()).bits_of();
if(sA != sB)
return 1;
std::cout << "agreed key: " << std::endl << Botan::hex_encode(sA);
return 0;
}
McEliece¶
McEliece is a cryptographic scheme based on error correcting codes which is thought to be resistant to quantum computers. First proposed in 1978, it is fast and patentfree. Variants have been proposed and broken, but with suitable parameters the original scheme remains secure. However the public keys are quite large, which has hindered deployment in the past.
The implementation of McEliece in Botan was contributed by cryptosource GmbH. It is based on the implementation HyMES, with the kind permission of Nicolas Sendrier and INRIA to release a C++ adaption of their original C code under the Botan license. It was then modified by Falko Strenzke to add side channel and fault attack countermeasures. You can read more about the implementation at http://www.cryptosource.de/docs/mceliece_in_botan.pdf
Encryption in the McEliece scheme consists of choosing a message block of size n, encoding it in the error correcting code which is the public key, then adding t bit errors. The code is created such that knowing only the public key, decoding t errors is intractable, but with the additional knowledge of the secret structure of the code a fast decoding technique exists.
The McEliece implementation in HyMES, and also in Botan, uses an optimization to reduce the public key size, by converting the public key into a systemic code. This means a portion of the public key is a identity matrix, and can be excluded from the published public key. However it also means that in McEliece the plaintext is represented directly in the ciphertext, with only a small number of bit errors. Thus it is absolutely essential to only use McEliece with a CCA2 secure scheme.
One such scheme, KEM, is provided in Botan currently. It it a somewhat unusual
scheme in that it outputs two values, a symmetric key for use with an AEAD, and
an encrypted key. It does this by choosing a random plaintext (n  log2(n)*t
bits) using McEliece_PublicKey::random_plaintext_element
. Then a random
error mask is chosen and the message is coded and masked. The symmetric key is
SHA512(plaintext  error_mask). As long as the resulting key is used with a
secure AEAD scheme (which can be used for transporting arbitrary amounts of
data), CCA2 security is provided.
In mcies.h
there are functions for this combination:

secure_vector<uint8_t>
mceies_encrypt
(const McEliece_PublicKey &pubkey, const secure_vector<uint8_t> &pt, uint8_t ad[], size_t ad_len, RandomNumberGenerator &rng, const std::string &aead = "AES256/OCB")¶

secure_vector<uint8_t>
mceies_decrypt
(const McEliece_PrivateKey &privkey, const secure_vector<uint8_t> &ct, uint8_t ad[], size_t ad_len, const std::string &aead = "AES256/OCB")¶
For a given security level (SL) a McEliece key would use parameters n and t, and have the corresponding key sizes listed:
SL  n  t  public key KB  private key KB 

80  1632  33  59  140 
107  2280  45  128  300 
128  2960  57  195  459 
147  3408  67  265  622 
191  4624  95  516  1234 
256  6624  115  942  2184 
You can check the speed of McEliece with the suggested parameters above
using botan speed McEliece
eXtended Merkle Signature Scheme (XMSS)¶
Botan implements the single tree version of the eXtended Merkle Signature Scheme (XMSS) using Winternitz One Time Signatures+ (WOTS+). The implementation is based on IETF InternetDraft “XMSS: Extended HashBased Signatures”.
XMSS uses the Botan interfaces for public key cryptography. The following algorithms are implemented:
 XMSS_SHA2256_W16_H10
 XMSS_SHA2256_W16_H16
 XMSS_SHA2256_W16_H20
 XMSS_SHA2512_W16_H10
 XMSS_SHA2512_W16_H16
 XMSS_SHA2512_W16_H20
 XMSS_SHAKE128_W16_H10
 XMSS_SHAKE128_W16_H10
 XMSS_SHAKE128_W16_H10
 XMSS_SHAKE256_W16_H10
 XMSS_SHAKE256_W16_H10
 XMSS_SHAKE256_W16_H10
Code Example¶
The following code snippet shows a minimum example on how to create an XMSS public/private key pair and how to use these keys to create and verify a signature:
#include <botan/botan.h>
#include <botan/auto_rng.h>
#include <botan/xmss.h>
int main()
{
// Create a random number generator used for key generation.
Botan::AutoSeeded_RNG rng;
// create a new public/private key pair using SHA2 256 as hash
// function and a tree height of 10.
Botan::XMSS_PrivateKey private_key(
Botan::XMSS_Parameters::xmss_algorithm_t::XMSS_SHA2_256_W16_H10,
rng);
Botan::XMSS_PublicKey public_key(private_key);
// create signature operation using the private key.
std::unique_ptr<Botan::PK_Ops::Signature> sig_op =
private_key.create_signature_op(rng, "", "");
// create and sign a message using the signature operation.
Botan::secure_vector<uint8_t> msg { 0x01, 0x02, 0x03, 0x04 };
sig_op>update(msg.data(), msg.size());
Botan::secure_vector<uint8_t> sig = sig_op>sign(rng);
// create verification operation using the public key
std::unique_ptr<Botan::PK_Ops::Verification> ver_op =
public_key.create_verification_op("", "");
// verify the signature for the previously generated message.
ver_op>update(msg.data(), msg.size());
if(ver_op>is_valid_signature(sig.data(), sig.size()))
{
std::cout << "Success." << std::endl;
}
else
{
std::cout << "Error." << std::endl;
}
}