La integridad del paquete, la frescura del mensaje y el historial de ediciones son tres propiedades distintas; una no demuestra la existencia de otra.
Un mensajero puede permitir editar o eliminar mensajes; pero, en un sistema con cifrado autenticado, el servidor no debería poder modificar silenciosamente el texto cifrado y entregar aun así un mensaje válido. La integridad del mensaje en un mensajero permite al destinatario detectar cambios en los datos posteriores al cifrado; no equivale a conservar un historial completo ni a demostrar jurídicamente una conversación.
Puntos clave
- El cifrado autenticado detecta la manipulación del texto cifrado, pero no conserva necesariamente el historial de ediciones y eliminaciones.
- Según la documentación técnica de Livara, AES-256-GCM protege los mensajes privados con una etiqueta de autenticación; un paquete manipulado no debería descifrarse como válido.
- Una edición autorizada debe ser un nuevo evento cifrado de extremo a extremo, no una reescritura secreta del paquete anterior por el servidor.
- Los números de seguridad ayudan a verificar la clave del interlocutor, no su honestidad ni la validez jurídica de una captura de pantalla.
- En disputas delicadas, conserve también fuera del hilo los archivos originales, las horas, el estado de edición y pruebas independientes.
¿Qué es exactamente la integridad del mensaje?
La integridad permite al destinatario detectar cambios no autorizados en los datos cifrados. La confidencialidad pregunta «¿quién puede leer el texto?»; la integridad pregunta «¿han llegado los mismos datos que cifró el remitente?». La explicación del cifrado de extremo a extremo y sus límites desarrolla esta diferencia.
Es una ilustración conceptual con etiquetas de ejemplo, no la interfaz real de Livara ni el resultado de una prueba de rechazo de mensajes manipulados.
Según la documentación técnica de Livara, los mensajes directos usan LVR1 y los grupos privados compatibles usan LGS1 para el cifrado de extremo a extremo. La página de seguridad de Livara indica que los grupos antiguos incompatibles permanecen explícitamente fuera del E2EE y que un grupo nuevo no se crea con la etiqueta de cifrado hasta que todos sus miembros están preparados. Compruebe el estado de esa conversación concreta. Los documentos indican que LVR1 usa ECDH P-256 y ML-KEM-768 para derivar claves de mensaje. Que un componente esté estandarizado no supone una aprobación independiente de toda la combinación o del producto. Después, Livara utiliza AES-256-GCM para proteger el contenido.
Según la documentación del producto, esta protección incluye textos, ediciones y adjuntos de conversaciones privadas. Los canales de Livara, en cambio, no están cifrados de extremo a extremo: el servidor puede leer deliberadamente su contenido para eliminar, entre otras cosas, contenido abusivo. La pertenencia a grupos también está controlada por el servidor. La seguridad de las llamadas y el modo de grabación deben evaluarse aparte de los mensajes de texto.
Detección de manipulación y cifrado AES-256-GCM en mensajeros
Además de cifrar el contenido, AES-GCM genera una etiqueta de autenticación. Si cambian el texto cifrado o los datos autenticados, la verificación de la etiqueta debe fallar. NIST SP 800-38D define GCM y advierte de que reutilizar un nonce con la misma clave puede debilitar gravemente la seguridad.
Según las especificaciones técnicas de Livara, los mensajes privados usan AES-256-GCM. Si el servidor cambia parte de un paquete protegido, no puede generar una nueva etiqueta sin la clave del mensaje; por tanto, el destinatario no debería aceptar el paquete como íntegro. La respuesta breve a «¿puede el servidor cambiar un mensaje?» es: puede eliminar, retener, bloquear o retrasar datos, pero no debería poder hacer que un contenido manipulado parezca válido.
Esta garantía no es ilimitada. La criptografía no neutraliza el malware del dispositivo, el acceso de un atacante a una pantalla desbloqueada ni una edición autorizada del usuario. La integridad del contenido tampoco oculta necesariamente los metadatos. La guía sobre metadatos de mensajería y lo que revelan explica este límite.
¿Puede el servidor cambiar un mensaje, o editar es otra cosa?
El servidor no debería poder reescribir en secreto el paquete cifrado anterior, pero puede entregar un evento de edición creado por el remitente. La seguridad de la edición de mensajes depende de que la edición también se autentique y se cifre de extremo a extremo, como el mensaje original, en lugar de que el servidor cambie directamente el texto almacenado.
Según Livara, las ediciones están protegidas mediante LVR1 en chats directos y LGS1 en grupos privados compatibles. Para evaluar la interfaz, compruebe si la aplicación muestra «editado»; aun así, la criptografía por sí sola no conserva eternamente la versión anterior en todos los dispositivos.
«Eliminar para todos» es una solicitud de descartar contenido, no una prueba de que se hayan destruido todas las copias. El destinatario puede haber visto el mensaje, leído la notificación, guardado el archivo o hecho una captura. Los mensajes temporales reducen la permanencia, pero no garantizan que se eliminen todas las copias.
¿Qué demuestra la autenticación de un mensaje de chat?
La autenticación del mensaje de chat indica que se creó con las claves de sesión y no fue manipulado durante el tránsito. No demuestra que el titular de la cuenta tuviera personalmente el dispositivo, que el texto sea cierto o que el destinatario pueda demostrarlo después de forma concluyente a un tercero.
Livara presenta los números de seguridad como una forma de detectar cambios de clave. Dos personas pueden comparar las huellas de las claves por una vía independiente; la guía para verificar chats con números de seguridad detalla los pasos. Esto reduce el riesgo de sustituir la clave del contacto por la de un atacante, pero no protege un dispositivo infectado.
La autenticación de la cuenta es otra cuestión. Ningún mecanismo de acceso, por sólido que sea, sustituye a la integridad del mensaje, la verificación de la clave del contacto o la seguridad del dispositivo.
La integridad del contenido no es orden ni frescura del mensaje
Un paquete antiguo puede tener una etiqueta de autenticación válida. Impedir que vuelva a aceptarse requiere diseño de protocolo, contadores, identificadores de sesión y conservación del estado del destinatario; AES-GCM no es por sí solo un registro del orden de toda la conversación. Esta diferencia importa al evaluar repeticiones, mensajes retrasados y sincronización entre dispositivos.
También debe quedar claro qué datos cubre realmente la etiqueta. Si el identificador de conversación o el tipo de evento están fuera del contexto autenticado, proteger solo el cuerpo no resuelve todo el problema. La revisión del código y las pruebas de esa versión concreta deben aclarar esta vinculación.
Si el texto o el estado del mensaje son inesperados
Registre la versión de la aplicación, la hora de observación, los dispositivos implicados y la presencia de una etiqueta de edición. Consulte al contacto por una vía independiente para saber si realizó una edición autorizada. No atribuya una discrepancia de sincronización a manipulación del servidor sin pruebas, pero tampoco descarte sin motivo errores de autenticación o cambios de clave.
Para informes técnicos utilice mensajes de prueba no sensibles y no publique datos privados del contacto. Si la conversación se va a utilizar en un asunto jurídico, la criptografía o una captura por sí solas no determinan la validez legal; consulte a un profesional cualificado antes de modificar pruebas.
¿Cómo evaluar las afirmaciones de integridad de un mensajero?
No se conforme con «cifrado». Pregunte:
- ¿Qué conversaciones y archivos están cifrados de extremo a extremo?
- ¿Qué algoritmo AEAD usa el servicio?
- ¿Cómo se registran y muestran las ediciones y eliminaciones?
- ¿Cómo detecta el usuario los cambios de clave de un contacto?
- ¿Qué metadatos, contenido o pertenencia a grupos controla el servidor?
- ¿Tienen las llamadas las mismas garantías que los mensajes?
- ¿Se ha auditado el protocolo de forma independiente?
Livara publica especificaciones y herramientas para comprobar algunas de sus afirmaciones, y los usuarios de Android pueden comparar la suma de comprobación del APK mediante SHA-256 en Proof Lab para la verificación sin conexión de la aplicación. Sin embargo, este artículo no aporta pruebas de una auditoría independiente de la versión actual. Publicar especificaciones y vectores de prueba facilita el análisis, pero no sustituye una auditoría independiente.
Para las conversaciones privadas, la afirmación principal de Livara es limitada y clara: AES-256-GCM debe detectar la manipulación del paquete y las ediciones también deben cifrarse. No implica un registro inmutable, la eliminación garantizada de todas las copias ni una prueba jurídica automática.
Preguntas frecuentes
¿Puede el administrador del servidor cambiar el texto de un mensaje cifrado?
Con un diseño correcto de AES-256-GCM, el administrador sin la clave del mensaje no puede cambiar el texto cifrado y generar una etiqueta válida. Sí puede eliminar, bloquear o retrasar el paquete. Esta garantía no cubre un dispositivo infectado ni una edición autorizada del remitente.
¿La etiqueta «editado» demuestra cómo era la versión anterior?
No. Solo indica que el contenido mostrado cambió después del envío, salvo que la aplicación también conserve un historial de versiones. El cifrado puede autenticar el evento de edición, pero no conserva automáticamente el texto anterior.
¿Un número de seguridad garantiza la autenticidad de todos los mensajes?
No. Ayuda a verificar que la clave de cifrado pertenece al contacto y a detectar cambios en ella. No indica quién tenía el dispositivo al enviar, si el mensaje es cierto o si el dispositivo carece de malware.
¿Eliminar para todos borra el mensaje de todas partes?
No. Puede descartar la copia dentro de la aplicación, pero no recuperar archivos guardados, notificaciones, capturas ni registros previos. Eliminar para todos reduce la permanencia; no garantiza el borrado del dispositivo del destinatario ni de otros sistemas.
