El cifrado indica qué claves abren un mensaje; debemos comprobar por separado quién ha recibido esas claves.
No; el cifrado de extremo a extremo de un grupo no impide por sí solo que haya un miembro oculto. La respuesta a «¿Puede el servidor añadir un miembro al grupo?» depende de los mecanismos de pertenencia y verificación de miembros, no solo del cifrado de mensajes. Según la documentación de Livara, LGS1 cifra el contenido en grupos privados compatibles que realmente funcionan en modo E2EE. La rotación de claves tras un cambio de miembros está diseñada para limitar el acceso futuro y requiere que los dispositivos apliquen las actualizaciones de miembros y claves; no recupera las copias ya recibidas.
Puntos clave
- El cifrado de extremo a extremo busca la confidencialidad de los mensajes, pero proteger la lista de miembros requiere un mecanismo separado.
- En un grupo privado compatible de Livara cuyo estado E2EE se haya confirmado, LGS1 cubre mensajes, ediciones y claves de adjuntos; no extienda esta afirmación a grupos antiguos incompatibles.
- Comparar Signal, WhatsApp, SimpleX y Element solo por la etiqueta «cifrado» no basta; también hay que valorar los avisos de cambios de miembros, el papel del administrador y la verificación de identidad.
- La interfaz no puede detectar en todas las circunstancias una cuenta autorizada controlada por un atacante; los miembros deben comprobar las identidades y los cambios sensibles por una vía independiente.
- Proof Lab de Livara ofrece una demostración local de P-256, HKDF y AES-GCM y la comprobación de hashes de archivos; no es una implementación completa ni una auditoría independiente de LVR1/LGS1.
¿Impide el cifrado de grupos que haya miembros ocultos?
No, salvo que el protocolo, además del contenido, coordine criptográficamente el estado de pertenencia entre los miembros de forma verificable. Aquí, «miembro oculto» significa una cuenta que accede a mensajes futuros sin que los miembros humanos hayan advertido su entrada o reconocido correctamente su identidad.
El cifrado de extremo a extremo significa que solo los dispositivos de los participantes deberían poder leer el contenido; pero esos dispositivos también deben saber a quién envían las claves. Si el servidor puede modificar la lista de destinatarios, el cifrado puede funcionar correctamente y, aun así, cifrar el mensaje para un miembro no deseado. Para distinguir contenido y metadatos, consulte la guía sobre cifrado de extremo a extremo y sus límites.
Por tanto, un «ataque del servidor a un grupo cifrado» no implica necesariamente romper AES o resolver un problema matemático. El servidor podría, mediante el control de miembros, añadir una cuenta válida a los destinatarios futuros. Los mensajes anteriores cuyas claves no poseía esa cuenta son una cuestión diferente; el principal riesgo es el acceso posterior a su entrada.
¿Qué sabemos de la pertenencia a grupos en Livara?
La documentación de seguridad de Livara separa el control del servidor sobre miembros y roles del cifrado del contenido. Es un límite importante para evaluar, pero por sí solo no demuestra un ataque práctico exitoso ni una entrada completamente invisible. Para afirmarlo habría que probar el comportamiento del cliente, la distribución de claves, los avisos de cambios de miembros y las condiciones del ataque.
La pregunta correcta es: ¿validan los dispositivos de forma independiente los cambios de la lista y qué se muestra al usuario antes de enviar una clave a un nuevo miembro? Este artículo no presenta resultados de una auditoría ni de una prueba de penetración de Livara.
¿Cómo difiere la seguridad de la lista de miembros en cinco mensajeros?
Las diferencias principales son quién autoriza los cambios, cómo se enteran los miembros y si pueden verificar de forma independiente la identidad de una cuenta nueva. La mera existencia de E2EE no responde completamente a la cuestión de la confianza en el servidor.
| Mensajero | Contenido del grupo | Pertenencia y confianza práctica | Conclusión prudente |
|---|---|---|---|
| Livara | En un grupo privado compatible con E2EE, LGS1 cubre texto, ediciones y claves de adjuntos. | Las claves de remitente se regeneran y redistribuyen automáticamente cuando cambian los miembros. | Según la documentación del producto, el contenido de grupos privados compatibles y las claves multimedia se protegen antes de la entrega; compruebe el estado de ese grupo concreto. |
| Signal | La ayuda de Signal sobre grupos dice que el servicio no registra miembros, título, imagen ni atributos del grupo. | La misma fuente indica que el administrador puede decidir quién añade miembros y activar su aprobación para los enlaces de grupo; los miembros deben seguir observando los cambios. | El diseño limita lo que sabe el servicio, pero los usuarios deben comprobar los cambios de miembros y las identidades de las cuentas. |
| El resumen del cifrado de WhatsApp indica que los mensajes personales y grupales se cifran de extremo a extremo. | El recurso de ayuda de WhatsApp explica la opción de compartir parte del historial con un nuevo miembro y la facultad del administrador de limitarlo. | El contenido del grupo está cifrado, pero la corrección de la pertenencia debe evaluarse mediante controles administrativos y avisos de la aplicación. | |
| SimpleX | La documentación de grupos de SimpleX indica que cada miembro tiene conexiones separadas con los demás. | La especificación describe los grupos como conexiones entre miembros, con roles y mensajes de cambios de pertenencia; esto no excluye a un administrador humano. | Que el grupo carezca de identificador global no elimina todos los riesgos de pertenencia ni los de dispositivos comprometidos. |
| Element / Matrix | La especificación E2EE de Matrix define el evento m.room.encryption y los algoritmos de cifrado de salas. |
La especificación de pertenencia de Matrix modela los miembros mediante eventos m.room.member en el estado de la sala, distribuido por los servidores de origen. |
El cifrado de la sala y el estado de pertenencia son capas distintas; los miembros deben comprobar dispositivos y cambios de la sala. |
La tabla no es una clasificación absoluta. Cada sistema tiene un modelo de amenazas distinto, y la aplicación, el dispositivo, la administración y la conducta de los miembros pueden cambiar el resultado. Para elegir en la práctica, utilice las 12 preguntas de la lista de comprobación de mensajería segura junto con la documentación oficial de cada producto.
¿Cómo comparar la confianza en el servidor de un mensajero?
No reduzca la confianza a un sí o un no; pregunte exactamente qué ve y qué puede cambiar el servidor. Un servidor que no lee el texto aún puede controlar los momentos de comunicación, los miembros del grupo o la distribución de claves iniciales.
Primero, separe la confidencialidad del contenido
Compruebe dónde se cifran exactamente los mensajes, ediciones, reacciones, títulos, adjuntos y claves de adjuntos. Según la documentación de Livara, LGS1 cubre texto, ediciones y claves de adjuntos en grupos privados compatibles con E2EE; la afirmación no incluye canales.
Segundo, identifique la autoridad sobre los miembros
Determine quién puede invitar, quién aprueba las solicitudes y cómo muestra el cliente los cambios. Si el servidor impone el estado del grupo, su posible compromiso debe figurar explícitamente en el modelo de amenazas.
Tercero, distinga identidad y pertenencia
Un nombre conocido no demuestra que una clave pertenezca a esa persona. En Livara, el número de seguridad permite comparar huellas de claves fuera de la aplicación; disponer de esta herramienta no significa que se haya comprobado toda la lista de miembros. Atribuya también funciones de transparencia de claves a un producto solo si están documentadas.
Cuarto, separe las pruebas de las afirmaciones
La documentación, los informes de auditoría y las pruebas independientes no son equivalentes. Un informe fiable debe aclarar versión, alcance, hallazgos y correcciones. El nombre de un algoritmo o la coincidencia entre dos implementaciones no demuestra por sí sola que la gestión de miembros sea segura.
¿Cómo verificar a los miembros de un chat grupal?
Los miembros deben revisar inmediatamente los cambios de la lista y verificar por un canal independiente las identidades de contactos sensibles. En conversaciones de alto riesgo no basta con ver un nombre, foto o número de cuenta: pueden ser erróneos, reciclados o estar bajo control de un atacante.
En Livara, dos personas pueden comparar su número de seguridad en persona, en una llamada conocida o por una vía independiente. Esto puede revelar un cambio de clave inesperado; no obstante, una comparación entre dos personas no abarca por sí sola a todos los miembros de un grupo grande a la vez. La guía para verificar chats con el número de seguridad explica los pasos prácticos.
Para grupos sensibles resulta útil este breve procedimiento:
- Limite en lo posible la capacidad de añadir miembros a los administradores.
- Revise en el momento cada aviso de entrada, salida o cambio de rol.
- Verifique la identidad del nuevo miembro fuera de ese mismo grupo.
- Tras un cambio sospechoso, deje de enviar información sensible y cree un grupo nuevo con miembros verificados.
- Revise periódicamente los dispositivos y sesiones vinculados a cada cuenta.
Estas medidas reducen el riesgo, pero no reparan un defecto de la arquitectura de pertenencia. Si se compromete el servidor o la cuenta del administrador y la interfaz muestra mal los cambios, el usuario aún podría no advertir una entrada.
Preguntas frecuentes
¿Puede el servidor añadir un miembro sin romper el cifrado?
Sí, si la arquitectura del mensajero entrega al servidor el control de la lista. No necesita romper el cifrado: puede añadir una cuenta a los destinatarios futuros para que los clientes cifren también para ella. La posibilidad y el método dependen del protocolo de pertenencia de cada producto.
¿Cómo funciona LGS1 en los grupos de Livara?
Según la documentación, en grupos privados compatibles con E2EE, LGS1 utiliza una cadena de claves y firmas del remitente para proteger contenido y claves de adjuntos. Limitar el acceso futuro después de una salida depende de aplicar el cambio de miembros y distribuir claves nuevas. Proof Lab solo ofrece demostraciones locales de algunos componentes criptográficos y comprobaciones de hashes; no es una implementación completa de LGS1, una auditoría del protocolo ni una prueba de gestión segura de miembros.
¿Comparar números de seguridad demuestra que ha entrado un miembro oculto?
No. La comparación comprueba la identidad de las claves entre dos personas por una vía independiente y puede revelar un cambio inesperado. Pero no demuestra que ningún otro miembro haya entrado; también deben comprobarse por separado la lista, los avisos de pertenencia y las identidades de cuentas sensibles.
¿Qué mensajero tiene la lista de miembros más segura?
Estas fuentes no permiten designar un ganador absoluto, pues Signal, WhatsApp, SimpleX, Element y Livara tienen modelos de pertenencia y amenazas diferentes. La elección depende de su riesgo: compruebe quién controla la pertenencia, cómo se anuncian los cambios y si las identidades pueden verificarse fuera del servidor.
