The Php Times

Timo Poppinga a lancé une discussion sur la liste PHP internals pour améliorer la prise en charge des algorithmes asymétriques basés sur les providers OpenSSL dans ext/openssl, avec un accent sur la cryptographie post-quantique. La proposition est liée aux tickets php-src 22862 et 23421.

Les versions récentes d'OpenSSL fournissent des algorithmes PQC standardisés comme ML-KEM, ML-DSA et SLH-DSA via les API EVP/provider. L'extension OpenSSL de PHP expose aujourd'hui la cryptographie asymétrique à travers un ensemble fixe de constantes OPENSSL_KEYTYPE_* et ne donne pas accès aux opérations génériques d'encapsulation et de désencapsulation KEM.

Plutôt que d'ajouter des constantes et des API par algorithme, le RFC exposerait le modèle provider de façon générique : génération de clés par nom d'algorithme OpenSSL, algorithmes provider sans constante keytype dédiée, opérations KEM génériques, et signatures via des algorithmes comme ML-DSA et SLH-DSA à travers les API de signature existantes lorsque possible. Les futurs algorithmes et les providers tiers fonctionneraient alors via la même API.

Poppinga estime l'effort d'implémentation contenu puisque OpenSSL fournit les primitives, mais signale la gestion des clés, la compatibilité des providers, la gestion des erreurs et le support des versions d'OpenSSL comme points délicats. Il ne prévoit pas d'écrire le code C lui-même, invoquant des compétences C rouillées et la sensibilité sécuritaire du sujet, et demande qu'un mainteneur d'ext/openssl implémente ou supervise étroitement le travail. Il prendra en charge le texte du RFC, la conception de l'API, la documentation et les tests.

Question ouverte aux retours : le support des clés basées sur les providers et l'API KEM doivent-ils former un seul RFC ou deux propositions distinctes.