Qué son ML-KEM y ML-DSA

Dos nombres que no conviene intercambiar

ML-KEM es un mecanismo de encapsulación de claves. Permite que dos partes establezcan un secreto compartido a través de un canal público bajo los supuestos del esquema. Ese secreto se utiliza dentro de una construcción más amplia; ML-KEM no es por sí solo un cifrador general de documentos.

ML-DSA es un esquema de firma digital. Una parte firma con su clave privada y otras pueden verificar la firma con la clave pública correspondiente. La verificación ayuda a detectar modificaciones y a comprobar el vínculo con esa clave. La confianza en la identidad del firmante requiere mecanismos adicionales.

Ambos fueron estandarizados por NIST el 13 de agosto de 2024 en FIPS 203 y FIPS 204, respectivamente. FIPS 205 especifica SLH-DSA, otra familia de firmas. Esta distinción evita tratar todas las siglas como variantes de una misma función.

Un ejemplo concreto

Imaginá un proveedor que distribuye una actualización de software. La firma del paquete permite verificar que corresponde al firmante esperado y que no fue modificado. Por separado, la descarga puede viajar por una conexión que establece claves de sesión para proteger el tráfico.

Actualizar el intercambio de claves de la conexión no transforma automáticamente la firma del paquete. Y cambiar la firma no garantiza que cada tramo de la descarga utilice una conexión preparada para amenazas futuras. El inventario debería registrar ambas funciones.

Qué pedir en una respuesta técnica

Si un proveedor dice que soporta ML-KEM, pedile que identifique el protocolo, la versión, los parámetros y los extremos cubiertos. Si dice que soporta ML-DSA, preguntá qué objetos firma, cómo distribuye la confianza y qué clientes pueden verificarlos.

No hace falta que una persona no técnica elija parámetros por su cuenta. Sí hace falta que pueda reconocer una respuesta incompleta. Un nombre de algoritmo sin función, alcance ni versión no permite evaluar una implementación.

Hecho: los dos estándares resuelven tareas distintas. Inferencia: las pruebas de aceptación deben cubrir cada tarea de forma separada. Hipótesis: un producto podría agregar soporte en una versión futura; hasta su entrega es una expectativa. Limitación: una explicación conceptual no sustituye los requisitos completos de los FIPS ni la revisión de una implementación.

Qué recordar

• ML-KEM: establecer un secreto.
• ML-DSA: generar y verificar firmas.
• Estándar, biblioteca, protocolo y producto son niveles diferentes.

Qué NO significa esto

No significa que haya que implementar estos algoritmos desde cero o elegirlos solo por su nombre. Usá soluciones mantenidas, documentación vigente y pruebas apropiadas para el sistema concreto.