Cripto-agilidad, o: por qué elegir el algoritmo es la parte fácil.

Hay un momento que tiene todo sistema de producción de larga vida, y la mayoría lo tiene más de una vez. El momento es: tenemos que cambiar la criptografía. A veces porque rompieron una primitiva (MD5, SHA-1, RC4). A veces porque una versión de protocolo se volvió demasiado vieja para defender (TLS 1.0, SSLv3). A veces porque un regulador subió el piso. Y — el que viene ahora — a veces porque el suelo criptográfico bajo toda la industria se está moviendo, igual que lo está moviendo post-cuántico hoy.

Cuando llega ese momento, todo codebase cae limpiamente en uno de dos baldes. Los codebases ágiles cambian la criptografía en un archivo de configuración y deployean. Los codebases rígidos descubren que el nombre del algoritmo quedó hard-codeado en 400 lugares, que los textos cifrados en su base de datos no tienen etiqueta de algoritmo, que la rotación de claves es un rumor, y que la migración ahora es un incidente de seis meses. La diferencia entre los dos baldes no es 'quién eligió el algoritmo correcto hace cinco años.' Es si el equipo practicó cripto-agilidad — y esta entrada es sobre esa práctica.

Qué es realmente la cripto-agilidad

La cripto-agilidad es la propiedad de un sistema que te permite cambiar algoritmos criptográficos — hash, cifrado, firma, intercambio de claves — sin reescribir la aplicación a su alrededor. No es una librería, no es una publicación de NIST, y no es una feature que activás. Es una forma de escribir software, igual que observable o testeable es una forma de escribir software.

La definición más limpia de una línea que vi: el algoritmo tiene que ser dato, no código. Cuando el algoritmo es dato, cambiarlo es un cambio de configuración y una rotación de claves. Cuando es código, cambiarlo es un refactor de cada lugar que lo nombra a mano. Que tu sistema sea uno u otro, en mi experiencia, es el factor más grande para predecir cuánto va a doler cualquier migración cripto futura — incluida la migración post-cuántica.

La clase de historia que nadie tiene permitido saltearse

En los últimos 25 años, la comunidad criptográfica jubiló formalmente o degradó: MD5 (1996 debilitado, 2004 roto), SHA-1 (colisión en 2017), RC4 (prohibido en TLS en 2015), 3DES (deprecado en 2018), TLS 1.0 y 1.1 (deprecados en 2020), y está en medio de mover toda la pila de clave pública a post-cuántico. Seis primitivas ampliamente deployadas se murieron o quedaron en aviso dentro de una sola carrera profesional. La próxima ya está en camino. La siguiente también va a estar en camino.

Cualquier sistema que quiera vivir una década tiene que asumir que sus elecciones criptográficas actuales son temporales. La cripto-agilidad es la respuesta de ingeniería a esa asunción. Elegí los algoritmos más fuertes que puedas hoy; diseñá como si los fueras a reemplazar el año que viene.

Cómo se ve un sistema ágil

Concretamente, dentro de un codebase. Hay exactamente un módulo que conoce los nombres de algoritmos criptográficos — llamémoslo crypto/registry. Todos los demás módulos le piden al registry que hashee, cifre, firme o verifique; nada más en el codebase nombra SHA-256, AES-GCM, Ed25519 o ML-KEM-768. El registry es un mapa de IDs de algoritmo a implementaciones. Agregar un algoritmo nuevo es: agregar una entrada. Sacar un algoritmo es: sacar una entrada. El resto de la aplicación no se mueve.

Cada artefacto que el sistema produce — cada texto cifrado, cada firma, cada clave envuelta — lleva el ID del algoritmo que lo creó. Una firma no es <bytes>; es <algorithm-id, bytes>. Un texto cifrado no es un blob; es un sobre: {alg, kid, iv, ct, tag}. Verificar o descifrar un artefacto arranca leyendo el ID de algoritmo desde el artefacto y preguntándole al registry qué implementación usar. El verificador no sabe qué algoritmo firmó el artefacto cuando empieza la llamada; lo aprende del artefacto mismo.

Los cuatro hábitos que vuelven real la agilidad

Definir la cripto-agilidad es fácil. Practicarla son cuatro hábitos, todos poco glamorosos.

1. Etiquetá cada artefacto con el algoritmo que lo creó. Cada firma, texto cifrado, MAC y clave envuelta lleva su alg (e idealmente un kid — ID de clave — también). Ya existen sobres estándar: JWS / JWE / COSE / JOSE para tokens, y los formatos de sobre IETF HPKE / NIST para uso general. Usá uno; no inventes el tuyo. La razón más común de que una migración duela es que los artefactos legacy no se pueden distinguir de los nuevos al decodificar.
2. Envolvé, nunca inline. Cada operación criptográfica pasa por una interfaz (registry.sign, registry.verify, registry.encrypt). La interfaz acepta el nombre del algoritmo como dato — típicamente desde configuración, metadata de claves, o el artefacto mismo. Si un desarrollador puede grepear tu codebase por 'AES-GCM' y encontrar más de un hit, tu sistema tiene una fuga; esa fuga es donde la próxima migración va a doler.
3. Tratá la rotación como una operación normal, no como una emergencia. Un sistema que nunca rotó una clave en producción es un sistema que va a fallar al rotar una cuando importe. Metelo en el runbook: programala trimestralmente, testeala en staging mensualmente, alertá sobre claves más viejas que un umbral. El día que rompan una primitiva tiene que verse operativamente como un simulacro trimestral, no como un incendio.
4. Híbrido es el default en las transiciones. Cuando cambiás primitivas, corré la vieja y la nueva juntas el tiempo suficiente para poder volver atrás sin pérdida de datos. Para firmas, doble-firmá (vieja + nueva) y aceptá cualquiera; para intercambio de claves, derivá la clave de sesión de las mitades clásica y post-cuántica. Híbrido no es un hack — así pasó toda migración cuidadosa, y así va a pasar toda migración cuidadosa siguiente.

Los anti-patterns que agarran a los equipos más tarde

La imagen espejo de los cuatro hábitos son los cuatro patrones que siempre se ven bien en el momento y siempre se vuelven cuentas a pagar después.

• Nombres de algoritmo hard-codeados a lo largo del codebase. El grep por 'SHA-256' devuelve 70 hits en 30 archivos. Ninguno está mal hoy. Todos son trabajo después.
• Artefactos sin etiqueta en disco. Textos cifrados guardados sin sobre de algoritmo, firmas guardadas como bytes crudos. Migrar esto requiere una danza aparte: re-cifrar o re-firmar cada registro bajo la primitiva nueva, y mientras tanto mantener al verificador viejo vivo durante años.
• Claves que nunca rotaron. Claves de firma de API de seis años, certificados root horneados en binarios, secretos JWT más viejos que el equipo. La primera rotación siempre es la más dura; el equipo que no hizo una todavía no aprendió qué supuestos se rompen.
• Un único booleano de 'algoritmo' en configuración. useEcdsa: true. La próxima migración agrega useMlDsa: true. Dos migraciones después tenés una ensalada de cinco booleanos y nadie puede responder qué camino corre en producción hoy. Usá IDs de algoritmo nombrados (y IDs de claves) — nunca booleanos.

Por qué esto importa más en un sistema multi-agente

Todo lo de arriba es verdad para cualquier sistema de larga vida. Es especialmente verdad para los sistemas multi-agente que construimos en GOGOGO LLC. Un solo producto tiene muchos agentes que se pasan estado firmado entre sí, que persisten traces que deben mantenerse verificables durante años, y que se federan con sistemas externos cuyas elecciones cripto no controlamos. La cantidad de costuras criptográficas se multiplica. Cada costura que hard-codea un algoritmo es un punto futuro de falla.

Concretamente: cuando un agente emite un trace que otro agente (o el auditor de otro cliente) va a verificar un año después, ese trace debe llevar no sólo la firma sino el algoritmo que la produjo. Cuando el bus de mensajes entre agentes autentica paquetes, la cabecera del paquete debe llevar el ID de algoritmo. Cuando el sistema de evaluación de un cliente califica una decisión de agente de hace meses contra un esquema de firma nuevo, la nota vieja debe seguir verificándose bajo el algoritmo con el que se firmó originalmente. Nada de esto es difícil si la agilidad se diseñó desde el principio. Todo es un proyecto si no.

“Elegí el algoritmo correcto hoy y resolviste un problema de un martes a la tarde. Construí un sistema que puede cambiar su algoritmo el año que viene y resolviste cada martes a la tarde que todavía no conocés. La cripto-agilidad es la segunda habilidad, y se paga a lo largo de toda la vida del producto.”

Dónde encaja esto en el cuadro post-cuántico

La razón por la que la cripto-agilidad está en el centro de cualquier plan honesto de migración post-cuántica es la misma razón por la que estuvo en el centro de cada migración previa. Los equipos que salen sin ruido de una transición de primitiva son los equipos cuyo código no notó el cambio. Ese resultado no es suerte. Es la consecuencia de años de decisiones pequeñas, poco glamorosas: etiquetá cada artefacto, ruteá cada operación por una sola interfaz, rotá como simulacro, corré híbrido a lo largo de cada transición. Empezá esos hábitos ahora y la migración post-cuántica es un rollout de configuración. Empezá después de la fecha límite y es un incidente con stakeholders.

El próximo post de esta serie corta es sobre qué significa todo esto — criptografía post-cuántica y cripto-agilidad — específicamente para sistemas hechos de muchos agentes que comparten, firman y verifican estado. Si querés una ventaja, corré un grep por los nombres de algoritmos en tu codebase hoy y contá los hits. Ese número es tu puntaje actual de cripto-agilidad. Más sobre cómo construimos en gogogollc.com.