Agilidad: diseñar para poder cambiar el algoritmo

La agilidad criptográfica es una propiedad de la arquitectura: poder sustituir un algoritmo, un tamaño de clave o un protocolo por política y configuración, sin reescribir aplicaciones ni rediseñar sistemas. No consiste en tener activados todos los algoritmos a la vez, ni en perseguir el último que se publique. Consiste en que el día que haya que cambiar, el cambio sea una decisión y no un proyecto por cada sistema.

Se construye con piezas conocidas. Las aplicaciones no nombran algoritmos: piden una operación con un perfil («firma de documentos») a un servicio o una biblioteca central, y la política decide qué algoritmo corresponde a ese perfil. Los protocolos negocian el algoritmo con la contraparte a partir de una lista que se configura. Cada firma o cada dato cifrado se guarda con el identificador del algoritmo que se usó, para que durante la convivencia se sepa con qué verificar o descifrar lo viejo. Y hay pruebas automáticas que demuestran que el cambio de perfil funciona antes de hacerlo en producción.

Lee decision-de-algoritmo.txt en el laboratorio: la columna del último cambio es la medida más honesta de la agilidad que tiene hoy cada sistema.

Un documento de arquitectura describe la intención. El código describe lo que pasa. Cuando un equipo se salta el servicio central «por rendimiento» o «solo por esta vez», el documento sigue diciendo lo mismo y el inventario hereda el error, porque se armó con el documento.

El costo aparece el día de la migración: un algoritmo escrito a mano en varios lugares obliga a buscar cada uno, cambiarlo, probarlo y publicar una versión nueva, mientras que el sistema que pide un perfil cambia con una línea en el servicio central. Por eso el arquitecto pide revisiones de código para confirmar lo que declara el documento, sobre todo en las aplicaciones que firman, porque sus firmas duran años.

Lee la sección 7 de documento-de-arquitectura.txt y compárala con revision-de-codigo.txt.

La migración poscuántica trae un cambio que muchos diseños no previeron: los tamaños. Una firma ECDSA ocupa unas decenas de bytes y una RSA, unos cientos; una firma ML-DSA ocupa varios miles. Las claves públicas y los mensajes del acuerdo de claves también crecen. Si un campo de la base de datos, una cabecera de un mensaje o un formato de archivo se diseñó a la medida de la firma de hoy, el algoritmo nuevo no cabe, y el cambio que parecía de configuración se convierte en una migración de datos.

No todo crece. Un resumen como SHA-256 sigue ocupando lo mismo, porque la amenaza cuántica no obliga a cambiarlo. Distinguir una firma de un resumen evita ampliar campos que no lo necesitan.

Lee campos-y-mensajes.txt con la decisión del comité y compáralo con tamanos-de-referencia.txt.

Con lo visto, el arquitecto propone un diseño que se pueda repetir en cada sistema nuevo: las aplicaciones piden perfiles por nombre y no conocen el algoritmo; la política central decide; cada firma y cada dato cifrado llevan el identificador de su algoritmo; los campos y mensajes tienen sitio para tamaños mayores; y los cambios se ensayan con pruebas antes de activarse.

Hay sistemas donde eso no basta. Una app móvil que lleva fijada la clave pública del servidor solo cambia cuando los usuarios instalan la versión nueva, y eso se mide en meses. El diseño ágil prevé desde ya cómo rotar ese anclaje, por ejemplo llevando una clave de reserva anclada, en lugar de descubrirlo el día del cambio.