RFC 9958 para ingenieros: Guía práctica de campo para la migración a PQC

Respuesta rápida: RFC 9958, «Criptografía postcuántica para ingenieros», es un documento informativo del IETF publicado en junio de 2026 por el grupo de trabajo PQUIP que explica los problemas que surgen al migrar los protocolos a algoritmos postcuánticos: claves y firmas entre 6 y 700 veces más grandes que sus equivalentes clásicos, problemas de fragmentación y pérdida de paquetes en protocolos como IKEv2, sobrecarga de la cadena en PKI y un modelo de implementación híbrido diseñado para superar esta brecha mientras maduran los algoritmos PQC. Esta guía lo traduce en una secuencia de migración práctica para ingenieros.

La mayoría de las guías de PQC se limitan a "usar ML-KEM en lugar de ECDH". El RFC 9958 es diferente. Fue redactado por ingenieros de Nokia, DigiCert y Entrust precisamente porque la sustitución de algoritmos no es lo que dificulta la migración a PQC. Lo que la dificulta es el comportamiento del protocolo con claves y firmas mucho más grandes, y ese comportamiento no se manifiesta hasta que se intenta adaptar una firma ML-DSA-87 de 4,627 bytes a un protocolo diseñado para firmas ECDSA de 64 bytes.

Esta guía traduce el contenido principal del RFC 9958, la realidad del tamaño, los modos de fallo a nivel de protocolo y el modelo de implementación híbrida, en una guía práctica de campo para los ingenieros que realizan el trabajo de migración.

Puntos Clave

• El RFC 9958 es un RFC informativo del grupo de trabajo PQUIP del IETF, publicado en junio de 2026, escrito para explicar el impacto operativo de PQC en lugar de sus cálculos matemáticos.
• Las claves y firmas basadas en retículos son aproximadamente de 6 a 10 veces más grandes que sus equivalentes clásicos para claves públicas, y de 10 a 100 veces más grandes para firmas; las firmas SLH-DSA son hasta 700 veces más grandes que las ECDSA.
• Estos aumentos de tamaño rompen con los supuestos inherentes a los protocolos más antiguos: IKEv2 necesitaba un nuevo "Intercambio Intermedio" (RFC 9242, utilizado por RFC 9370) específicamente para fragmentar los mensajes de intercambio de claves PQC que ya no se ajustaban al diseño original.
• Los esquemas híbridos PQ/T, que combinan un algoritmo clásico y uno post-cuántico, son el puente recomendado: la migración del intercambio de claves es en gran medida autónoma, pero la migración de firmas afecta a los certificados, las CA, los HSM y los anclajes de confianza en todo el ecosistema.
• La reutilización de claves en certificados híbridos y de algoritmo único permite ataques de eliminación de claves. El RFC 9958 establece explícitamente que las claves híbridas deben generarse desde cero y nunca reutilizarse a partir de una clave de algoritmo único existente.

Qué es realmente el RFC 9958

El RFC 9958, «Criptografía postcuántica para ingenieros», es un documento informativo del grupo de trabajo PQUIP (Uso postcuántico en protocolos) del IETF, publicado en junio de 2026. No se trata de una especificación estandarizada ni define un protocolo. Es un documento de referencia, escrito por autores de Nokia, DigiCert y Entrust, dirigido a ingenieros que trabajan en bibliotecas criptográficas, seguridad de redes e infraestructura y que necesitan comprender los cambios que se producen cuando un sistema adopta la criptografía postcuántica (PQC), más allá del simple intercambio de un identificador de algoritmo por otro.

El argumento central del documento es que la migración a PQC no es un simple reemplazo de algoritmos. El intercambio de claves, históricamente gestionado por algoritmos de la familia Diffie-Hellman, y las firmas digitales, históricamente RSA o ECDSA, cambian radicalmente con PQC, y los protocolos construidos en torno a las formas antiguas requieren un trabajo de ingeniería real, no solo una opción de configuración, para adaptarse a la nueva.

La verificación de la realidad del tamaño de la llave y la firma

Este es el número que la mayoría de los ingenieros subestiman hasta que lo ven en una tabla.

Algoritmo	Llave pública	Texto cifrado / firma	Equivalente clásico
X25519 (KEM clásico)	Bytes 32	Bytes 32	-
ML-KEM-768	Bytes 1,184	Bytes 1,088	Aproximadamente 37 veces más grande que el X25519
ML-KEM-1024	Bytes 1,568	Bytes 1,568	Aproximadamente 49 veces más grande que el X25519
ECDSA-P256 (firma clásica)	Bytes 64	Bytes 64	-
ML-DSA-65	Bytes 1,952	Bytes 3,309	Aproximadamente 52 veces más grande que ECDSA-P256
ML-DSA-87	Bytes 2,592	Bytes 4,627	Aproximadamente 72 veces más grande que ECDSA-P256
SLH-DSA-SHA2-128s	Bytes 32	Bytes 7,856	Aproximadamente 123 veces más grande que ECDSA-P256
SLH-DSA-SHA2-256f	Bytes 64	Bytes 49,856	Aproximadamente 779 veces más grande que ECDSA-P256

El RFC 9958 describe las claves y firmas basadas en retículos como aquellas que crecen aproximadamente de 6 a 10 veces para las claves públicas y de 10 a 100 veces para las firmas, en comparación con los esquemas clásicos, considerándolo el mejor equilibrio disponible para uso general. SLH-DSA se sitúa muy por encima de ese rango, razón por la cual se utiliza como alternativa para usos específicos en lugar de como opción predeterminada general.

Descubra cómo HSM-as-a-Service admite proyectos piloto de intercambio de claves ML-KEM sin necesidad de un ciclo de adquisición de hardware.

Por qué estos tamaños rompen los protocolos: fragmentación, tiempos de espera agotados, sobrecarga de la cadena.

Los aumentos de tamaño de esta magnitud no son solo un inconveniente en cuanto al ancho de banda. El RFC 9958 documenta modos de fallo específicos a nivel de protocolo que los ingenieros deben tener en cuenta.

• Fragmentación de UDP en IKEv2: El intercambio IKE_SA_INIT original no admite la fragmentación a nivel IKE, por lo que el material de clave PQC no era compatible. El RFC 9242 introdujo un "Intercambio Intermedio" específicamente para que el RFC 9370 pudiera gestionar el intercambio de claves PQC después del protocolo de enlace inicial, donde la fragmentación está disponible.
• Pérdida de paquetes y tiempos de espera: Los mensajes de intercambio de claves más grandes abarcan más paquetes de red. En condiciones de red con pérdidas, esto aumenta la probabilidad total de perder al menos un paquete en el intercambio, lo que incrementa la latencia del protocolo de enlace y puede provocar tiempos de espera de retransmisión que no ocurrían con los tamaños de clave clásicos.
• Exceso de la cadena PKI: Una cadena de cuatro certificados firmada con ML-DSA-87 en lugar de ECDSA contiene aproximadamente 70 veces más datos de firma por certificado. Si multiplicamos esto por una cadena completa, los protocolos de enlace TLS, las respuestas OCSP y el almacenamiento de certificados aumentan sustancialmente, con repercusiones en el comportamiento de los dispositivos intermedios y la memoria de los dispositivos con recursos limitados.
• Dispositivos restringidos: Los sistemas IoT y los sistemas embebidos que ya estaban optimizados para tamaños de clave clásicos se enfrentan a una mayor latencia en el protocolo de enlace, un mayor consumo de energía y la necesidad de una lógica de fragmentación que muchos nunca fueron diseñados para soportar.

Esquemas híbridos PQ/T: El puente, no el destino.

El RFC 9958 recomienda esquemas híbridos post-cuánticos y tradicionales (PQ/T) como puente práctico durante la migración, porque ni los algoritmos clásicos ni los nuevos algoritmos PQC son totalmente fiables por sí solos: los algoritmos clásicos acabarán sucumbiendo ante un ordenador cuántico criptográficamente relevante, mientras que los algoritmos PQC son más nuevos y están menos probados frente a errores de implementación y debilidades criptoanalíticas desconocidas.

En los estándares actuales se observan dos patrones de acuerdo de clave híbridos. Un esquema concatenado , utilizado en el intercambio de claves híbridas TLS 1.3, combina los dos secretos compartidos mediante concatenación antes de que entren en la función de derivación de clave. Un esquema en cascada , utilizado en la RFC 9370 para IKEv2, aplica la función de derivación de clave una vez por algoritmo en secuencia. En ambos casos, la seguridad resultante se mantiene siempre que al menos un algoritmo componente permanezca seguro, que es precisamente el objetivo de ejecutar algoritmos clásicos y postcuánticos conjuntamente en lugar de cambiarlos directamente.

Una advertencia del RFC 9958 merece ser destacada: las claves híbridas deben generarse desde cero, nunca combinando una clave post-cuántica con una clave clásica ya en uso. Reutilizar una clave clásica entre un certificado de algoritmo único y un certificado híbrido abre la puerta a un ataque de eliminación de firmas, en el que un atacante elimina la firma post-cuántica de los datos firmados y presenta el resto como si hubiera sido firmado únicamente con el algoritmo clásico.

Secuenciación de migración: ¿Por qué el intercambio de claves es lo primero?

El RFC 9958 establece una clara distinción operativa entre las dos vías de migración, y es la guía de secuenciación más práctica del documento.

El intercambio de claves híbrido o PQ es relativamente autónomo , ya que normalmente solo requiere modificaciones en la biblioteca criptográfica, como OpenSSL, sin afectar la infraestructura general de certificados y confianza. Esto lo convierte en el punto de partida ideal: permite a los equipos adquirir experiencia operativa con PQC en producción con un impacto relativamente bajo.

La migración a firmas digitales post-cuánticas o híbridas implica cambios mucho más amplios en el ecosistema : los certificados, las autoridades de certificación, los protocolos de gestión de certificados, los módulos de seguridad de hardware (HSM) y los anclajes de confianza deben evolucionar conjuntamente. Iniciar la creación de prototipos y la planificación de la migración de firmas con antelación, incluso mientras la migración del intercambio de claves aún está en curso, permite a los equipos detectar estos impactos en todo el ecosistema antes de que se conviertan en obstáculos para la producción.

Lo que realmente recomendamos

Inicie ahora los proyectos piloto de intercambio de claves híbridas, ya que el cambio a nivel de biblioteca está contenido y el aprendizaje operativo es valioso independientemente del protocolo que se modifique primero. Paralelamente, comience la planificación, mucho más lenta, del lado de la firma: realice un inventario de cada autoridad de certificación, HSM y ancla de confianza que eventualmente afectará una migración de firma, ya que este trabajo de inventario lleva más tiempo que el proyecto piloto y debe ejecutarse simultáneamente, no secuencialmente, para evitar que los cambios en todo el ecosistema, como advierte el RFC 9958, se conviertan en una sorpresa de última hora. Realice pruebas en condiciones de red reales, no solo en un entorno de laboratorio, ya que los efectos de fragmentación y pérdida de paquetes que documenta el RFC 9958 solo se manifiestan con latencia y pérdida realistas.

Cómo puede ayudar la consultoría de cifrado

La secuencia propia de RFC 9958, que prioriza el intercambio de claves híbridas y la planificación del ecosistema del lado de la firma en paralelo, se corresponde con dos productos diferentes. HSM-as-a-Service es donde se ejecuta el programa piloto de intercambio de claves de bajo impacto que recomienda esta guía, con gestión de claves ML-KEM validada por FIPS sin un ciclo de adquisición de hardware. CertSecure Manager se encarga de la migración más amplia del lado de la firma, orquestando el despliegue de certificados híbridos y PQC puros en toda la jerarquía de CA desde un único plano de políticas, precisamente la coordinación de todo el ecosistema que RFC 9958 señala como la parte más difícil de la transición.

Nuestros servicios de asesoramiento sobre control de calidad de procesamiento (PQC) aplican el inventario y la secuenciación que se describen en esta guía a ambas vías a la vez, de modo que los efectos de fragmentación, pérdida de paquetes y sobrecarga de la cadena mencionados anteriormente se planifican en lugar de descubrirse a mitad del despliegue.

Diseñar la migración, no solo el algoritmo.

La verdadera contribución del RFC 9958 radica en su negativa a tratar la migración de PQC como un simple cambio de algoritmo. Las claves y firmas, entre 6 y 700 veces más grandes que las que se diseñaron para los protocolos, generan problemas de fragmentación, latencia y sobrecarga de la cadena que solo se manifiestan en condiciones de red reales. El modelo híbrido PQ/T existe precisamente para ganar tiempo mientras se buscan soluciones para estos problemas, en lugar de descubrirlos en producción. La secuencia que recomienda el propio RFC 9958 es la migración del intercambio de claves en primer lugar, seguida de la planificación del ecosistema de firmas en paralelo, una estrategia que se mantiene como guía práctica para el plan de migración de prácticamente cualquier organización.

Preguntas frecuentes

¿Es RFC 9958 un estándar que los sistemas deben implementar?

No. Se trata de una RFC informativa, no de una especificación estandarizada. No define un protocolo ni impone un comportamiento; explica los desafíos técnicos de la migración a PQC y remite a las RFC estandarizadas, como la RFC 9370 y la RFC 9180, que sí definen un comportamiento de protocolo específico.

¿Por qué las claves y firmas de PQC son mucho más grandes que las clásicas?

Se basan en supuestos matemáticos diferentes, problemas de retículos o seguridad mediante funciones hash, en lugar de factorización de enteros o logaritmos discretos de curvas elípticas, y estos problemas requieren estructuras más grandes para alcanzar niveles de seguridad equivalentes. Se trata de una compensación inherente a las matemáticas subyacentes, no de una ineficiencia en la implementación.

¿Por qué el RFC 9958 recomienda comenzar con el intercambio de claves en lugar de las firmas?

La migración del intercambio de claves se limita principalmente a un cambio en la biblioteca criptográfica, mientras que la migración de firmas afecta a certificados, autoridades de certificación, HSM y anclas de confianza en todo el ecosistema. Comenzar con el cambio más específico permite a los equipos adquirir experiencia operativa antes de abordar la migración de firmas, que es más compleja.

¿Puede una clave híbrida reutilizar una clave clásica existente?

No. El RFC 9958 establece explícitamente que las claves híbridas deben generarse de nuevo. Reutilizar una clave clásica que también aparece en un certificado independiente de un solo algoritmo crea un riesgo de ataque de eliminación, en el que un atacante elimina el componente post-cuántico y presenta los datos como validados únicamente por el algoritmo clásico.

¿Cuál es el impacto práctico de las claves más grandes en las conexiones VPN IKEv2?

El intercambio IKE_SA_INIT original no podía fragmentar mensajes de intercambio de claves grandes, por lo que el material de clave PQC no se ajustaba al diseño original del protocolo. Los RFC 9242 y 9370 solucionan esto trasladando el intercambio de claves PQC a un intercambio posterior y fragmentable, pero esto requirió una corrección a nivel de protocolo, no solo un búfer más grande.