Las preclaves resuelven un problema de sincronización al establecer una sesión. No sustituyen una vía de comunicación ni una gestión de claves bien documentada.
Un destinatario sin conexión puede recibir un mensaje cifrado más tarde porque su dispositivo publicó material de clave pública con antelación. El remitente sigue necesitando un servicio de entrega accesible; «cifrado asíncrono» no significa que los mensajes atraviesen una caída de red o aparezcan al instante en un teléfono desconectado.
Los diseños poscuánticos amplían esta idea con un mecanismo de encapsulación de claves. Las preguntas importantes son cómo se establece el secreto inicial, cómo se retiran las claves privadas antiguas y cómo los mensajes posteriores renuevan la seguridad.
Las preclaves resuelven un problema de sincronización
Imagine que Maya está desconectada cuando Sam inicia una nueva conversación. El dispositivo de Maya había subido previamente preclaves públicas. Sam puede obtener ese material, realizar su parte del acuerdo de claves y enviar un primer mensaje cifrado. Maya lo procesa cuando vuelve a conectarse, utilizando claves privadas conservadas en su dispositivo.
Por tanto, el servidor proporciona información pública y mantiene datos cifrados en cola; no necesita poseer el secreto resultante para los mensajes. La especificación X3DH de Signal es una descripción primaria de este diseño asíncrono. Una preclave firmada y una preclave de un solo uso tienen duraciones y funciones distintas; «preclave» no significa que se suba una contraseña secreta al servidor.
En una conversación ya establecida, la aplicación puede utilizar el estado de sesión existente en vez de repetir la configuración inicial para cada mensaje. Iniciar una sesión y hacer avanzar sus claves de mensaje son operaciones separadas.
Qué aporta un KEM poscuántico
Un mecanismo de encapsulación de claves tiene tres operaciones básicas: generar claves, encapsular con una clave pública y desencapsular con la clave privada correspondiente. La encapsulación produce tanto un secreto compartido como un texto cifrado. El texto cifrado puede entregarse más tarde; el secreto en sí no se envía en claro.
NIST FIPS 203 estandariza ML-KEM. En ML-KEM-768, la clave pública de encapsulación ocupa 1.184 bytes, el texto cifrado 1.088 bytes y el secreto compartido 32 bytes. Son tamaños a nivel de algoritmo, no el tamaño de un paquete completo de mensajería. Las firmas, las claves clásicas, los identificadores y el entramado del transporte añaden sobrecarga; una clave pública almacenada en caché puede no acompañar a cada mensaje.
En una construcción híbrida, un protocolo combina material secreto clásico y poscuántico según un esquema definido de derivación de claves. Unir nombres de algoritmos no demuestra que la composición sea segura. La vinculación de identidades, la validación, la separación de dominios y el manejo de fallos deben especificarse y revisarse.
Un ejemplo: PQXDH, no un modelo universal
La especificación PQXDH de Signal describe preclaves poscuánticas firmadas de un solo uso y una clave firmada de último recurso. El remitente verifica las firmas proporcionadas, realiza el acuerdo de claves e incluye el texto cifrado del KEM y los identificadores de claves en el mensaje cifrado inicial. Más tarde, el destinatario deriva el mismo secreto y procesa el mensaje.
La clave de último recurso permite establecer la sesión cuando no hay claves KEM de un solo uso disponibles, pero el análisis frente a una posible vulneración no es idéntico. La eliminación y la rotación de claves privadas afectan a la protección de sesiones anteriores. La especificación también distingue el secreto hacia adelante poscuántico de la autenticación frente a un atacante cuántico activo. Estos detalles no deben sustituirse por «la alternativa no tiene coste de seguridad».
PQXDH es una construcción especificada concreta. Sus curvas, firmas y parámetros exactos no deben copiarse en la descripción de otro producto salvo que dicho producto los documente.
Un mecanismo ratchet no es lo mismo que una reserva de preclaves
Las preclaves permiten establecer sesiones. Un protocolo ratchet modifica los secretos durante la conversación. La especificación Double Ratchet explica la evolución de las claves de mensaje y construcciones ratchet poscuánticas más recientes, incluidos diseños que no transmiten un intercambio poscuántico completo con cada mensaje de aplicación.
El secreto hacia adelante se refiere a los mensajes anteriores cuando una clave se ve comprometida después. La seguridad poscompromiso se refiere a recuperar la seguridad de las comunicaciones futuras cuando el atacante pierde el acceso y se incorpora material secreto nuevo. Ninguna de las dos significa que el malware pueda permanecer indefinidamente en un teléfono mientras la criptografía le oculta de algún modo el texto en claro de ese teléfono.
Eliminar una preclave pública del servidor evita su reutilización ordinaria; no equivale a eliminar la clave privada correspondiente de un extremo. Una auditoría útil comprueba tanto las reglas del ciclo de vida como el comportamiento ante mensajes retrasados.
Qué documenta Livara y qué sigue necesitando pruebas
La página de seguridad de Livara describe un establecimiento híbrido de sesiones con claves de un solo uso cuando están disponibles, avances ordinarios de la cadena de mensajes y épocas periódicas de ML-KEM. Esto difiere de la antigua afirmación de que cada mensaje realiza un intercambio ML-KEM nuevo y completo. Son declaraciones de la documentación del producto, no una verificación independiente de la implementación.
No deduzca de estas declaraciones una política concreta de alternativa ante claves agotadas, un intervalo de reposición ni una cifra de latencia de red. Esas preguntas requieren documentación del protocolo específica de la versión o resultados medidos. El Proof Lab tampoco es una prueba completa del establecimiento asíncrono, el agotamiento de claves o la recuperación de mensajes retrasados.
Cómo evaluar las afirmaciones sobre mensajería sin conexión
Pida al proveedor o al evaluador pruebas que cubran estos casos:
| Caso de prueba | Qué observar |
|---|---|
| Primer mensaje a un contacto desconectado | Qué material de clave pública se utilizó y cuándo recibe realmente el mensaje el destinatario |
| Preclaves de un solo uso agotadas | Si la configuración se detiene o sigue una alternativa documentada, y qué contrapartida de seguridad se declara |
| El destinatario reinstala o cambia de identidad | Si los mensajes antiguos en cola siguen siendo descifrables y si los cambios de claves son visibles |
| Mensajes retrasados o reordenados | Límites de retención, tratamiento de claves omitidas y errores comprensibles |
| Regreso tras una ausencia prolongada | Renovación segura de claves, procesamiento acotado y estado de entrega preciso |
| Comparación de rendimiento | Dispositivo, versión de la aplicación, red, tamaño de la carga útil y mediciones separadas del establecimiento inicial y de las sesiones ya establecidas |
Utilice cuentas y mensajes de prueba sin información sensible. Una prueba de entrega satisfactoria demuestra ese escenario, no todas las propiedades criptográficas. A la inversa, una entrega fallida puede deberse a la red o al ciclo de vida y no a una ruptura del cifrado.
Preguntas frecuentes
¿Puede el destinatario estar desconectado mientras envío?
Sí, si la aplicación dispone del material público necesario y de infraestructura de entrega y almacenamiento. El destinatario no puede leer el mensaje en cola hasta que su dispositivo pueda recuperarlo y procesarlo.
¿Las claves KEM más grandes siempre ralentizan notablemente los chats?
Del tamaño de una clave por sí solo no se deduce una afirmación universal sobre tiempos. Importan la frecuencia de establecimiento, la agrupación, la caché, la implementación y las condiciones de red. Publique una medición de rendimiento en vez de prometer una sobrecarga nula.
¿Una preclave firmada demuestra quién es la persona detrás de la cuenta?
Autentica material con respecto a una identidad de firma. Cómo se vincula esa identidad con la persona a la que desea contactar es una cuestión independiente de confianza y verificación.
¿Funciona el cifrado poscuántico sin ninguna conexión?
Algunos cálculos locales pueden ejecutarse sin conexión. La entrega de mensajes sigue requiriendo una vía de comunicación; la criptografía no la proporciona.
