# [RFC] OpenSSL provider-based algorithms and post-quantum cryptography support

- Thread: https://externals.io/message/132629
- Original archive: https://news-web.php.net/php.internals/132629
- Started by Alexander Danilov on 2026-09-25T07:27:02+00:00
- Messages: 1
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #132629 — Alexander Danilov — 2026-09-25T07:27:02+00:00

URL: https://externals.io/message/132629#132629

> In particular, I'd be interested in opinions on whether provider-based
 > key support and the KEM API should be addressed in a single RFC or
 > split into separate proposals.

These proposals seem reasonable to me on their own.

1) `openssl_pkey_get_details()` should just return the algorithm name as
    OpenSSL gives it to us. And for key generation, we can let pass the
    algorithm name explicitly in OpenSSL's own terms — right now it's
    inferred from whatever key happens to be set in the options array,
    which is a bit indirect.

2) Generic KEM encapsulate/decapsulate. This isn't new — there's
    an old thread (https://externals.io/message/126392) from a while
    back where it was basically agreed the functions should exist,
    but it stalled on naming/signature discussions and nothing ever
    landed. I doubt anyone objects to the functions themselves, it's
    really just a matter of picking names and getting it done this time.

I'd rather not lump everything into one big RFC — these two feel
like they can be handled separately from the PQC discussion.

Also, if you need, I'd be happy to help you implement both of these.

 > I'd like to start a discussion about improving support for modern
 > OpenSSL provider-based asymmetric algorithms in ext/openssl, in
 > particular post-quantum cryptography (PQC).

As for PQC specifically: I went through ext/openssl against OpenSSL
3.5/4.0's PQC support. Turns out a lot of it already works unmodified
— PEM key loading, `openssl_sign()`/verify(), CSR/certs, CMS on
OpenSSL >= 4.0, and X25519MLKEM768-by-default TLS all just work as-is.

What's actually missing, and purely additive:

- type is now -1 in `openssl_pkey_get_details()` return
value
- new parameters support in key generation
- TLS group selection/introspection
- ML-DSA's context-string/deterministic signing params

None of that needs an RFC, going by the Curve25519/448 precedent from
8.4. I'm willing to send these as a handful of small PRs, announced
separately, and leave the generic name-based key gen + KEM API in
this RFC / RFCs, where Timo's already offering to drive the design.

Also drafted tests for the "already works" list, passing on
3.5.8/4.0.2, ready to open.

Does that split work for you?

The PRs above would target 8.7 (master).

--
Thanks,
Danilov Alexander