Eliminar a alguien de un grupo cifrado debería impedir que reciba los secretos necesarios para los futuros mensajes protegidos. Cambiar solo la lista de miembros no lo consigue si los emisores restantes siguen utilizando material de claves que el antiguo miembro ya conoce.
La transición tampoco es instantánea en toda una red poco fiable. Un diseño de grupo seguro debe definir a qué estado de pertenencia corresponde un mensaje y qué hace un emisor antes de haber procesado una eliminación.
Los mensajes pasados y futuros son problemas distintos
Un antiguo miembro puede conservar mensajes, archivos y claves recibidos cuando estaba autorizado. Eliminarlo no puede hacer que olvide el historial ni borrar sus capturas de pantalla.
El objetivo alcanzable es excluirlo del nuevo estado criptográfico una vez que la eliminación surta efecto. Del mismo modo, añadir a alguien plantea otra pregunta: si obtiene acceso al historial anterior. Los productos y protocolos usan términos como secreto hacia adelante en contextos diferentes, por lo que describir claramente la regla de acceso prevista suele ser más útil que una etiqueta ambigua.
Por qué los grupos con claves de emisor necesitan un estado nuevo
En un diseño de claves de emisor, cada participante puede cifrar los mensajes ordinarios del grupo con una cadena compartida con los destinatarios permitidos. Esto puede evitar tener que cifrar todo el contenido por separado para cada destinatario en cada envío.
Tras una eliminación, el antiguo miembro puede conservar la cadena anterior. Por ello, los emisores restantes necesitan un estado de sustitución que no se distribuya al miembro excluido, y los clientes necesitan un contexto de pertenencia acordado para utilizarlo. La rotación debe abarcar los emisores y dispositivos pertinentes; cambiar un único indicador en el servidor no basta.
El protocolo exacto importa. MLS, especificado en RFC 9420, gestiona la eliminación mediante un cambio de época confirmado que aporta nueva entropía a los miembros restantes. Es un ejemplo de transición de estado definida, no una afirmación de que Livara implemente MLS.
Qué documenta Livara sobre LGS1
La página de seguridad de Livara describe una cadena de emisor firmada por cada emisor, con claves distribuidas mediante sesiones LVR1 por pares. Indica que se crean y distribuyen claves de emisor nuevas cuando cambia la composición del grupo.
Esto respalda una afirmación sobre el diseño publicado de renovación de claves. No establece un tiempo medido de «revocación instantánea» ni demuestra que se gestionen correctamente todas las condiciones de carrera, los escenarios con dispositivos sin conexión y los reintentos. Para eso hacen falta análisis de la implementación y pruebas.
Los controles de pertenencia del servidor y la exclusión criptográfica también cumplen funciones distintas. El servicio puede denegar la entrega o el acceso, mientras que el cifrado debería impedir que una parte excluida con una copia del texto cifrado posterior lo abra sin los nuevos secretos.
Un plan útil para probar la eliminación
En un grupo de prueba autorizado, compruebe estos escenarios con mensajes no sensibles:
| Escenario | Pregunta que debe resolverse |
|---|---|
| Se elimina a un miembro mientras todos están conectados | ¿Cuál es el primer mensaje bajo el nuevo estado de pertenencia? |
| Un emisor restante está sin conexión | ¿Debe actualizar la pertenencia y las claves antes de volver a enviar? |
| El miembro eliminado se reconecta más tarde | ¿Puede obtener nuevas distribuciones de claves de emisor o solo contenido antiguo al que estaba autorizado? |
| Cambian varios miembros a la vez | ¿Convergen todos los dispositivos restantes en el mismo estado? |
| Se reintenta un mensaje antiguo | ¿Se conserva su época original en lugar de etiquetarlo erróneamente como contenido nuevo? |
Una prueba solo de interfaz puede confirmar el comportamiento visible, pero por sí sola no demuestra la exclusión criptográfica. Una evaluación rigurosa debe inspeccionar qué claves y texto cifrado puede obtener un dispositivo de prueba excluido.
Qué deben recordar los administradores
Elimine a los participantes innecesarios, revise los miembros restantes y evite enviar nuevo material sensible hasta que la aplicación haya procesado el cambio. Si un participante actual reenvía contenido deliberadamente, la renovación de claves del grupo no puede impedir esa divulgación.
Para usos de alta sensibilidad, pida al proveedor las reglas exactas de eliminación, el comportamiento de revocación de dispositivos y las pruebas disponibles. La promesa importante es un límite bien definido para los mensajes futuros, no una afirmación sin respaldo de que un botón de eliminación destruye todas las copias anteriores.
