La respuesta corta
El cifrado de extremo a extremo implementado correctamente significa que el contenido del mensaje está cifrado en el dispositivo del remitente y solo puede ser descifrado por los puntos finales receptores previstos. El servicio de entrega debe manejar texto cifrado, no texto sin formato ni claves de conversación. Pero E2EE protege una ruta entre los puntos finales: no hace que ninguno de los puntos finales, el destinatario, cada pieza de metadatos o cada copia de seguridad sean confiables.
¿Qué significa realmente “de extremo a extremo”?
Los puntos finales son los dispositivos o instancias de aplicaciones que contienen las claves necesarias para leer una conversación. El cifrado ocurre antes de que el mensaje abandone el punto final del remitente; el descifrado ocurre después de que llega a un punto final de recepción autorizado.
Ese límite importa. El cifrado de transporte como TLS protege una conexión entre un dispositivo y un servidor. El cifrado de extremo a extremo agrega un límite separado a nivel de mensaje destinado a evitar que el intermediario reciba las claves de texto sin formato. El estándar Messaging Layer Security del IETF describe el objetivo como hacer que los mensajes sean accesibles a los puntos finales que se comunican en lugar de a los servidores que los entregan.
La etiqueta del producto por sí sola no es una prueba. La autenticación de identidad, la administración de claves, los cambios de membresía de grupos, la eliminación de claves antiguas, la calidad de la implementación y el comportamiento de las copias de seguridad afectan el resultado real de la seguridad.
Para qué está diseñado E2EE
Las garantías exactas dependen del protocolo y la implementación, pero el moderno E2EE autenticado está destinado a abordar estos riesgos:
Intercepción de red
Alguien que observe Wi-Fi, un ISP o una red intermedia debería ver tráfico cifrado en lugar de contenido de mensaje legible.
Un proveedor de servicios curioso
Un servicio de entrega que no contiene claves de conversación no debería poder abrir mensajes de texto cifrados normales.
Compromiso del servidor de entrega
El cifrado a nivel de mensajes puede preservar la confidencialidad del contenido incluso si el enrutamiento de la infraestructura o el texto cifrado en cola temporal están comprometidos.
Cambios de mensajes no detectados
El cifrado autenticado puede permitir a los destinatarios rechazar texto cifrado que haya sido alterado o falsificado, sujeto a la autenticación e implementación de claves correctas.
Alguna exposición a mensajes pasados
Los protocolos con secreto directo eliminan o avanzan el material de claves antiguo para que un compromiso de clave posterior no revele automáticamente todos los mensajes anteriores. Esta es una propiedad de protocolo adicional, no un sinónimo de E2EE.
Lo que E2EE no protege automáticamente
La mayoría de los malentendidos en materia de seguridad comienzan cuando la protección del contenido del mensaje se trata como protección de todo el sistema de comunicación.
Un punto final comprometido o desbloqueado
El malware, un dispositivo robado desbloqueado, vistas previas de notificaciones, capturas de pantalla, teclados y servicios de accesibilidad pueden encontrar texto sin formato antes del cifrado o después del descifrado.
La persona que recibe el mensaje.
Un destinatario autorizado puede copiar, fotografiar, citar o reenviar lo que legítimamente puede leer. Los controles que desaparecen reducen el historial retenido; no pueden hacer olvidar a un destinatario hostil.
Todos los metadatos
La entrega puede exponer el tiempo, el volumen de tráfico, las direcciones IP, los destinos, los tokens de dispositivos u operaciones de grupo. Los protocolos y arquitecturas pueden minimizar o proteger partes de estos metadatos, pero el cifrado de contenido por sí solo no los elimina.
Copias de seguridad y exportaciones sin cifrar
Si el historial en texto plano o las claves recuperables se copian en otro sistema, esa copia tiene su propio límite de seguridad. "El chat es E2EE" no prueba que todas las copias de seguridad lo sean.
¿Quién está realmente al otro lado?
El cifrado con una clave incorrecta o sustituida puede crear una conversación perfectamente cifrada con la parte equivocada. La verificación de claves y la vinculación de identidades confiables siguen siendo importantes.
Disponibilidad y coerción
Un servicio aún puede retrasar, bloquear, limitar la velocidad o eliminar el tráfico cifrado. E2EE tampoco puede evitar que una persona se vea obligada a desbloquear un punto final o revelar lo que sabe.
Modelo de amenaza: ¿Ayuda E2EE?
Una pregunta de seguridad útil nombra al adversario en lugar de preguntar si una aplicación está simplemente "encriptada".
| Guión | ¿E2EE protege el contenido? | ¿Qué más importa? |
|---|---|---|
| El observador de la red intercepta el tráfico | Generalmente si | Protocolo sólido, implementación segura, límites de análisis de tráfico |
| El servidor de entrega está vulnerado | Generalmente si | Las claves deben permanecer en los puntos finales autorizados; los metadatos pueden permanecer visibles |
| Me roban el teléfono estando desbloqueado | No | Bloqueo de dispositivo, protección de almacenamiento local, política de notificación, retención breve |
| El destinatario graba intencionalmente el mensaje | No | Confianza, política, marcas de agua, divulgación limitada, controles legales |
| El atacante sustituye una clave de identidad | No por sí solo | Verificación de claves, transparencia, autenticación, advertencias de cambio. |
| El servicio se niega a entregar mensajes | No | Diseño de disponibilidad, seguimiento, plan de comunicación alternativo. |
Cómo maneja City of Hats este límite
City of Hats trata a E2EE como una capa en un modelo de amenaza más amplio. Las declaraciones a continuación describen nuestra arquitectura publicada y el comportamiento del producto; no son una afirmación de que el software pueda eliminar el riesgo de los endpoints o el comportamiento de los destinatarios.
Cifrado a nivel de mensajes
City of Hats documenta E2EE del lado del cliente para mensajes, archivos y llamadas Hat-to-Hat, utilizando el establecimiento de claves híbridas X25519 y ML-KEM-768 con Double Ratchet y AES-256-GCM. Las claves de descifrado de conversaciones deben permanecer en los dispositivos autorizados.
Transparencia técnica →Menos identidad de registro
Se puede crear un Hat sin número de teléfono ni correo electrónico. Phrase IDs, Hats múltiple y Hats desechable reducen la necesidad de vincular cada contexto de comunicación a un operador o identidad de buzón. No hacen que un dispositivo o conexión de red comprometidos sean anónimos.
Disposable Hats →Llamadas cifradas retransmitidas
Los documentos City of Hats transmiten voz y video para que el otro participante no reciba una dirección IP directa de igual a igual. El relé maneja medios cifrados, mientras que los metadatos a nivel de red aún requieren un modelo de amenaza realista.
Llamadas cifradas →No hay ruta de recuperación de conversación
El servicio de mensajería para consumidores está diseñado sin una bóveda de recuperación de mensajes mantenida por el proveedor. Perder el único dispositivo autorizado puede significar perder el historial de mensajes. Esto mejora la resistencia a las demandas de recuperación del lado del servidor, pero es una compensación deliberada de disponibilidad.
Privacidad y manejo de datos →Controles después del parto
View Once, Recall, GeoLock, Certified Send, Channel Seal y otros modos de seguridad pueden limitar el acceso o la retención normales. Estos controles reducen la exposición; no pueden derrotar a un destinatario autorizado utilizando una segunda cámara o un punto final ya comprometido.
Modos de seguridad →Contextos de comunicación quemables
Hats y los canales se pueden quemar o dejar que caduquen, por lo que no son obligatorios una identidad de larga duración y un historial de conversaciones ilimitado. La destrucción reduce lo que queda disponible más adelante; no puede retractar información ya capturada fuera del sistema protegido.
Channel Seal →Cómo evaluar un mensajero cifrado
No se limite a la frase "cifrado de extremo a extremo". Pregunta al proveedor o a su documentación:
- ¿Qué tipos de comunicación son E2EE de forma predeterminada: mensajes, grupos, archivos, llamadas e interacciones comerciales?
- ¿Dónde se generan, almacenan, rotan, realizan copias de seguridad y eliminan las claves?
- ¿Cómo se verifican las claves de identidad y qué sucede cuando cambia una clave?
- ¿Qué contenidos y metadatos puede observar o retener el servicio?
- ¿Qué sucede en un dispositivo comprometido, perdido o recién vinculado?
- ¿Pueden los destinatarios exportar, reenviar, capturar o conservar contenido de forma permanente?
- ¿Están disponibles las especificaciones de protocolo, el código fuente, las auditorías o la evidencia técnica reproducible?
- ¿Qué propiedades de seguridad son independientes de E2EE, como el secreto directo, la seguridad posterior al compromiso, la resistencia de los metadatos y la disponibilidad?
El resultado final
El cifrado de extremo a extremo es esencial porque puede eliminar el servicio de entrega y la red del conjunto de partes a las que se les confía el contenido del mensaje. No es todo el sistema de privacidad. Una comunicación segura y sólida también depende de los puntos finales, la identidad, los metadatos, la retención, la recuperación, el comportamiento de los destinatarios y la documentación honesta de las compensaciones.
Fuentes primarias y lecturas adicionales.
Estándares y materiales técnicos propios utilizados para este artículo. Consultado el 9 de agosto de 2026.
- IETF RFC 9420. The Messaging Layer Security (MLS) Protocol
- IETF RFC 9750. The Messaging Layer Security (MLS) Architecture
- NIST SP 800-124 Rev. 2. Guidelines for Managing the Security of Mobile Devices
- Signal. Sealed Sender: metadata and message delivery
- Signal. Disappearing messages and the hostile-recipient boundary
Las declaraciones de producto City of Hats enlazan con nuestra propia documentación publicada y deben evaluarse como afirmaciones de primera parte hasta que se verifiquen de forma independiente.
← Volver al Centro de Conocimiento