The Features of 3.5: EVP_SKEY

This is the fifth in a series of posts about the features of OpenSSL 3.5. Its target audience is people who are curious about internet security, but who don’t recognize the acronyms in that list.

1. QUIC server
2. External QUIC library interface
3. Post-quantum cryptography
4. Hybrid ML-KEM in TLS v1.3
5. EVP_SKEY

In this series we are explaining the acronyms used by the developers of OpenSSL. While it’s handy, necessary even, to have a shorthand for complicated cryptography concepts, that shorthand stands as a barrier for non-experts seeking to understand.

Previously we explained the difference between public keys and symmetric keys. In short, anyone can use a public key to encrypt a message that can only be decrypted with a matching private key, but a symmetric key is used both to encrypt and decrypt. In the OpenSSL code, PKEY represents both a private key and the matching public key. (It’s handy that “public” and “private” start with P.) Naturally, then, SKEY ought to signify a symmetric key, which indeed it does.

Less easy to explain is EVP. In the OpenSSL world it’s a bit like VAT or ATM. We know what those mean conceptually without needing to dredge up the words underlying the acronym. Sometimes the acronym officially loses a connection to the underlying words. (See: QUIC, for instance.) In practice everyone just learns that EVP means “high-level cryptographic functions”. But what do those letters stand for?

After a bit of digging I found a clue in the answers to this Stack Overflow question. That, in turn, led me to ssleay.txt, a file archiving documentation from the SSLeay project that predates and provided the foundation for OpenSSL. While the documentation is obsolete,¹ it does provide some relevant history:

EVP	The Digital EnVeloPe library is quite large.  At [its] core are
	[functions] to perform encryption and decryption by parts while using
	an initial parameter to specify which of the 17 different ciphers
	or 4 different message digests to use.  On top of these are [implemented]
	the digital signature functions, sign, verify, seal and open.
	Base64 encoding of binary data is also done in this library.

Reproduction of a 1906 Stanley Steamer, which runs on steam power.

In computer science terms, EVP represents an abstraction that hides the details of the specific cipher used under the hood. As a driver, I’m rarely concerned whether the engine is a diesel, straight-four or V8. These days it’s just as likely to be a hybrid or electric motor instead and there’s no particular difficulty adapting because they all operate similarly from the driver’s perspective. The steering wheel and pedals are the “high-level functions” of vehicle operation.

In the same way, EVP functions allow developers to write programs that can use a range of algorithms, including algorithms that haven’t been invented yet. EVP_PKEY is a data structure that can hold any sort of asymmetric key that has been implemented for OpenSSL. So as soon as ML-KEM was implemented in 3.5, code originally written with some other algorithm could be updated to use ML-KEM with a simple configuration change.

The abstraction for asymmetric keys has been with OpenSSL since the beginning. But prior to 3.5 symmetric keys have always been stored using a byte array in memory. Dmitry Belyavskiy, an OpenSSL committer employed by Red Hat, decided to introduce EVP_SKEY while developing code for integrating with hardware security modules (HSM). These devices manage cryptographic keys and it’s not advisable to put those keys into memory. The EVP_SKEY abstraction means OpenSSL can use secret keys stored in hardware without ever having access to them.

This abstraction can also be called an “opaque key” because the actual key can’t be examined directly. Now that OpenSSL 3.5 has been released, the developers of third-party providers can add EVP_SKEY functionality so that symmetric keys aren’t exposed even in memory. In the world of OpenSSL, a provider allows code to be added to OpenSSL to support new algorithms and operations. The PKCS#11 provider, which allows OpenSSL to interface with smart cards and hardware security modules, already has plans to use EVP_SKEY functionality so that secret keys never come out of the hardware.

The OpenSSL Foundation thanks Dmitry Belyavskiy and Simo Sorce who contributed to this feature.

For more information, see:

• Is there any plan to implement symmetric algorithm like AES-GCM/CCM for TLS
• EVP_SKEY implementation for symmetric cipher and MACs
• EVP_SKEY Design

Image of Stanley Steamer: Joe Ross from Lansing, Michigan, CC BY-SA 2.0, via Flickr