The Daily Commit · Edición de sección Portada PHP AI Dev EN DE FR ES

The Php Times

RFC Watch — Ecosistema

Abierta la discusión de un RFC para algoritmos OpenSSL por provider y criptografía postcuántica en ext/openssl


Timo Poppinga ha abierto una discusión en la lista internals sobre un RFC para exponer de forma genérica los algoritmos por provider de OpenSSL en ext/openssl.

PHP INTERNALS ([RFC]/[VOTE]), 5 de septiembre de 2026 seleccionado por Sönke

El objetivo es soportar algoritmos postcuánticos como ML-KEM, ML-DSA y SLH-DSA, incluida la encapsulación KEM, sin constantes PHP por algoritmo.

Timo Poppinga ha iniciado una discusión en la lista de internals de PHP para mejorar el soporte de algoritmos asimétricos basados en providers de OpenSSL en ext/openssl, con foco en la criptografía postcuántica. La propuesta se relaciona con los issues 22862 y 23421 de php-src.

Las versiones recientes de OpenSSL incluyen algoritmos PQC estandarizados como ML-KEM, ML-DSA y SLH-DSA a través de las API EVP/provider. La extensión OpenSSL de PHP expone actualmente la criptografía asimétrica mediante un conjunto fijo de constantes OPENSSL_KEYTYPE_* y no ofrece acceso a las operaciones genéricas de encapsulación y desencapsulación KEM.

En lugar de añadir constantes y API por algoritmo, el RFC expondría el modelo de providers de forma genérica: generación de claves por nombre de algoritmo de OpenSSL, algoritmos por provider sin constante keytype propia, operaciones KEM genéricas y firmas con algoritmos como ML-DSA y SLH-DSA a través de las API de firma existentes cuando sea posible. Los futuros algoritmos y providers de terceros funcionarían así con la misma API.

Poppinga estima que el esfuerzo de implementación sería contenido, ya que OpenSSL aporta las primitivas, pero señala como puntos delicados la gestión de claves, la compatibilidad de providers, el manejo de errores y el soporte de versiones de OpenSSL. No piensa escribir el código C personalmente, alega que sus conocimientos de C están oxidados y que el tema es crítico para la seguridad, y pide que un mantenedor de ext/openssl lo implemente o lo supervise de cerca. Él se encargaría del texto del RFC, el diseño de la API, la documentación y las pruebas.

Pregunta abierta a la lista: si el soporte de claves por provider y la API KEM deben ir en un único RFC o en dos propuestas separadas.

Leer la fuente original (en inglés) ↗

Valora este artículo: 0

Tribuna de lectores

Aún no hay aportaciones — abre el debate.

← Ecosistema — Page B1

"All the Code That's Fit to Ship" · The Daily Commit · Edición de pantalla · Información legal · Política de privacidad