El plan de transición

El orden de migración no se decide por lo fácil ni por lo que más ruido hace. Se decide por dos preguntas: cuánto tiempo debe seguir reservado el dato y quién puede estar grabándolo hoy. Por eso la prioridad más alta es un acuerdo de claves asimétrico en un canal observable con datos de larga vida; después, las firmas de larga vida, que habrá que poder verificar cuando exista el ordenador capaz de falsificarlas; después, el resto de usos asimétricos. Los simétricos y los hashes quedan al final, sin cambio de algoritmo.

La tabla criterios del laboratorio lo muestra en el orden aprobado por el comité de Quillacinga. Un plan que empieza por el uso más cómodo de migrar, por ejemplo uno interno sin datos de larga vida, gasta meses mientras el riesgo mayor sigue abierto.

Un plan de migración criptográfica toca túneles, certificados y servicios que no se pueden dejar caídos. Cada fase necesita un plan de vuelta atrás probado: cómo volver a la configuración anterior si el piloto falla, si un cliente no negocia o si la latencia sube más de lo aceptable. Una fase sin ese plan convierte un error de configuración en una caída que dura hasta que alguien improvisa la reversa.

El borrador tiene cuatro fases y la columna vuelta_atras_probada dice si cada una la tiene. Lee la tabla fases y escribe el identificador de la fase que no la tiene.

Un plan no puede migrar lo que depende de un tercero sin saber si ese tercero lo soporta y cuándo. Un firewall, un balanceador, un HSM o un servicio de claves gestionado trae su propio calendario; si el proveedor no ha confirmado soporte poscuántico por escrito, el hito que lo necesita no tiene fecha real. La respuesta correcta no es esperar sin hacer nada, sino pedir la confirmación, registrarla en el plan y, si no llega, decidir si se cambia de proveedor o se acepta el riesgo.

La tabla terceros lista los proveedores de Quillacinga, el uso que sostienen y lo que han confirmado. Encuentra al que no ha confirmado nada y escribe su nombre.

La fase de piloto no sirve para demostrar que funciona, sino para encontrar lo que no. Los algoritmos poscuánticos suelen producir claves, firmas y mensajes de negociación más grandes que los clásicos; eso puede romper un balanceador con límites de tamaño, un dispositivo antiguo o un tiempo de espera ajustado. Un buen piloto mide latencia, tamaño de los mensajes y compatibilidad con los clientes reales, en una sede acotada y con la reversa lista. Si todo va bien se amplía; si no, se corrige antes de escalar.

El NIST publicó en noviembre de 2024 un borrador sobre la transición a estos estándares; las fechas de retirada de los algoritmos clásicos que fije su versión vigente se consultan en la fuente oficial y se llevan al plan como hitos, no se asumen de memoria.