The Php Times

Timo Poppinga hat auf der PHP-Internals-Liste eine Diskussion über bessere Unterstützung für OpenSSL-Provider-basierte asymmetrische Algorithmen in ext/openssl gestartet, mit Schwerpunkt auf Post-Quanten-Kryptographie. Der Vorschlag bezieht sich auf die php-src-Issues 22862 und 23421.

Aktuelle OpenSSL-Versionen bringen standardisierte PQC-Algorithmen wie ML-KEM, ML-DSA und SLH-DSA über die EVP/Provider-APIs mit. Die OpenSSL-Erweiterung von PHP bildet asymmetrische Kryptographie derzeit über einen festen Satz von OPENSSL_KEYTYPE_*-Konstanten ab und bietet keinen Zugriff auf generische KEM-Kapselung und -Entkapselung.

Statt Konstanten und APIs pro Algorithmus hinzuzufügen, soll der RFC das Provider-Modell generisch abbilden: Schlüsselerzeugung per OpenSSL-Algorithmusname, Provider-basierte Algorithmen ohne eigene Keytype-Konstante, generische KEM-Operationen sowie Signaturen über Algorithmen wie ML-DSA und SLH-DSA über die bestehenden Signatur-APIs, soweit möglich. Künftige Algorithmen und Drittanbieter-Provider würden dann über dieselbe API funktionieren.

Poppinga schätzt den Implementierungsaufwand als überschaubar ein, da OpenSSL die Primitives bereits liefert, nennt aber Schlüsselverwaltung, Provider-Kompatibilität, Fehlerbehandlung und OpenSSL-Versionsunterstützung als heikle Punkte. Den C-Teil will er ausdrücklich nicht selbst schreiben, seine C-Kenntnisse seien eingerostet und das Thema sicherheitskritisch. Er bittet einen ext/openssl-Maintainer um Implementierung oder enge Begleitung und übernimmt selbst RFC-Text, API-Design, Dokumentation und Tests.

Offene Frage an die Runde: ob Provider-basierte Schlüsselunterstützung und KEM-API in einen einzigen RFC gehören oder in zwei getrennte Vorschläge.