Resumen

  • RFC 9858 registra nuevas combinaciones SHA-256 y SHAKE256 para HSS/LMS, de modo que el verificador sepa qué cálculo ejecutar.
  • Un resultado válido no certifica que el índice de hoja haya avanzado una sola vez en todos los módulos, restauraciones y rutas de error.
  • La seguridad depende de persistir el nuevo estado antes de liberar la firma, impedir copias activas y preparar el relevo antes de agotar el árbol.

VALID no es un acta de custodia

El RFC 9858 fue publicado por el Crypto Forum Research Group de la IRTF en octubre de 2025. Añade conjuntos con SHA-256 y salida de 192 bits, además de SHAKE256 con salidas de 192 y 256 bits. Sus identificadores LM-OTS y LMS permiten que una implementación declare de forma inequívoca la función, la longitud y los demás parámetros que otra debe aplicar.

Ese acuerdo resuelve una cuestión de sintaxis criptográfica. No prueba cómo se administró la clave.

LMS consume una hoja de un árbol de Merkle en cada firma. El número q identifica esa hoja y la clave privada posee, por tanto, un estado que avanza y una capacidad finita. RFC 8554 señala que reutilizar el estado de una clave privada puede destruir las garantías de seguridad. Sin embargo, el verificador solo recibe una evidencia autocontenida: mensaje, firma, clave pública y ruta para reconstruir la raíz. Puede comprobar que ese conjunto encaja. No puede observar si otra instancia firmó con el mismo q antes, ni si una copia de respaldo volverá a hacerlo después.

La arquitectura necesita dos expedientes. El de parámetros documenta familia hash, longitud de salida, altura del árbol y configuración de Winternitz. El de estado documenta propiedad, reserva, persistencia, emisión y recuperación. RFC 9858 aumenta las opciones del primero; no entrega las pruebas del segundo.

La elección entre 192 y 256 bits tampoco es decorativa. Las variantes de 192 bits reducen tamaños a cambio de un margen de seguridad menor. SHAKE256 puede ajustarse mejor a ciertas plataformas, pero usar la misma longitud de salida que SHA-256 no garantiza una mejor custodia. «Admite RFC 9858» es una especificación incompleta si no incluye el conjunto exacto, el periodo de uso y el comportamiento ante cortes y concurrencia.

NIST SP 800-208 describe la operación que falta. En la generación conforme dentro de módulos de hardware, el material privado no debe ser exportable. El índice de hoja ha de incrementarse y almacenarse de forma no volátil antes de exportar la firma o aceptar otra solicitud. La secuencia es esencial: una escritura que permanece en caché puede desaparecer con la alimentación. Si el sistema libera primero y persiste después, un reinicio abre la puerta a repetir una hoja.

Por la misma razón, restaurar no puede significar volver a una imagen antigua de la clave activa. La recuperación segura puede usar árboles independientes dentro de HSS, asignaciones exclusivas o una clave sucesora preparada. Copiar el mismo estado a dos sitios convierte la disponibilidad en concurrencia sobre un secreto de un solo uso.

La altura del árbol fija además el presupuesto. Reintentos, reservas descartadas y fallos consumen capacidad aunque no todos produzcan una firma pública. Hace falta medir el máximo duradero, el máximo reservado, las firmas liberadas y el saldo. La transición de clave pública debe estar ensayada antes del umbral de agotamiento. Una vez que dos firmas conflictivas salen de una hoja, no existe restauración que revierta el hecho.

Fuentes