El avance de la cadena por mensaje y la renovación de una época poscuántica resuelven partes distintas del problema del ratchet.
Un ratchet híbrido poscuántico actualiza las claves de mensajería utilizando material tanto clásico como poscuántico. Su objetivo es conservar la protección bajo supuestos cuidadosamente definidos si un componente se vuelve vulnerable, limitando al mismo tiempo el daño de determinadas exposiciones de claves a lo largo del tiempo.
Livara documenta este enfoque para LVR1 con P-256 y ML-KEM-768. Comprender el diseño exige separar el establecimiento inicial de claves, las actualizaciones ordinarias de la cadena de mensajes y las renovaciones poscuánticas periódicas. No son la misma operación realizada en cada mensaje.
De un secreto compartido a claves de mensaje cambiantes
Un mecanismo de establecimiento de claves proporciona a los participantes material secreto que pueden utilizar en un esquema de derivación de claves. Después, un protocolo ratchet hace evolucionar el estado y deriva claves de mensaje, en lugar de mantener una misma clave de contenido durante toda la conversación.
NIST FIPS 203 especifica ML-KEM, incluido el conjunto de parámetros ML-KEM-768. Establece un secreto compartido; un cifrado autenticado como AES-GCM cifra la carga útil del mensaje. La autenticación y la forma de combinar los componentes pertenecen al protocolo más amplio.
La descripción general de seguridad de Livara describe un establecimiento híbrido, raíces clásicas y poscuánticas independientes, cadenas unidireccionales de envío y recepción que avanzan con los mensajes y actualizaciones periódicas de época ML-KEM. Indica que una clave de mensaje se combina con la raíz poscuántica actual antes de proteger el contenido y la cabecera.
Esa descripción no debe reinterpretarse como «se realiza un nuevo intercambio P-256 y una nueva encapsulación ML-KEM para cada mensaje». El avance de una cadena puede ser un paso de derivación de claves relativamente económico.
Qué cambia una época
Una época es un periodo del estado del protocolo asociado a una renovación concreta. Distribuir entre épocas los mensajes más grandes de establecimiento de claves puede reducir la sobrecarga reiterada de comunicación, pero también hace que las reglas de renovación sean relevantes para la seguridad.
Quien revise el diseño debería preguntar:
- ¿Qué desencadena una nueva época: un contador, el tiempo, una acción del interlocutor u otra condición?
- ¿Cómo se autentican los identificadores de época y el material de claves?
- ¿Qué ocurre con los mensajes retrasados, duplicados o que llegan fuera de orden?
- ¿Cómo gestiona un cliente una actualización ausente o un interlocutor antiguo incompatible?
- ¿Qué secretos antiguos se conservan para la entrega retrasada y cuándo se descartan?
Una implementación necesita respuestas precisas. La palabra «periódico» por sí sola no constituye una especificación completa de recuperación o interoperabilidad.
Cuantificar tamaños de primitivas sin inventar una prueba de rendimiento
FIPS 203 asigna a ML-KEM-768 un tamaño de clave de encapsulación de 1.184 bytes y un tamaño de texto cifrado de 1.088 bytes. Son codificaciones de primitivas, no el tamaño total de un mensaje o de un intercambio inicial de Livara. Las cabeceras del protocolo, las firmas, el entramado y la frecuencia con que se envía cada valor determinan el tráfico real.
Los tamaños de las claves P-256 también dependen de su representación. Por ejemplo, un punto de curva comprimido y otro sin comprimir tienen distintas longitudes codificadas. Comparar un «tamaño de clave P-256» sin especificar con un texto cifrado ML-KEM no es un análisis completo del ancho de banda.
Para evaluar el coste de un ratchet, mida los bytes por conversación y época, el tiempo de CPU, la memoria, las activaciones de radio y la latencia de extremo a extremo en dispositivos representativos. Indique las condiciones de compilación y de red. Sin esas mediciones, no se justifican ni un «impacto insignificante en la batería» ni un tiempo de ejecución universal inferior a un milisegundo.
Secreto hacia adelante y recuperación tras una intrusión
El secreto hacia adelante busca proteger mensajes anteriores después de que se expongan determinados secretos posteriores, siempre que se hayan borrado los secretos antiguos necesarios. La seguridad posterior a una intrusión se refiere a recuperar la protección cuando un atacante ya no controla el terminal y entra en el protocolo material secreto nuevo desconocido para él.
La especificación Double Ratchet explica estas diferencias y los límites de la recuperación tras una intrusión. El acceso continuado de malware, la aleatoriedad manipulada o un atacante activo que controle los intercambios pertinentes pueden impedir la recuperación esperada. Enviar un mensaje más no demuestra que se haya revocado una sesión robada ni que un teléfono comprometido esté limpio.
Una construcción híbrida también necesita una autenticación y una combinación sólidas. «El atacante debe romper ambos algoritmos» es una propiedad buscada bajo los supuestos de la construcción, no una afirmación incondicional que abarque errores de implementación o terminales maliciosos.
Mantener visibles los límites de las funciones
En la documentación de Livara, las claves de emisor de grupos LGS1 se distribuyen mediante sesiones LVR1 entre pares. Eso no significa que una cadena de emisor de grupo sea estructuralmente idéntica a un Double Ratchet de chat directo. La página de seguridad actual también excluye del cifrado de extremo a extremo a los grupos antiguos incompatibles y exige que los miembros estén preparados antes de crear un nuevo grupo cifrado.
Los archivos adjuntos tienen sus propias claves de contenido, transportadas dentro de la conversación protegida. Las llamadas y la grabación opcional en el servidor requieren una revisión separada; no infiera protección poscuántica de los medios solo porque una ruta de señalización utilice una sesión híbrida. Los canales públicos y los metadatos operativos quedan fuera de la confidencialidad del contenido privado.
¿Qué reforzaría la confianza?
Busque una especificación versionada, pruebas de interoperabilidad y de casos de fallo, revisión independiente y una relación clara entre el código fuente revisado y el cliente distribuido. Los algoritmos estándar aportan pruebas útiles sobre los componentes, pero no certifican su composición.
El Proof Lab de Livara demuestra primitivas clásicas seleccionadas y excluye expresamente la composición completa LVR1/LGS1 de ese banco de pruebas local. Su modelo de amenazas sigue siendo un contexto necesario. Juntos, estos materiales ayudan a formular preguntas; no deben presentarse como sustitutos de una evaluación completa del protocolo y su implementación.
