Resumen

  • La revisión 05 dice que sustituyó los códigos experimentales 100–107 por los códigos asignados 37–44. En la captura del 1 de octubre de 2026, el registro OpenPGP de IANA todavía marcaba 37–99 como no asignados. La evidencia prueba una desalineación temporal, no la causa ni el resultado del trámite.
  • Cada propuesta es opcional y está vinculada a claves, certificados y firmas v6 o posteriores. Reconocer un octeto no demuestra soporte, política, ejecución ni interoperabilidad.
  • En las firmas deben aprobar ECDSA y ML-DSA. En el KEM deben ejecutarse ECDH y ML-KEM, validarse los puntos de curva, conservarse el contexto del combinador y verificarse la integridad del desenvoltorio.

El laboratorio solo había probado su propia lectura

Imaginemos una prueba de aceptación. El vector de firma separada se decodifica, el digest coincide y las dos bibliotecas devuelven éxito. El informe dice “algoritmo 41 conforme”. Esa frase omite la versión del objeto, el origen del número, el perfil habilitado y la política que convertirá una validez criptográfica en una acción. Omite también si otro sistema reconoce 41 con la misma definición.

El draft-ietf-openpgp-nist-bp-comp-05 explica en su historial interno que reemplazó 100–107 por 37–44, descritos como asignados. Regeneró huellas, valores intermedios del KEM y vectores, y añadió casos de firma separada. Las ediciones HTML y XML permiten inspeccionar el mismo contenido.

Sin embargo, el registro público de parámetros OpenPGP consultado ese día mostraba algoritmos hasta el 36 y mantenía 37–99 como Unassigned. El dato no autoriza a afirmar que IANA rechazó nada, que el borrador se equivocó o que una actualización estaba a punto de publicarse. Solo autoriza a fechar la discrepancia.

El documento seguía siendo trabajo en curso. La ficha principal lo situaba en el grupo OpenPGP, con revisión del 24 de septiembre de 2026 y vencimiento el 28 de marzo de 2027. La API de Datatracker no declaraba un estado RFC pretendido, aunque el encabezado decía Informational. El historial del proceso pedía una revisión antes del visto bueno de la presidencia. No era un RFC ni un estándar aprobado.

Ocho códigos, cuatro KEM y cuatro firmas

Los códigos 37 y 38 combinan ML-KEM-768 o ML-KEM-1024 con ECDH en NIST P-384 o P-521. Los códigos 39 y 40 hacen el emparejamiento con brainpoolP384r1 y brainpoolP512r1. Los códigos 41–44 sustituyen KEM por firmas: ML-DSA-65 o ML-DSA-87 se unen a ECDSA sobre las mismas familias de curvas.

Todos aparecen como MAY. La opcionalidad cambia la lectura operativa. “El producto usa OpenPGP” no implica “el producto implementa 43”. “La biblioteca contiene ML-DSA” tampoco implica que acepte una firma compuesta, una clave v6 o esa curva. El identificador fija la construcción y sus longitudes; no emite un certificado de capacidad.

El borrador restringe estos algoritmos a claves y certificados de versión 6 o superior. Las firmas también deben ser v6 o posteriores y usar un digest de al menos 256 bits. RFC 9580 define la arquitectura moderna de paquetes, claves y firmas. RFC 9980 incorpora ML-KEM, ML-DSA y el combinador de claves que reutiliza la propuesta. Un recibo de parseo debe incluir versiones, código, tamaños, digest y compilación exacta.

El desenvoltorio correcto llega después de dos caminos

En el KEM compuesto, el emisor realiza ECDH y encapsula con ML-KEM. Los dos secretos resultantes, el ciphertext ECDH, la clave pública ECDH y el identificador entran en multiKeyCombine. El KEK resultante envuelve la clave de sesión con AES-256 key wrap.

El receptor no puede saltar directamente a “clave recuperada”. Primero coteja el algoritmo del PKESK con el de su clave secreta, analiza longitudes exactas, ejecuta ambas decapsulaciones, reproduce el contexto del combinador y comprueba la integridad de 64 bits. En un PKESK v3, además, el algoritmo simétrico se transporta fuera del valor envuelto, por lo que la longitud de la clave recuperada debe corresponderle.

FIPS 203 es la referencia de ML-KEM. SP 800-56A Rev. 3 ofrece el contexto para el establecimiento clásico con curvas elípticas. Un éxito final puede ser auténtico y, aun así, insuficiente como auditoría: no identifica qué validaciones se ejecutaron ni con qué versión. Por eso hacen falta recibos por etapa.

Antes de ECDH hay que decidir si el punto pertenece a la curva

La revisión 04 añadió una obligación que debería ser visible en la telemetría. Los puntos recibidos para las curvas NIST y Brainpool, todas de Weierstrass corta, se consideran entradas controlables por un atacante. Antes de multiplicarlos por un escalar secreto hay que verificar que no son el punto del infinito, que sus coordenadas están en el campo y que satisfacen la ecuación.

En la encapsulación se valida la clave pública ECDH del destinatario. En la decapsulación se valida el punto efímero recibido. Cualquier fallo termina el proceso. El propio texto advierte que operar sobre un punto fuera de la curva puede habilitar un ataque de curva inválida y recuperar el secreto ECDH.

Las bases se distribuyen entre FIPS 186-5, las curvas recomendadas de SP 800-186, las curvas Brainpool de RFC 5639 y la validación de claves públicas de SEC 1 v2. Ninguna longitud de paquete sustituye esas tres pruebas matemáticas.

Dos firmas producen un único sí solamente mediante un AND

El formato de firma contiene una firma ECDSA y otra ML-DSA sobre el digest de los datos OpenPGP. La operación compuesta exige que ambas sean válidas. Un componente omitido, no soportado, mal formado o fallido hace fallar el conjunto.

Las longitudes importan. R y S de ECDSA dependen de la curva; ML-DSA-65 ocupa 3.309 octetos y ML-DSA-87, 4.627. Un digest de menos de 256 bits debe rechazarse. FIPS 204 define ML-DSA, y RFC 9794 organiza la terminología de los esquemas híbridos tradicionales y poscuánticos. La palabra “híbrido” no permite seleccionar el resultado más conveniente.

Los vectores separados añadidos en la revisión 05 prueban que un ejemplo de especificación puede reproducirse. No prueban quién firmó un documento real, si esa persona estaba autorizada, si la clave era confiable o si una aplicación ejecutó la acción prevista. El registro operativo debe guardar el digest, los dos resultados, el AND, la identidad de clave, la decisión de confianza y el desenlace de la aplicación por separado.

La frontera no es la de otro artículo

Esta investigación no vuelve a decidir si un mensaje con varios destinatarios puede llamarse poscuánticamente confidencial cuando conserva una ruta tradicional; esa es otra cuestión de RFC 9980. Aquí la unidad es un solo algoritmo compuesto NIST/Brainpool y la prueba de que sus partes se interpretaron y ejecutaron de forma completa.

Las fuentes no demuestran despliegue, adopción, rendimiento, interoperabilidad, ataque, incidente o comportamiento de un proveedor concreto. Describen un borrador y normas adyacentes. El resultado válido es una matriz de controles, no una afirmación de mercado.