OSSL-GUIDE-L...-INTRODUCTION(7SSL)

๐Ÿ’– OSSL-GUIDE-LIBCRYPTO-INTRODUCTION โ€” aka ossl-guide-libcrypto-introduction, crypto ๐Ÿ’–

okay bestie, welcome to the OpenSSL Guide: An introduction to libcrypto ๐ŸŽ€ this is the 7SSL one, and it's the moment you finally meet the library that's been running the whole internet's group chat behind the scenes. grab a snack, we're going in ๐Ÿฆ‹


โœจ INTRODUCTION โœจ

so the OpenSSL cryptography library โ€” everybody calls it "libcrypto" โ€” is basically your all-access pass to a huge range of cryptographic algorithms that get used all over Internet standards ๐ŸŒˆ. The services it hands out? The OpenSSL implementations of TLS and CMS use them, and a whole bunch of other third-party products and protocols have used them too. iconic behaviour, honestly ๐Ÿ‘‘

what's actually in the menu:

  • symmetric encryption
  • public key cryptography
  • key agreement
  • certificate handling
  • cryptographic hash functions
  • cryptographic pseudo-random number generators
  • message authentication codes (MACs)
  • key derivation functions (KDFs)
  • and various utilities ๐Ÿ’…

๐Ÿงฎ Algorithms

cryptographic primitives โ€” like the SHA256 digest, or AES encryption โ€” get called "algorithms" in OpenSSL-speak. and lowkey the interesting bit: each algorithm can have multiple implementations available to you. for example, the RSA algorithm shows up as a "default" implementation that's good for general use, AND a "fips" implementation that's been validated to FIPS 140 standards for when that actually matters. also?? a third party could absolutely add more implementations, like in a hardware security module (HSM) ๐Ÿงš

algorithms live inside providers. go read ossl-guide-libraries-introduction(7) for the whole provider tea โ˜•

โš™๏ธ Operations

different algorithms can be grouped together by purpose. like, there are algorithms for encryption, and totally different algorithms for digesting data. these groups are called "operations" in OpenSSL ๐Ÿซถ, and each operation has its own little set of functions attached to it.

for example:

  • wanna do an encryption operation with AES (or literally any other encryption algorithm)? you use the encryption functions on the EVP_EncryptInit(3) page.
  • wanna do a digest operation with SHA256? you use the digesting functions on the EVP_DigestInit(3) page.

see how it's organised? obsessed ๐Ÿ˜Œ


๐Ÿ” ALGORITHM FETCHING ๐Ÿ”

okay so to actually use an algorithm, an implementation for it has to be "fetched" first. fetching = the process of:

  1. looking through the available implementations,
  2. applying selection criteria (via a property query string),
  3. and finally choosing the implementation that will be used โœจ

OpenSSL supports two flavours of fetching โ€” "Explicit fetching" and "Implicit fetching" ๐Ÿ’–

๐ŸŽฏ Explicit fetching

explicit fetching is when you directly call a specific API to fetch an algorithm implementation from a provider. the fetched object can then be passed to other APIs. these explicit fetching functions usually have the name APINAME_fetch, where APINAME is the name of the operation. for example EVP_MD_fetch(3) can be used to explicitly fetch a digest algorithm implementation. and bestie, you are responsible for freeing the object returned from the APINAME_fetch function โ€” use APINAME_free when you don't need it anymore. don't forget, that's a leak ๐Ÿซ 

these fetching functions follow a pretty common pattern where three arguments get passed:

  • The library context โ€” see OSSL_LIB_CTX(3) for the full description. this may be NULL to signify the default (global) library context, or a context created by the user. only providers loaded in this library context (see OSSL_PROVIDER_load(3)) will be considered by the fetching function. and in case no provider has been loaded in this library context, then the default provider will be loaded as a fallback (see OSSL_PROVIDER-default(7)). ๐Ÿซถ
  • An identifier โ€” for all currently implemented fetching functions this is the algorithm name. each provider supports a list of algorithm implementations. see the provider specific documentation for info on what's available in each one: "OPERATIONS AND ALGORITHMS" in OSSL_PROVIDER-default(7), "OPERATIONS AND ALGORITHMS" in OSSL_PROVIDER-FIPS(7), "OPERATIONS AND ALGORITHMS" in OSSL_PROVIDER-legacy(7) and "OPERATIONS AND ALGORITHMS" in OSSL_PROVIDER-base(7).
โš ๏ธ heads up bestie: while providers may register algorithms against a list of names using a string with a colon separated list of names, fetching algorithms using that format is currently unsupported. so don't try it ๐Ÿ’€
  • A property query string โ€” the property query string used to guide selection of the algorithm implementation. see "PROPERTY QUERY STRINGS" in ossl-guide-libraries-introduction(7). โœจ

so the algorithm implementation that gets fetched can then be used with other diverse functions that use them. for example, the EVP_DigestInit_ex(3) function takes as a parameter an EVP_MD object which may have been returned from an earlier call to EVP_MD_fetch(3). cute, right? ๐Ÿ’…

๐ŸŒ™ Implicit fetching

OpenSSL has a bunch of functions that return an algorithm object with no associated implementation, like EVP_sha256(3), EVP_aes_128_cbc(3), EVP_get_cipherbyname(3) or EVP_get_digestbyname(3). these stick around for compatibility with OpenSSL before version 3.0, back when explicit fetching wasn't a thing yet. nostalgia core ๐Ÿ˜ญ

when you use them with functions like EVP_DigestInit_ex(3) or EVP_CipherInit_ex(3), the actual implementation to be used gets fetched implicitly using default search criteria (which uses NULL for the library context and property query string).

and in some cases, implicit fetching can also occur when a NULL algorithm parameter is supplied. in that case an algorithm implementation is implicitly fetched using default search criteria and an algorithm name that is consistent with the context in which it is being used ๐ŸŒ€

functions that use an EVP_PKEY_CTX or an EVP_PKEY(3), such as EVP_DigestSignInit(3), all fetch the implementations implicitly. usually the algorithm to fetch is determined based on the type of key that's being used and the function that's been called.

๐ŸŽ๏ธ Performance

if you perform the same operation many times with the same algorithm, then it is recommended to use a single explicit fetch of the algorithm and then reuse that explicitly fetched algorithm each subsequent time ๐Ÿ”ฅ. this will typically be faster than implicitly fetching the algorithm every single time you use it. there's an example of Explicit fetching down in "USING ALGORITHMS IN APPLICATIONS" ๐Ÿ‘€

prior to OpenSSL 3.0, functions such as EVP_sha256() which return a "const" object were used directly to indicate the algorithm to use in various function calls. if you pass the return value of one of these convenience functions to an operation, then you are using implicit fetching. and if you're converting an application that worked with an OpenSSL version prior to OpenSSL 3.0, then consider changing instances of implicit fetching to explicit fetching instead. glow up โœจ

if an explicitly fetched object is not passed to an operation, then any implicit fetch will use an internally cached prefetched object โ€” but it will still be slower than passing the explicitly fetched object directly. no cap ๐Ÿซก

the following functions can be used for explicit fetching:

  • EVP_MD_fetch(3) โ€” fetch a message digest/hashing algorithm implementation.
  • EVP_CIPHER_fetch(3) โ€” fetch a symmetric cipher algorithm implementation.
  • EVP_KDF_fetch(3) โ€” fetch a Key Derivation Function (KDF) algorithm implementation.
  • EVP_MAC_fetch(3) โ€” fetch a Message Authentication Code (MAC) algorithm implementation.
  • EVP_KEM_fetch(3) โ€” fetch a Key Encapsulation Mechanism (KEM) algorithm implementation.
  • OSSL_ENCODER_fetch(3) โ€” fetch an encoder algorithm implementation (e.g. to encode keys to a specified format).
  • OSSL_DECODER_fetch(3) โ€” fetch a decoder algorithm implementation (e.g. to decode keys from a specified format).
  • EVP_RAND_fetch(3) โ€” fetch a Pseudo Random Number Generator (PRNG) algorithm implementation.

and go check "OPERATIONS AND ALGORITHMS" in OSSL_PROVIDER-default(7), "OPERATIONS AND ALGORITHMS" in OSSL_PROVIDER-FIPS(7), "OPERATIONS AND ALGORITHMS" in OSSL_PROVIDER-legacy(7) and "OPERATIONS AND ALGORITHMS" in OSSL_PROVIDER-base(7) for the full list of algorithm names that can be fetched ๐Ÿงพ


๐Ÿ“ FETCHING EXAMPLES ๐Ÿ“

this whole section is a series of examples of fetching algorithm implementations. show don't tell, main character energy ๐Ÿ‘‘

Fetch any available implementation of SHA2-256 in the default context. note that some algorithms have aliases โ€” so "SHA256" and "SHA2-256" are synonymous ๐Ÿ’ซ

EVP_MD *md = EVP_MD_fetch(NULL, "SHA2-256", NULL);
...
EVP_MD_free(md);

Fetch any available implementation of AES-128-CBC in the default context:

EVP_CIPHER *cipher = EVP_CIPHER_fetch(NULL, "AES-128-CBC", NULL);
...
EVP_CIPHER_free(cipher);

Fetch an implementation of SHA2-256 from the default provider in the default context:

EVP_MD *md = EVP_MD_fetch(NULL, "SHA2-256", "provider=default");
...
EVP_MD_free(md);

Fetch an implementation of SHA2-256 that is not from the default provider in the default context:

EVP_MD *md = EVP_MD_fetch(NULL, "SHA2-256", "provider!=default");
...
EVP_MD_free(md);

Fetch an implementation of SHA2-256 that is preferably from the FIPS provider in the default context:

EVP_MD *md = EVP_MD_fetch(NULL, "SHA2-256", "provider=?fips");
...
EVP_MD_free(md);

Fetch an implementation of SHA2-256 from the default provider in the specified library context:

EVP_MD *md = EVP_MD_fetch(libctx, "SHA2-256", "provider=default");
...
EVP_MD_free(md);

Load the legacy provider into the default context and then fetch an implementation of WHIRLPOOL from it:

/* This only needs to be done once - usually at application start up */
OSSL_PROVIDER *legacy = OSSL_PROVIDER_load(NULL, "legacy");

EVP_MD *md = EVP_MD_fetch(NULL, "WHIRLPOOL", "provider=legacy");
...
EVP_MD_free(md);
๐Ÿ“Œ note that in the above example the property string "provider=legacy" is optional, since โ€” assuming no other providers have been loaded โ€” the only implementation of the "whirlpool" algorithm is in the "legacy" provider. also note that the default provider should be explicitly loaded if it is required in addition to other providers:
/* This only needs to be done once - usually at application start up */
OSSL_PROVIDER *legacy = OSSL_PROVIDER_load(NULL, "legacy");
OSSL_PROVIDER *default = OSSL_PROVIDER_load(NULL, "default");

EVP_MD *md_whirlpool = EVP_MD_fetch(NULL, "whirlpool", NULL);
EVP_MD *md_sha256 = EVP_MD_fetch(NULL, "SHA2-256", NULL);
...
EVP_MD_free(md_whirlpool);
EVP_MD_free(md_sha256);

and that's where part 1 wraps, bestie โ€” more coming ๐ŸŒธ

๐Ÿ’– USING ALGORITHMS IN APPLICATIONS ๐Ÿ’–

so bestie, the โœจteaโœจ is that all the crypto algorithms show up in your app through the "EVP" APIs. every single operation โ€” encryption, digesting, message authentication codes, etc. โ€” has its own lil set of EVP function calls you can summon to do the thing. if you want the deep dive, go read evp(7), that's the lore page ๐ŸŒธ

most of them follow the same lil pattern, and honestly once you clock it you've clocked all of them:

  1. first you make a "context" object. digesting? that's an EVP_MD_CTX. encrypting/decrypting? that's an EVP_CIPHER_CTX ๐Ÿ’…
  2. then you initialise it for use with an "init" function โ€” and you can optionally pass in a set of parameters (that's the OSSL_PARAM(3) type, iykyk) to configure how the operation behaves โœจ
  3. then you feed data in with a bunch of "update" calls ๐Ÿ“
  4. then you finalise with a "final" call, which usually hands you some output ๐ŸŽ€
  5. and finally you clean up and free the context, like the responsible main character you are ๐Ÿ‘‘

and here's a whole complete example of that process for digesting data with SHA256. the process is basically the same for other operations like encryption/decryption, signatures, message authentication codes, etc. there's even more examples chilling in the OpenSSL demos (peep "DEMO APPLICATIONS" in ossl-guide-libraries-introduction(7)) ๐Ÿฆ‹

#include <stdio.h>
#include <openssl/evp.h>
#include <openssl/bio.h>
#include <openssl/err.h>

int main(void)
{
    EVP_MD_CTX *ctx = NULL;
    EVP_MD *sha256 = NULL;
    const unsigned char msg[] = {
        0x00, 0x01, 0x02, 0x03
    };
    unsigned int len = 0;
    unsigned char *outdigest = NULL;
    int ret = 1;

    /* Create a context for the digest operation */
    ctx = EVP_MD_CTX_new();
    if (ctx == NULL)
        goto err;

    /*
     * Fetch the SHA256 algorithm implementation for doing the digest. We're
     * using the "default" library context here (first NULL parameter), and
     * we're not supplying any particular search criteria for our SHA256
     * implementation (second NULL parameter). Any SHA256 implementation will
     * do.
     * In a larger application this fetch would just be done once, and could
     * be used for multiple calls to other operations such as EVP_DigestInit_ex().
     */
    sha256 = EVP_MD_fetch(NULL, "SHA256", NULL);
    if (sha256 == NULL)
        goto err;

   /* Initialise the digest operation */
   if (!EVP_DigestInit_ex(ctx, sha256, NULL))
       goto err;

    /*
     * Pass the message to be digested. This can be passed in over multiple
     * EVP_DigestUpdate calls if necessary
     */
    if (!EVP_DigestUpdate(ctx, msg, sizeof(msg)))
        goto err;

    /* Allocate the output buffer */
    outdigest = OPENSSL_malloc(EVP_MD_get_size(sha256));
    if (outdigest == NULL)
        goto err;

    /* Now calculate the digest itself */
    if (!EVP_DigestFinal_ex(ctx, outdigest, &len))
        goto err;

    /* Print out the digest result */
    BIO_dump_fp(stdout, outdigest, len);

    ret = 0;

 err:
    /* Clean up all the resources we allocated */
    OPENSSL_free(outdigest);
    EVP_MD_free(sha256);
    EVP_MD_CTX_free(ctx);
    if (ret != 0)
       ERR_print_errors_fp(stderr);
    return ret;
}

๐Ÿ”‘ ENCODING AND DECODING KEYS ๐Ÿ”‘

okay so a ton of algorithms need a key to even function. you can generate keys dynamically with the EVP APIs (for example, look at EVP_PKEY_Q_keygen(3)), but likeโ€ฆ realistically you're gonna need to save or load keys (or their associated parameters) to/from some external format like PEM or DER (see openssl-glossary(7) for the format tea โ˜•). and that's literally what OpenSSL's encoders and decoders are for ๐Ÿ’…

here's the cute part: encoders and decoders are just algorithm implementations, same as literally every other algorithm implementation in OpenSSL. providers implement them. the OpenSSL encoders and decoders live in the default provider, and they're also duplicated in the base provider ๐ŸŒˆ

and also, besides using encoders/decoders directly, there are some helper functions for certain well known and commonly used formats. for example peep PEM_read_PrivateKey(3) and PEM_write_PrivateKey(3) for reading and writing key data from PEM encoded files ๐ŸŽ€


๐Ÿ“š FURTHER READING ๐Ÿ“š

want an intro to using "libssl"? go read ossl-guide-libssl-introduction(7) bestie, it's right there ๐Ÿ’œ


๐Ÿ‘€ SEE ALSO ๐Ÿ‘€

openssl(1), ssl(7), evp(7), OSSL_LIB_CTX(3), openssl-threads(7), property(7), OSSL_PROVIDER-default(7), OSSL_PROVIDER-base(7), OSSL_PROVIDER-FIPS(7), OSSL_PROVIDER-legacy(7), OSSL_PROVIDER-null(7), openssl-glossary(7), provider(7)


Copyright 2000-2024 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the "License"). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.


and that's a wrap, bestie ๐Ÿซถ this was version 4.0.3, dated 2026-09-29, and it ate, no crumbs left ๐Ÿ’…โœจ go forth and digest, or encode, or whatever your heart desires ๐Ÿ‘‘๐ŸŒธ

๐Ÿ“ฆ where this page comes from