SHARE THE PERSPECTIVE

Una aplicación de mensajería puede mostrar un candado, llamarse privada y dejar sin responder preguntas importantes.

¿Qué conversaciones están cifradas? ¿Se protegen los archivos adjuntos? ¿Dónde se guardan las claves? ¿Qué información conserva el servidor? ¿Qué ocurre si pierdes un dispositivo? ¿Pueden cambiar las claves de cifrado sin aviso?

Estos detalles ayudan a identificar tanto las protecciones útiles como las pruebas que aún faltan. Ninguna lista de comprobación certifica por sí sola que un producto sea seguro.

Esta guía reúne 12 preguntas prácticas que conviene hacer antes de confiar conversaciones personales, archivos confidenciales o trabajo sensible a una aplicación de mensajería cifrada.

¿Qué es una aplicación de mensajería segura?

Una aplicación de mensajería segura es un servicio de comunicación diseñado para proteger las conversaciones frente al acceso no autorizado, la interceptación, la vulneración de cuentas y la exposición involuntaria de datos.

Como mínimo, una aplicación seria de mensajería privada debería utilizar transporte de red seguro, autenticación robusta de cuentas, controles de acceso rigurosos y prácticas claras de tratamiento de datos.

Para conversaciones especialmente privadas, también debería ofrecer cifrado de extremo a extremo.

El cifrado de extremo a extremo, o E2EE, protege el contenido compatible cifrándolo en el dispositivo del emisor y descifrándolo en un dispositivo autorizado del destinatario. El servicio puede entregar los datos cifrados sin necesitar el cuerpo legible del mensaje.

Sin embargo, el cifrado es solo una parte de la seguridad de la mensajería.

Una evaluación completa también debe considerar:

  • Qué conversaciones están cifradas
  • Si las fotos y los archivos reciben la misma protección
  • Dónde se guardan las claves privadas
  • Cómo pueden los contactos verificar las claves
  • Qué metadatos siguen siendo visibles
  • Cómo funcionan la recuperación de cuentas y de claves
  • Qué ocurre si un dispositivo está comprometido
  • Cómo documenta el servicio sus limitaciones

Para profundizar, consulta la guía sobre cifrado de extremo a extremo.

Por qué no basta con la palabra «cifrado»

Casi todos los servicios modernos de mensajería cifran el tráfico de red con HTTPS, TLS u otro transporte protegido.

Esa protección importa, pero no significa necesariamente que la conversación esté cifrada de extremo a extremo.

Con el cifrado de transporte, los datos se protegen mientras viajan entre tu dispositivo y el servicio. Este aún puede recibir el contenido legible antes de entregarlo por otra conexión protegida.

Con E2EE, el contenido compatible de los mensajes se cifra para los participantes antes de llegar al servicio de mensajería.

Esa diferencia determina quién puede acceder técnicamente al cuerpo del mensaje.

Por eso también conviene hacer preguntas precisas en lugar de aceptar una etiqueta genérica de «cifrado».

Afirmación Pregunta que conviene hacer
«Tus chats están cifrados» ¿Solo durante el tránsito o de extremo a extremo?
«Tus datos están seguros» ¿Qué datos, frente a qué amenazas y durante cuánto tiempo?
«No podemos leer tus mensajes» ¿Incluye chats directos, grupos, archivos multimedia, llamadas y copias?
«Privacidad desde el diseño» ¿Qué metadatos e información operativa siguen disponibles?
«Recuperación segura» ¿Quién puede restaurar las claves de cifrado y qué secreto necesita?

1. ¿Qué conversaciones están cifradas de extremo a extremo?

No supongas que una afirmación sobre cifrado se aplica a todas las partes de una aplicación.

Un servicio de mensajería puede ofrecer protecciones diferentes para:

  • Conversaciones directas individuales
  • Grupos privados
  • Grupos públicos
  • Canales de difusión
  • Llamadas de voz y vídeo
  • Historias o publicaciones temporales
  • Bots y cuentas automatizadas
  • Historial de conversaciones sincronizado

Pide al proveedor que defina el límite exacto.

Una respuesta sólida sería:

El cuerpo de los mensajes directos y los archivos multimedia se cifran en los dispositivos participantes. Los grupos privados compatibles están cifrados de extremo a extremo con LGS1, con rotación automática de las claves de emisor cuando cambia la composición del grupo. Los canales utilizan una arquitectura separada legible para el servidor y no se describen como E2EE.

Una respuesta débil sería:

Tu comunicación está protegida con cifrado de grado militar.

La primera respuesta aporta información que puedes evaluar. La segunda utiliza palabras impactantes sin definir el contenido protegido ni el modelo de amenazas.

2. ¿También se cifran las fotos, los vídeos y los archivos adjuntos?

Una aplicación podría cifrar el texto y gestionar los archivos multimedia subidos mediante otro sistema.

Esto plantea una pregunta importante: ¿se cifra una foto en el cliente antes de subirla o solo se protege mediante permisos del servidor y cifrado de transporte?

Pregunta por:

  • Fotos y vídeos
  • Documentos
  • Mensajes de voz
  • Vistas previas de enlaces
  • Miniaturas
  • Archivos temporales de subida
  • Archivos multimedia en caché
  • Autorización de descargas

La protección de archivos multimedia debería describirse por separado, no quedar oculta en una afirmación general sobre «mensajes».

Pregunta por separado por el acceso a los bytes cifrados y por el acceso a la clave de descifrado. Algunos diseños distribuyen adjuntos cifrados desde un almacenamiento menos restringido; eso no equivale automáticamente a exponer texto en claro. La cuestión fundamental es si una parte no autorizada puede obtener contenido multimedia legible o su clave, y qué metadatos revela la vía de almacenamiento.

3. ¿Dónde se generan y almacenan las claves de cifrado?

La fiabilidad del cifrado depende de cómo se gestionen sus claves.

En el E2EE del lado del cliente, el material de claves privadas debería permanecer bajo el control de los dispositivos participantes. Las claves públicas pueden compartirse para que los contactos establezcan comunicaciones cifradas, pero las privadas requieren una protección mayor.

Busca respuestas claras a estas preguntas:

  • ¿Se genera la clave privada en el dispositivo?
  • ¿Se sube alguna vez sin cifrar?
  • ¿Puede el proveedor derivarla o sustituirla?
  • ¿Puede obtenerla automáticamente otro dispositivo con la sesión iniciada?
  • ¿Está protegido el almacenamiento local de claves?
  • ¿Qué ocurre después de restablecer una clave?
  • ¿Reinstalar la aplicación crea una nueva clave de identidad?

La documentación no necesita revelar cada detalle de implementación. Sí debería explicar quién controla las claves privadas y cuál es su ciclo de vida.

4. ¿Pueden los contactos verificar sus claves mutuamente?

El cifrado de extremo a extremo protege una conversación únicamente cuando las claves pertenecen a los participantes previstos.

Muchos sistemas de mensajería segura representan una clave pública mediante una huella, un número de seguridad, un código QR u otro valor de verificación.

Dos contactos pueden comparar ese valor por un canal de confianza, como:

  • Una reunión presencial
  • Una llamada de voz verificada
  • Una cuenta autenticada previamente
  • Un directorio corporativo de confianza

La verificación de claves aporta más confianza en que se utilizan las claves esperadas; no demuestra por sí sola la identidad de una persona. Algunos productos también ofrecen comprobaciones de transparencia de claves, como la verificación automática de Signal. Comprueba las condiciones de cuenta y versión compatibles en lugar de exigir un procedimiento exclusivamente manual para todos los productos.

Pregunta también qué sucede cuando cambia una huella.

Una clave distinta puede tener una explicación inocente, como un restablecimiento, un cambio de dispositivo o una recuperación. Pero el cambio debería ser visible. Una sustitución silenciosa dificulta detectar un cambio inesperado de la clave de identidad.

5. ¿Qué metadatos conserva el servicio?

El contenido y los metadatos de los mensajes son categorías distintas.

Un servicio puede no ser capaz de leer el cuerpo de un mensaje E2EE y seguir procesando información necesaria para dirigir, sincronizar y mostrar la conversación.

Según el sistema, puede incluir:

  • Identificadores de las cuentas del emisor y del destinatario
  • Miembros de la conversación
  • Marcas de tiempo de los mensajes
  • Confirmaciones de entrega y lectura
  • Tamaño del mensaje
  • Eventos de reacciones y ediciones
  • Sesiones de dispositivos
  • Cursores de sincronización
  • Material de claves públicas
  • Tokens de notificaciones
  • Registros de prevención de abusos y seguridad

La existencia de metadatos operativos no convierte automáticamente un servicio en inseguro.

Las preguntas importantes son:

  • ¿Qué se recopila?
  • ¿Por qué se necesita?
  • ¿Cuánto tiempo se conserva?
  • ¿Quién puede acceder?
  • ¿Puede el usuario exportarlo o eliminarlo?
  • ¿Se utiliza para publicidad o perfiles ajenos al servicio?

Desconfía de las afirmaciones de que no se guarda «ningún metadato» si el proveedor no define qué considera un metadato.

6. ¿Cómo se autentica tu cuenta?

Un cifrado robusto de los mensajes no compensa una seguridad débil de la cuenta.

Un atacante que tome el control de una cuenta podría suplantar al usuario, registrar una nueva clave, acceder a contenido legible para el servidor o interferir en la recuperación.

Evalúa si el servicio proporciona protecciones como:

  • Gestión segura de contraseñas
  • Limitación de la frecuencia de intentos
  • Revocación de sesiones
  • Gestión clara de dispositivos o sesiones
  • Protección frente a la reutilización fraudulenta de credenciales capturadas
  • Procedimientos seguros de restablecimiento de contraseñas
  • Autenticación multifactor cuando corresponda
  • Notificaciones de cambios importantes en la cuenta

Distingue también la autenticación de cuentas del cifrado de mensajes.

Iniciar sesión demuestra que alguien tiene la credencial de la cuenta. No demuestra necesariamente que el dispositivo posea la clave privada de cifrado original.

7. ¿Cómo funciona la recuperación cifrada?

La recuperación plantea uno de los equilibrios más difíciles de la mensajería privada.

Es comprensible que los usuarios quieran acceder al historial al sustituir un dispositivo. Pero, si un proveedor puede restaurar silenciosamente todas las claves privadas, podría disponer de más capacidad de descifrado de la que esperan los usuarios.

Un diseño de recuperación protegido puede cifrar una copia de seguridad en el cliente y exigir un secreto de recuperación, una clave de acceso o la aprobación de un dispositivo de confianza. Primero identifica qué contiene la copia: la identidad de la cuenta, los contactos y el historial de mensajes son cosas distintas.

Pregunta:

  • ¿Se cifra la copia antes de subirla?
  • ¿Basta con la contraseña de la cuenta para restaurarla?
  • ¿Conoce el proveedor el secreto de recuperación?
  • ¿Puede el personal de soporte restablecer ese secreto?
  • ¿Qué ocurre si se pierde?
  • ¿La restauración conserva la misma huella de clave pública?
  • ¿Puede desactivarse la recuperación?

Una respuesta fiable puede incluir una limitación incómoda: perder tanto la clave privada como el secreto de recuperación puede hacer irrecuperable el contenido cifrado antiguo.

Esa consecuencia puede ser evidencia de un límite real de seguridad, no de un defecto del producto.

8. ¿Qué sucede cuando se interrumpe la conexión?

La seguridad y la fiabilidad deben funcionar juntas.

Las conexiones móviles desaparecen. Los navegadores se suspenden. Los dispositivos cambian de red. Una aplicación bien diseñada debería gestionar las desconexiones temporales sin duplicar mensajes, perder el orden ni debilitar el cifrado.

Busca un modelo de funcionamiento sin conexión y sincronización capaz de:

  1. Preparar localmente una acción de salida.
  2. Asignarle un identificador estable.
  3. Reintentar de forma segura al recuperar la conexión.
  4. Evitar envíos duplicados.
  5. Conciliar la confirmación del servidor con el estado local.
  6. Recuperar los cambios no recibidos durante la desconexión.

Pregunta por separado cómo protege la aplicación los datos que enviará por la red y su bandeja de salida local mientras espera el mensaje. El E2EE no demuestra automáticamente que la cola local esté cifrada en reposo.

Un reintento de red no debería exigir entregar al servicio una copia en claro de un mensaje que, por lo demás, está cifrado de extremo a extremo.

9. ¿Cómo se autoriza el acceso a archivos subidos y objetos almacenados?

La seguridad de los archivos multimedia abarca más que el cifrado.

Un servicio puede gestionar avatares, adjuntos, fondos de pantalla, historias, subidas temporales y miniaturas generadas. Cada objeto necesita una política de acceso.

Comprueba si la aplicación:

  • Exige autenticación para recuperar archivos multimedia privados
  • Verifica que la cuenta solicitante pertenezca a la conversación correspondiente
  • Separa los recursos públicos de los objetos de mensajes privados
  • Elimina las subidas que no se hayan adjuntado
  • Retira los objetos temporales caducados
  • Evita que la caché mezcle contenido entre cuentas
  • Utiliza identificadores impredecibles sin considerar que esa imprevisibilidad sustituya la autorización

Un archivo privado en claro no debe volverse legible simplemente porque alguien adivine su URL. Para los objetos cifrados, examina cómo se distribuyen y revocan las claves y las capacidades de acceso. Las orientaciones de autorización de OWASP recomiendan aplicar las decisiones de acceso de forma coherente, también a los recursos estáticos; un identificador impredecible no constituye por sí solo una política de autorización completa.

10. ¿Se protegen los chats de grupo de otra manera?

El cifrado de grupos y los controles de miembros plantean preguntas distintas a las del cifrado de chats directos.

Los cambios de miembros, los dispositivos múltiples, el historial, los roles de administrador, las invitaciones, las expulsiones y la rotación de claves añaden requisitos de diseño.

Algunos servicios ofrecen E2EE para chats directos y de grupo. Otros lo ofrecen solo para conversaciones directas y protegen los grupos mediante TLS, almacenamiento autenticado y controles de acceso del lado del servidor.

El segundo modelo puede seguir proporcionando una seguridad útil, pero tiene un límite de confianza diferente.

Pregunta si el servidor puede procesar el contenido del grupo y si cambia la protección cuando:

  • Se incorpora un miembro
  • Se marcha un miembro
  • Un administrador expulsa a alguien
  • Se edita un mensaje
  • Se sincroniza el historial con un dispositivo nuevo
  • Entra un bot o una integración en el grupo

Nunca supongas que un candado mostrado en un tipo de conversación se aplica automáticamente a todos los demás.

11. ¿Qué controles de privacidad tiene el usuario?

La privacidad también consiste en mantener el control después de que la información llegue al servicio.

Busca controles prácticos de cuenta y conversación, como:

  • Exportar los datos de la cuenta
  • Eliminar una cuenta
  • Revocar sesiones
  • Borrar el historial local o sincronizado
  • Eliminar mensajes enviados cuando se permita
  • Gestionar las confirmaciones de lectura
  • Controlar la visibilidad del perfil
  • Bloquear contactos no deseados
  • Gestionar las vistas previas de notificaciones
  • Desactivar o eliminar copias de claves

El proveedor debería explicar si la eliminación retira solo tu copia, la de todos los participantes o el propio registro del servidor.

Un destinatario puede haber descargado, copiado, reenviado o fotografiado ya un mensaje. Ninguna función de eliminación puede garantizar su borrado de todos los dispositivos.

12. ¿Son concretas y verificables las afirmaciones de seguridad?

La documentación de seguridad más sólida define sus límites.

Busca afirmaciones concretas sobre:

  • Algoritmos y tamaños de claves
  • Operaciones del lado del cliente frente a operaciones del servidor
  • Tipos de conversación cubiertos por E2EE
  • Cifrado de archivos multimedia
  • Información almacenada
  • Autenticación
  • Recuperación
  • Cambios de claves
  • Controles de acceso
  • Limitaciones conocidas
  • Fecha de la última actualización de la documentación

Trata con cautela las expresiones vagas:

  • Cifrado indescifrable
  • Privacidad absoluta
  • Seguridad de grado militar
  • Anonimato completo
  • Cero metadatos
  • Imposible de vulnerar
  • Cifrado a prueba del futuro

Ningún sistema de comunicación complejo debería evaluarse únicamente mediante un eslogan.

Las auditorías independientes, la documentación técnica pública, los clientes reproducibles, las revisiones profesionales y los informes de seguridad con alcance bien definido pueden aportar garantías adicionales. No todos ofrecen el mismo nivel de evidencia, pero son más útiles que los superlativos sin respaldo.

Mensajería segura: señales sólidas y señales de alerta

Señal sólida Señal de alerta
El proveedor especifica qué conversaciones son E2EE Todas las funciones se describen simplemente como «cifradas»
Se explica quién controla las claves privadas Nunca se aborda la gestión de claves
Los cambios de clave son visibles Las claves pueden cambiar sin aviso
Se documentan las limitaciones de recuperación El soporte puede restaurarlo todo sin explicar cómo
Se enumeran las categorías de metadatos Se afirma «cero metadatos» sin definirlos
La protección multimedia se describe por separado Solo se mencionan los mensajes de texto
Los grupos tienen un límite de confianza definido Se insinúa que lo afirmado para chats directos cubre los grupos
Las páginas de seguridad incluyen detalles actuales de implementación El lenguaje comercial contradice la documentación técnica
Las limitaciones se explican claramente El servicio promete protección absoluta o invulnerable

Cómo aplicar la lista a las afirmaciones públicas de Livara

La página de seguridad de Livara ofrece documentación del producto, no una certificación independiente. Sus límites actuales distinguen:

  • Mensajes directos: LVR1 utiliza acuerdo de claves híbrido P-256 y ML-KEM-768 y cifrado autenticado para el contenido compatible.
  • Grupos privados compatibles: protección con claves de emisor LGS1; los miembros y los roles siguen sujetos a un límite separado de autoridad del servidor. Los grupos antiguos incompatibles no deberían recibir por extensión la etiqueta E2EE.
  • Canales públicos: contenido legible para el servidor, sin E2EE.
  • Recuperación: el material de identidad se cifra antes de subirlo; restaurarlo no equivale a restaurar el historial de chats.
  • Metadatos y dispositivos: los registros de encaminamiento y los dispositivos comprometidos quedan fuera de la promesa del cifrado del contenido.

Trata estas afirmaciones como algo que debes contrastar con tu versión instalada y con el modelo de amenazas. Una especificación de protocolo, un vector de prueba local, una auditoría de una versión concreta y la observación del servicio en funcionamiento son formas distintas de evidencia. No sustituyas la falta de pruebas por la suposición de seguridad perfecta ni de una vulnerabilidad demostrada.

Lista de comprobación de mensajería segura en 60 segundos

Antes de crear una cuenta, comprueba si puedes responder a cada pregunta:

  • ¿Qué tipos de conversación están cifrados de extremo a extremo?
  • ¿Están cubiertos las imágenes, los vídeos, los documentos y los mensajes de voz?
  • ¿Se generan y conservan las claves privadas en los dispositivos participantes?
  • ¿Pueden los contactos comparar huellas de claves o números de seguridad?
  • ¿Son visibles los cambios de clave?
  • ¿Identifica la política de privacidad los metadatos almacenados?
  • ¿Se explica la autenticación de la cuenta?
  • ¿El proceso de recuperación de claves está separado del inicio de sesión habitual?
  • ¿Se autentican y autorizan las solicitudes de archivos multimedia privados?
  • ¿Sigue activo el cifrado mientras los mensajes esperan sin conexión?
  • ¿Tienen los grupos y canales un límite de seguridad preciso?
  • ¿Se documentan las limitaciones sin promesas exageradas?

Marca las preguntas sin respuesta como «desconocido», no automáticamente como «seguro» o «inseguro». Un proveedor no necesita utilizar la misma arquitectura que todos sus competidores.

Sí necesita dar respuestas lo bastante precisas para que los usuarios entiendan en qué están confiando.

La opción más segura depende de tu modelo de amenazas

No existe una aplicación de mensajería universal que sea automáticamente la mejor para todas las personas y situaciones.

Un grupo familiar, un lugar de trabajo, un periodista y su fuente, un equipo sanitario o una comunidad pública pueden necesitar combinaciones diferentes de:

  • Confidencialidad
  • Verificación de identidad
  • Anonimato
  • Administración de grupos
  • Conservación de mensajes
  • Cumplimiento normativo
  • Recuperación
  • Compatibilidad con varios dispositivos
  • Código abierto
  • Auditorías independientes
  • Facilidad de uso

Empieza preguntando qué estás protegiendo y frente a quién.

En la comunicación personal habitual, los principales riesgos pueden ser el robo de cuentas, una red insegura, la pérdida de un dispositivo o una recopilación excesiva de datos.

En comunicaciones de mayor riesgo, también puedes necesitar identidades verificadas, políticas de mensajes temporales, dispositivos reforzados, procedimientos operativos estrictos y una revisión de seguridad independiente.

El cifrado no puede reparar un dispositivo comprometido ni impedir que un destinatario de confianza comparta un mensaje.

La privacidad empieza por expectativas precisas

Una aplicación fiable no pide a los usuarios que crean que todos los riesgos han desaparecido.

Explica:

  • Qué está protegido
  • Qué dispositivos guardan las claves
  • Qué procesa el servidor
  • Qué metadatos permanecen
  • Cómo funciona la recuperación
  • Dónde empieza y termina el E2EE
  • Qué protecciones aún no se han implementado

Esa claridad permite tomar decisiones informadas.

Una documentación clara es necesaria para evaluar, pero no basta para identificar la aplicación más segura. También importan la calidad de implementación, las actualizaciones oportunas, los hallazgos independientes y los riesgos de tu uso real. La guía de selección de herramientas de EFF también recomienda partir de las amenazas y considerar la apertura del código como una oportunidad de revisión, no como una garantía.

Como siguiente paso, haz una prueba inocua: verifica un contacto, envía un adjunto de ejemplo, revisa los dispositivos vinculados, examina qué cubre la copia de seguridad y confirma que ambos participantes utilizan los ajustes de forma fiable. No hagas la prueba con el material confidencial que quieres proteger.

Preguntas frecuentes

¿Qué hace segura a una aplicación de mensajería?

Una aplicación segura combina transporte de red protegido, autenticación robusta, controles de acceso rigurosos, gestión segura de claves, tratamiento responsable de datos y límites de privacidad claramente documentados. Para el contenido privado de los mensajes, el cifrado de extremo a extremo aporta una capa adicional importante.

¿Una aplicación de mensajería cifrada es automáticamente privada?

No. Una aplicación puede cifrar el contenido y seguir procesando información de cuentas, marcas de tiempo, miembros, confirmaciones, información de dispositivos u otros metadatos. La privacidad depende tanto del cifrado como de las prácticas generales de datos del servicio.

¿El cifrado de extremo a extremo oculta con quién hablo?

No necesariamente. El E2EE protege principalmente el contenido compatible. El servicio puede seguir necesitando información del emisor, el destinatario, los miembros, los horarios y el encaminamiento para entregar y sincronizar conversaciones.

¿Puede un proveedor de mensajería recuperar mensajes E2EE?

Depende del diseño de claves y copias. Un proveedor puede guardar historial cifrado y carecer de la clave privada para abrirlo. Un sistema de recuperación puede restaurar la clave solo cuando el usuario proporciona un secreto de recuperación separado.

¿Es segura la mensajería cifrada basada en el navegador?

Un navegador puede ejecutar criptografía robusta del lado del cliente, pero la seguridad sigue dependiendo de la implementación de la aplicación, la integridad del navegador, la seguridad del dispositivo, el almacenamiento de claves, la entrega del código de la aplicación desde el servidor y las extensiones y el sistema operativo del usuario.

¿Los chats de grupo siempre están cifrados de extremo a extremo?

No. Algunos servicios ofrecen E2EE para grupos y otros lo aplican solo a conversaciones directas. Consulta la documentación del proveedor para conocer el límite exacto.

¿Qué ocurre si cambia mi clave de cifrado?

Un cambio puede deberse a un dispositivo nuevo, una reinstalación, un restablecimiento de claves o una recuperación. Una aplicación segura debería hacerlo visible y permitir que los contactos verifiquen la nueva huella.

¿Basta el E2EE para comunicaciones muy sensibles?

El E2EE protege el contenido entre los dispositivos compatibles, pero no protege un dispositivo infectado o desbloqueado, no garantiza el comportamiento del destinatario ni oculta automáticamente los metadatos. Los usuarios de mayor riesgo también necesitan seguridad sólida de dispositivos y procedimientos operativos.

Abrir la mensajería de Livara
CONTINUE THE THREADPrivate messaging ↗
YOU’VE REACHED THE ENDBack to the reading room ↗