El nombre de un protocolo no prueba su seguridad: importan la arquitectura, la implementación y el comportamiento real ante cambios de miembros y claves.
Messaging Layer Security (MLS) y LGS1 de Livara no son dos certificados intercambiables de seguridad para chats de grupo. MLS es un estándar de protocolo del IETF; LGS1 es el diseño específico de producto documentado por Livara. Compararlos de forma justa requiere separar la arquitectura, las pruebas sobre la implementación y el comportamiento que experimentan los usuarios.
La distinción clave es entre un estado de grupo compartido basado en árboles y claves de remitente distribuidas mediante sesiones entre pares. Ninguna etiqueta, por sí sola, indica si una aplicación concreta gestiona correctamente a un miembro expulsado, un dispositivo desactualizado o una clave comprometida.
La diferencia de arquitectura
RFC 9420 especifica MLS para el establecimiento asíncrono de claves de grupo. Utiliza un árbol ratchet y épocas de grupo, con secreto hacia adelante y seguridad poscompromiso bajo condiciones definidas. Su estructura de árbol reduce ciertos costes de actualización de claves a medida que crece el grupo.
La documentación de seguridad de Livara describe LGS1 como una cadena de remitente firmada para cada miembro, distribuida mediante sesiones LVR1 entre pares y renovada cuando cambia la composición del grupo. Es una afirmación del producto, no una prueba de que LGS1 cumpla MLS o disponga del mismo análisis.
| Pregunta | MLS | Documentación de Livara LGS1 |
|---|---|---|
| Estructura compartida | Árbol ratchet y épocas | Cadenas por remitente |
| Actualizaciones de claves | Los cambios del estado del grupo se consolidan en una nueva época | Se distribuyen claves de remitente nuevas a los miembros |
| Estado de la especificación | Estándar del IETF, RFC9420 | Descripción publicada específica del producto |
| Qué falta evaluar | Integración en la aplicación e implementación | Especificación completa, implementación y pruebas independientes |
Esta tabla describe categorías de diseño. No es una prueba de rendimiento ni una clasificación de seguridad.
Qué significa «logarítmico» y qué no
Una actualización criptográfica puede utilizar un número logarítmico de componentes cifrados de la ruta del árbol sin hacer que todo el trabajo del sistema sea logarítmico. Los mensajes siguen teniendo que distribuirse, los clientes conservan estado y el comportamiento depende de la estructura del grupo y de las operaciones. La antigua comparación «MLS necesita O(log N) mensajes mientras que todo en LGS1 es más rápido» mezclaba costes distintos y no aportaba mediciones.
La arquitectura MLS, RFC 9750, trata el servicio de entrega por separado del establecimiento criptográfico de claves. Analiza la distribución de mensajes y la ordenación de los cambios de grupo. Esa separación importa: el cálculo en el cliente, los bytes de un commit, la distribución total desde el servidor y el tráfico de reconexión son métricas diferentes.
Un informe de rendimiento significativo debe indicar:
- el tamaño del grupo y el número de dispositivos por persona;
- si la operación es un mensaje normal, una expulsión, una actualización de claves o una reconexión;
- los bytes enviados por el cliente iniciador frente al tráfico total de entrega;
- el tiempo transcurrido, el modelo de dispositivo, la versión de la implementación y las condiciones de red;
- el coste de las actualizaciones perdidas y de los cambios repetidos de miembros.
Sin esos detalles, las afirmaciones sobre «milisegundos», «poca sobrecarga de estado» o superioridad para un determinado tamaño de grupo no están demostradas.
Expulsar a un miembro es una prueba del ciclo de vida
Que un administrador elimine una cuenta es solo una parte de la seguridad. Los clientes deben coincidir en el nuevo estado de miembros, usar claves nuevas adecuadas y evitar entregarlas a dispositivos excluidos. Alguien que ya posee texto en claro o claves antiguos puede conservar acceso a contenido anterior; la expulsión no hace desaparecer sus copias.
Para cualquiera de los dos sistemas, una prueba útil pregunta: una vez completada la expulsión, ¿puede el dispositivo eliminado descifrar un mensaje de prueba nuevo sin información sensible? ¿Puede ponerse al día de forma segura un miembro que estaba desconectado? ¿Se gestionan todos los dispositivos de una cuenta? ¿La interfaz muestra los fallos o los cambios de miembros?
Estas son preguntas de evaluación propuestas, no resultados de pruebas realizadas aquí. Una comparación de productos debe publicar el resultado observado y la versión probada, en lugar de equiparar un clic administrativo exitoso con la exclusión criptográfica.
El secreto hacia adelante y la recuperación son condicionales
Mantener protegidos los mensajes antiguos tras una vulneración posterior depende de retirar el material secreto antiguo. Recuperar la protección de los mensajes futuros depende de incorporar secretos nuevos después de que el atacante pierda el acceso pertinente. En MLS, procesar las actualizaciones del grupo forma parte de esa recuperación; enviar una actualización no equivale a que todos los miembros la hayan aplicado. Consulte las consideraciones de seguridad de RFC 9420.
En un diseño de claves de remitente, pregunte cómo se sustituye y redistribuye el estado comprometido de cada remitente. Una cadena unidireccional por sí sola no debe describirse como capaz de recuperarse automáticamente frente a un atacante que conoce su estado actual. La protección entre pares utilizada durante la redistribución es relevante, pero no sustituye un análisis completo a nivel de grupo.
Las afirmaciones poscuánticas necesitan una suite criptográfica y un alcance concretos
Las suites criptográficas definidas en el RFC9420 base utilizan mecanismos clásicos de clave pública. MLS es extensible, por lo que una afirmación sobre una implementación concreta debe identificar su suite real y sus extensiones, en vez de declarar que todos los despliegues de MLS serán clásicos para siempre.
El uso documentado de distribución híbrida LVR1 por parte de LGS1 es una afirmación distinta de una garantía poscuántica analizada independientemente para cada operación de grupo. FIPS 203 estandariza ML-KEM; no certifica el protocolo completo de grupo que lo incorpora. Evalúe en conjunto autenticación, cambios de miembros, compromiso de claves e implementación, no solo el nombre del KEM.
Qué solicitar antes de decidir sobre un producto
Pida la especificación actual del protocolo, vectores de prueba y una revisión independiente específica de la versión, incluidos los hallazgos pendientes. Después compare requisitos ordinarios del producto: dispositivos compatibles, comportamiento de las actualizaciones, recuperación, funciones de moderación y datos conservados en los servidores.
La arquitectura MLS considera explícitamente los servicios de aplicación y sus supuestos de confianza. Del mismo modo, el modelo de amenazas de Livara debe leerse junto con sus afirmaciones de producto. El cifrado no convierte a los participantes autorizados en personas fiables, no impide capturas de pantalla ni elimina todas las formas de metadatos.
Si faltan pruebas, registre «no demostrado» en lugar de etiquetar automáticamente un diseño como inseguro o superior. La decisión debe reflejar los riesgos de su grupo y la calidad de las pruebas disponibles.
Preguntas frecuentes
¿Es LGS1 una implementación de MLS?
Las descripciones publicadas muestran arquitecturas diferentes. Este artículo no identifica LGS1 como una implementación de MLS ni afirma que exista interoperabilidad.
¿Exige MLS que todos los miembros estén conectados a la vez?
No. El uso asíncrono forma parte de su diseño. Las aplicaciones siguen necesitando políticas para actualizaciones retrasadas, estados desactualizados y miembros desconectados durante mucho tiempo.
¿Resuelve la distribución poscuántica de claves la seguridad de los grupos?
No. Aborda una parte del establecimiento de claves. La identidad, los miembros, el ciclo de vida de las claves, la seguridad de los extremos y la implementación siguen requiriendo pruebas.
¿Qué diseño es más rápido?
Este artículo no contiene una prueba de rendimiento que establezca un ganador. Mida las operaciones y el despliegue que importan a su grupo.
