La agilidad criptográfica es la capacidad de trasladar un protocolo de un conjunto criptográfico a otro sin perder unas garantías de seguridad claras. En mensajería, eso significa algo más que añadir el nombre de un algoritmo nuevo. Los clientes antiguos, los destinatarios sin conexión, los mensajes almacenados y los dispositivos vinculados deben comportarse de forma predecible durante la transición.
El RFC 7696 del IETF describe la agilidad de algoritmos como un problema de migración que implica identificadores, implementaciones y cambios operativos. Un número de versión ayuda a identificar qué se utiliza; por sí solo no hace segura una migración.
Tres versiones que es fácil confundir
Un servicio de mensajería puede tener una versión de la aplicación, una versión del protocolo de comunicación y un identificador del conjunto criptográfico. Responden a preguntas distintas:
| Identificador | Qué le indica a quien lo revisa | Qué no demuestra |
|---|---|---|
| Versión de la aplicación | Qué compilación del software está instalada | Que todas las conversaciones usan el protocolo más reciente |
| Versión del protocolo | Qué formato de mensajes y reglas de estado se aplican | Que la implementación sigue correctamente esas reglas |
| Identificador del algoritmo o conjunto | Qué componentes criptográficos se seleccionan | Que la negociación no puede degradarse a una opción más débil |
Las notas de la versión deben explicar esa relación expresamente. «Ya está disponible el nuevo cifrado» resulta ambiguo si solo lo usan las conversaciones recién creadas o si un cliente vinculado más antiguo provoca un retorno a un modo anterior.
Qué debe especificar una migración segura
Empieza por un escenario concreto: Alice actualiza hoy; Bob sigue sin conexión con un teléfono antiguo. Alice envía un mensaje y después añade un segundo dispositivo. ¿Qué debe aceptar, almacenar y mostrar cada dispositivo?
Un diseño que se pueda revisar responde, como mínimo, a estas preguntas:
- ¿Cómo descubre cada parte las versiones compatibles con la otra?
- ¿Se autentica la versión seleccionada como parte de la sesión?
- ¿Qué ocurre cuando no comparten ninguna versión aceptable?
- ¿Puede un intermediario malicioso eliminar una capacidad e inducir un modo más débil?
- ¿Siguen siendo legibles los mensajes antiguos y qué claves antiguas siguen siendo necesarias?
- ¿Restaurar una copia de seguridad reactiva un estado de protocolo obsoleto?
- ¿Cuándo se desactivarán los algoritmos obsoletos, en lugar de simplemente desaconsejar su uso?
Un fallo visible suele ser más seguro que una transición silenciosa a un modo que el usuario no pretendía utilizar. Pero el comportamiento exacto ante fallos y durante la recuperación debe estar documentado para que las personas no lo eludan pasando a un canal sin protección.
Una matriz práctica de pruebas de actualización
Una actualización de seguridad necesita algo más que un chat que funcione entre dos instalaciones nuevas. Prueba estos casos con datos no sensibles:
| Prueba | Evidencias que registrar |
|---|---|
| Cliente nuevo con cliente antiguo | Protocolo seleccionado o resultado claro de incompatibilidad |
| Destinatario sin conexión durante la actualización | Comportamiento de entrega y descifrado tras volver a conectarse |
| Regresa un dispositivo vinculado antiguo | Si puede leer, enviar o forzar un modo inesperado |
| Un grupo añade a un miembro incompatible | Política explícita del grupo y estado visible para el usuario |
| Se restaura una copia tras retirar algoritmos obsoletos | Si el estado no compatible se rechaza o se migra |
| Metadatos de versión manipulados | Fallo de autenticación en lugar de una degradación inadvertida |
Estos son criterios de evaluación, no afirmaciones de que un producto concreto haya superado las pruebas. Conserva los identificadores de compilación y los resultados observados para distinguir una regresión posterior de un cambio en la documentación.
Cómo interpretar los nombres de protocolo de Livara
Livara denomina LVR1 al protocolo de los chats directos y LGS1 al de los grupos privados en su documentación de seguridad. Estos nombres distinguen responsabilidades; no deben interpretarse como prueba de una estandarización o auditoría independiente. La página también explica el comportamiento de los clientes o grupos que no pueden cumplir los requisitos previos del modo cifrado.
Las siguientes evidencias útiles serían una especificación versionada, vectores de prueba, reglas de compatibilidad y resultados de revisión asociados a una versión concreta. El Proof Lab deja claro el alcance más limitado de su demostración. Ejecutar primitivas en un navegador no equivale a probar todas las rutas de migración de la aplicación.
Qué deben hacer los usuarios durante una actualización del cifrado
Mantén actualizados los clientes compatibles, lee los avisos de seguridad sobre compatibilidad de dispositivos y presta atención a los cambios en los indicadores de identidad o del estado del cifrado. No supongas que un nuevo icono de la aplicación significa que todos los grupos y copias de seguridad antiguos han adquirido una protección nueva. Si el producto no puede explicar qué datos han cambiado de protección, pregunta antes de compartir material sensible.
Una buena agilidad criptográfica permite examinar los cambios. Identifica qué ha cambiado, cómo lo acuerdan las partes, qué puede salir mal y cuándo deja de aceptarse el mecanismo antiguo.
