Add evp_pkey perftool

[andrewkdinh]

Summary

This CLI tool that generates keys using a given algorithm.
Runs for 5 seconds and prints the average execution time per key generation.

Fixes openssl/project#1877

Features

• Two modes of operation:
  • evp_shared (default): Use EVP API and allow shared data between computations
  • evp_isolated: Use EVP API and don't allow shared data between computations
• Configurable number of times to update
• Terse output for easier CI automation (-t)
• Configurable thread count

Usage

$ ./evp_pkey -h
Usage: evp_pkey [-h] [-t] [-o operation] [-a algorithm] [-V] thread-count
-h - print this help output
-t - terse output
-o operation - mode of operation. One of [evp_isolated, evp_shared] (default: evp_shared)
-a algorithm - algorithm for generated key. One of [RSA, X25519, X448, ED25519, ED448] (default: ED25519)
-V - print version information and exit
thread-count - number of threads

$ ./evp_rand -o evp_shared 10 # evp_shared operation mode, ED25519 algorithm, 10 threads
Average time per key generation: 36.481838us

$ ./evp_rand -o evp_isolated 10 # now using evp_isolated mode
Average time per key generation: 34.623617us

[mbroz]

Shouldn't be this controlled by a parameter? I think 3072/4096 bits RSA is quite common these days.
Anyway, that can be changed later once needed.

[jogme]

+1

[andrewkdinh]

If EVP_PKEY_CTX_set_rsa_keygen_bits isn't called, then by default the RSA key length for RSA key generation is set to 2048 bits. Anyways, I don't think having an extra parameter for this is too useful (especially if other algorithms are added), so I just removed the call to EVP_PKEY_CTX_set_rsa_keygen_bits.

https://docs.openssl.org/master/man3/EVP_PKEY_CTX_ctrl/#rsa-parameters

[jogme]

Makes me wonder if we don't want to test different bit sizes, then what is the actual motivation behind this perftool?

[npajkovsky]

We don't need to test different sizes because we're pref testing alg fetching.

[npajkovsky]

Hmm, we already have that in openssl speed.

[bob-beck]

So this looks to be sort of a "repeat" of the Evp hash one, combined with a test for EVP_pkey - is it not andrew?

This is not meant to be a test of the algorithm itself, but rather to track the overhead of the various methods
we have put in place for people to actually get the point where they can make use of an algorithm

So does it make sense to do this test as effecively, a combination of what it takes to get a hash, and to get a pkey? or should we just have a pkey only test.

[andrewkdinh]

So does it make sense to do this test as effecively, a combination of what it takes to get a hash, and to get a pkey? or should we just have a pkey only test.

@bob-beck I'm not sure either. Does having a pkey only test help us test what we're looking for?

If it were just to be pkey only test, would it essentially just be this?

    if ((pctx = EVP_PKEY_CTX_new_from_name(NULL, "RSA", NULL)) == NULL
        || EVP_PKEY_keygen_init(pctx) <= 0
        || EVP_PKEY_keygen(pctx, &pkey) <= 0) {

[bob-beck]

Effectively yes, I think so.

[bob-beck]

So you should rename this to an EVP_pkey perftest I think, then this is probably fine

[bob-beck]

So I think after the discussion this should be renamed to an evp_pkey perftest, at which
point it's probably good.

[andrewkdinh]

So I think after the discussion this should be renamed to an evp_pkey perftest, at which point it's probably good.

@bob-beck In that case, do we still need individual perftools for EVP_KEM and EVP_SIGNATURE? Because these use EVP_PKEY for their operations

[andrewkdinh]

This PR has been changed to create a perftool evp_pkey that generates keys using a given algorithm

[bob-beck]

Effectively we will want to know what the overhead fro EVP_PKEY is in each of these situations perhaps? on a fast operation, it may dominate, on a slow one it won't matter. I think is we have one reasonable measure for the fastest operations (maybe an ec signature?) that might be fine?

…

On Sat, Feb 21, 2026 at 7:50 PM Andrew Dinh ***@***.***> wrote: *andrewkdinh* left a comment (openssl/perftools#77) <#77 (comment)> So I think after the discussion this should be renamed to an evp_pkey perftest, at which point it's probably good. @bob-beck <https://github.com/bob-beck> In that case, do we still need individual perftools for EVP_KEM and EVP_SIGNATURE? Because these use EVP_PKEY for their operations — Reply to this email directly, view it on GitHub <#77 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB57M5P4QJYMQ4YWJDS25AD4NEKO5AVCNFSM6AAAAACVNMYGBSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTSMZZHE4TKMBUGE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[Sashan]

looks good to me.