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.
- QUIC server
- External QUIC library interface
- Post-quantum cryptography
- Hybrid ML-KEM in TLS v1.3
- 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,1 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
-
The author, Eric Young, mentioned parts of it were already out-of-date as of 22 Jun 1996. It was removed from OpenSSL in 2015. ↩︎