La pregunta útil no es si el cifrado suena potente, sino qué protege, quién conserva las claves y qué pruebas respaldan la afirmación.
«Cifrado de grado militar» no aporta información suficiente para evaluar una aplicación de mensajería. La expresión no indica quién tiene las claves, qué conversaciones están protegidas, si las copias de seguridad exponen texto en claro ni qué ocurre cuando un dispositivo queda comprometido.
La respuesta útil no consiste en descartar el cifrado, sino en sustituir una etiqueta impresionante por afirmaciones concretas que puedan comprobarse.
AES-256 es la elección de un algoritmo, no un modelo de seguridad completo
AES es un estándar público, no una tecnología militar secreta. FIPS 197 del NIST especifica AES-128, AES-192 y AES-256; el sufijo identifica la longitud de la clave. El estándar recibió una actualización editorial en 2023 sin cambios en el algoritmo.
Un cifrador robusto puede utilizarse en un sistema que dé al servicio acceso al texto en claro. Pregunte quién puede descifrar, no solo cuánto mide la clave. Pregunte también cómo se generan y almacenan las claves, cómo se autentican las identidades y qué condiciones de fallo hacen que la aplicación se detenga en lugar de continuar de forma insegura.
Cuando un proveedor menciona AES-GCM, es más específico que decir solo AES: GCM combina cifrado y autenticación. El manejo correcto de los nonces, la verificación de las etiquetas de autenticación y otros requisitos de implementación siguen siendo importantes. La especificación GCM del NIST es la referencia técnica; un logotipo no demuestra que una aplicación la implemente correctamente.
Cuatro afirmaciones distintas que el marketing suele mezclar
| Afirmación | Qué aborda | Qué no demuestra |
|---|---|---|
| Cifrado del transporte | Protección a través de una conexión, por ejemplo, entre la aplicación y el servidor | Que el servidor no pueda leer el contenido |
| Cifrado en reposo | Protección de los datos almacenados bajo un modelo concreto de claves y acceso | Que el operador no tenga la clave de descifrado |
| Cifrado de extremo a extremo | Protección del contenido entre los extremos designados | La seguridad de un extremo comprometido o la honestidad de un destinatario |
| Establecimiento de claves poscuántico | Resistencia frente a amenazas cuánticas especificadas durante el establecimiento de claves | Una auditoría completa de la aplicación, anonimato o seguridad futura garantizada |
El cifrado del transporte no implica que todas las bases de datos del proveedor almacenen texto en claro sin protección. Un servicio también puede cifrar los datos almacenados. La distinción relevante es si el proveedor controla las claves o tiene acceso de otro modo a contenido legible. Sea preciso en vez de sustituir un eslogan por otro.
Para una introducción más amplia, consulte qué protege el cifrado de extremo a extremo.
«Usa un estándar del NIST» no significa «validado conforme a FIPS»
FIPS 203 define ML-KEM, un mecanismo de encapsulación de claves. Una aplicación de mensajería puede indicar que utiliza ese algoritmo sin que toda la aplicación esté certificada o haya sido revisada de forma independiente. Los estándares, las pruebas de algoritmos, la validación de módulos criptográficos y las auditorías de seguridad de productos son tipos de evidencia diferentes.
El Programa de Validación de Módulos Criptográficos del NIST deja claro que implementar funciones aprobadas no basta para demostrar la validación de un módulo conforme a FIPS 140. Si un producto anuncia una validación, solicite el certificado, el módulo y la versión exactos, el entorno operativo y la configuración aprobada. Después determine qué parte del producto cubre realmente ese certificado.
Por eso tampoco debe usarse «seguridad de 256 bits» como puntuación global de una aplicación de mensajería. La composición de protocolos, la gestión de claves y la implementación pueden imponer límites diferentes.
La autenticación mediante contraseña no es cifrado de mensajes
Un mecanismo de inicio de sesión determina si un usuario puede acceder a una cuenta. E2EE determina quién puede leer el contenido protegido de los mensajes. Ninguno aporta automáticamente las propiedades del otro.
Por ejemplo, SRP está diseñado para autenticar sin transmitir la contraseña en sí. Eso no significa que el robo de una base de datos de autenticación sea inocuo. El análisis de seguridad de SRP en RFC 5054 explica que un verificador robado permite ataques de adivinación de contraseñas y otros riesgos. Evite concluir que «no hay contraseñas que robar, por tanto una intrusión en el servidor no puede importar».
En la práctica, conviene preguntar por la recuperación de cuentas, las sesiones activas y la relación entre el acceso a la cuenta y las claves de cifrado. Una respuesta que se limite a repetir «conocimiento cero» deja sin resolver las preguntas importantes.
Cinco preguntas para evaluar la página de seguridad de una aplicación de mensajería
- ¿Qué áreas están cubiertas? Los chats individuales, los grupos, los archivos, las llamadas, las publicaciones públicas y las copias de seguridad pueden tener límites distintos.
- ¿Quién conserva claves utilizables? Incluya las claves de recuperación, los dispositivos vinculados y los modos de procesamiento en el servidor.
- ¿Cómo se autentica el otro extremo? Busque verificación de claves, avisos significativos de cambios y un modelo de confianza documentado.
- ¿Qué pruebas existen? Las especificaciones, las compilaciones reproducibles, los vectores de prueba y las auditorías independientes responden a preguntas diferentes. Pida la versión y el alcance de cada uno.
- ¿Qué sigue siendo visible o vulnerable? Los metadatos, los dispositivos comprometidos, los mensajes copiados y el contenido público no deben desaparecer de la explicación.
Aplique las mismas preguntas a Livara. Su documentación de seguridad menciona LVR1 y LGS1 y publica límites operativos. Trátelos como afirmaciones del producto que deben evaluarse, no como una certificación independiente. El Proof Lab ofrece demostraciones limitadas y comprobaciones de artefactos, no una prueba de que cada función o versión sea segura.
Cómo leer una auditoría independiente
Compruebe la fecha, el auditor, la revisión del código, las plataformas incluidas y los componentes excluidos. Lea los hallazgos y el estado de su corrección, no solo el distintivo del resumen. Una auditoría de una biblioteca criptográfica no cubre automáticamente la recuperación de cuentas, la aplicación web, las notificaciones ni la seguridad operativa.
La ausencia de auditoría es una carencia de garantías, no una prueba de una vulnerabilidad concreta. A la inversa, una auditoría no es una garantía de por vida. Una comparación útil registra las pruebas y sus límites en lugar de proclamar un ganador universal como «el más seguro».
Preguntas frecuentes
¿«De grado militar» siempre es otra forma de decir AES-256?
No. No deduzca un algoritmo ni una certificación específicos a partir de esa expresión. Pida al proveedor que indique exactamente qué quiere decir.
¿Un cifrado más fuerte impide las capturas de pantalla o el malware?
No impide que un destinatario copie contenido ni que un dispositivo comprometido exponga datos a los que puede acceder. Son amenazas diferentes.
¿Qué señal es mejor que un eslogan de seguridad?
Un alcance claro, un protocolo identificado, límites explícitos y pruebas revisables sobre la implementación distribuida. La explicación debe ayudarle a decidir en qué confiar y qué sigue necesitando comprobaciones.
