Índice
- Los tres sentidos de «correo cifrado»
- Cifrado de transporte: necesario, no suficiente
- Extremo a extremo: PGP vs S/MIME
- Cifrado de acceso cero del proveedor
- El problema de los metadatos que todos saltan
- Dónde se sitúan de verdad los grandes proveedores
- Un marco de decisión
Los tres sentidos de «correo cifrado»
«Correo cifrado» es una de las expresiones más manidas del mercado de la privacidad, porque casi todos los proveedores pueden afirmarla con honestidad mientras se refieren a cosas completamente distintas. Hay tres capas de cifrado diferenciadas en el correo, y defienden contra tres adversarios distintos:
- Cifrado de transporte (TLS / STARTTLS) — la conexión entre dos servidores de correo está cifrada. Esto detiene a un fisgón pasivo en el cable. Hoy es casi universal y es el mínimo imprescindible, no una función.
- Cifrado de extremo a extremo (PGP o S/MIME) — el cuerpo del mensaje se cifra en el dispositivo del remitente con la clave pública del destinatario, de modo que solo la clave privada del destinatario puede abrirlo. Ningún servidor del camino puede leerlo.
- Cifrado de acceso cero del proveedor — el proveedor almacena tu buzón cifrado con claves derivadas de tu contraseña, así que ni él puede leer los mensajes presentes en tu cuenta.
Cuando un proveedor de consumo dice «tu correo está cifrado», casi siempre se refiere a la capa 1, a veces a la capa 1 más el cifrado de disco en reposo. Cuando un ingeniero preocupado por su privacidad pide correo cifrado, casi siempre se refiere a la capa 2 o 3. Esa brecha es todo el tema de esta guía.
Cifrado de transporte: necesario, no suficiente
TLS — normalmente negociado sobre SMTP con STARTTLS — cifra el salto entre dos servidores de correo. Su valor es real: impide que alguien que vigila la red lea tu correo en vuelo, y la infraestructura moderna lo usa casi en todas partes.
Pero TLS es salto a salto, no de extremo a extremo. Un mensaje suele atravesar varios servidores entre remitente y destinatario, y en cada salto se descifra, se procesa y se vuelve a cifrar para el siguiente tramo. Eso significa que cada servidor de la cadena — tu proveedor, el del destinatario y cualquier relevo intermedio — maneja el mensaje en claro. El cifrado de transporte protege el mensaje de los desconocidos en el cable; no hace nada para protegerlo de los propios proveedores.
Hay un segundo truco: STARTTLS es oportunista por defecto. Si el servidor receptor no anuncia TLS, muchos remitentes recurrirán en silencio a una entrega en claro en lugar de fallar. Así que «usamos TLS» ni siquiera garantiza que un mensaje dado se cifrara en todo el camino. Por eso el cifrado de transporte, con ser esencial, es el suelo y no el techo.
Extremo a extremo: PGP vs S/MIME
El cifrado de extremo a extremo (E2EE) mueve el cifrado a los extremos. El remitente cifra el mensaje con la clave pública del destinatario; solo la clave privada del destinatario puede descifrarlo. Como los servidores intermedios nunca tienen la clave privada, ninguno puede leer el cuerpo — ni tu proveedor, ni un relevo, ni el proveedor del destinatario. Es el mismo modelo de clave pública que sustenta los gestores de contraseñas por CLI y el manejo de claves que cubrimos para desarrolladores; la diferencia está en quién gestiona la distribución de claves.
Dominan dos estándares, y su diferencia se reduce por completo a la confianza y la distribución de claves:
PGP (OpenPGP). Una «red de confianza» descentralizada. Los usuarios generan sus propios pares de claves e intercambian directamente sus claves públicas, verificándolas fuera de banda (una huella por teléfono, una clave firmada por un contacto común). Es de máxima flexibilidad y no exige autoridad central, pero la distribución de claves es manual, de ahí la fama de fricción de PGP. Es el estándar entre particulares, periodistas y comunidades de código abierto.
S/MIME. Las claves públicas se vinculan a identidades mediante certificados emitidos por una autoridad de certificación (AC) central. Esto simplifica mucho el despliegue en una organización gestionada — el departamento de TI provisiona los certificados de forma centralizada — pero ata tu confianza a esa jerarquía de AC. S/MIME es la opción habitual en empresas y administraciones, donde ya existe una PKI gestionada.
Ambos ofrecen la misma garantía central: un mensaje que ningún servidor intermedio puede leer, más una firma digital que prueba el remitente y que no hubo alteración. El coste, en ambos casos, es que el destinatario también debe participar. No puedes enviar de forma transparente un mensaje E2EE a alguien sin clave.
Cifrado de acceso cero del proveedor
Hay un tercer modelo que sortea el dolor de la distribución de claves para el caso común de un buzón privado: el cifrado de acceso cero en el proveedor.
Aquí el proveedor cifra tu buzón almacenado con claves derivadas de tu contraseña, en tu dispositivo, de modo que el servidor solo guarda texto cifrado de tu cuenta. Ni el proveedor puede leer el correo en reposo. Proton Mail es la implementación más conocida: los mensajes entre usuarios de Proton están cifrados de extremo a extremo por defecto, y todo el buzón se conserva bajo cifrado de acceso cero, de forma que el propio Proton no puede leerlo.
El límite honesto está en la naturaleza del correo. Cuando un usuario de Proton escribe a un usuario de Gmail, el mensaje no puede cifrarse de extremo a extremo salvo que el usuario de Gmail también tenga PGP, porque el otro extremo no tiene clave. Proton lo resuelve dejándote enviar un mensaje protegido por contraseña a un no usuario: el destinatario lo abre mediante un enlace y una contraseña que compartes aparte. Es un puente real, pero hay que compartir la contraseña por otro canal — la misma restricción de fondo que PGP, empaquetada de forma más cómoda.
El cifrado de acceso cero atrae porque te da un buzón legible, buscable en el dispositivo, sin configuración, que el proveedor sigue sin poder leer — sin obligar a cada corresponsal a gestionar claves.
El problema de los metadatos que todos saltan
Este es el punto más importante y más ignorado de cualquier discusión honesta sobre correo cifrado: el cifrado protege el contenido, no los metadatos.
Incluso con un cifrado de extremo a extremo impecable, lo siguiente suele viajar en claro y puede registrarlo tu proveedor, el del destinatario y la red:
- quién envió el mensaje y quién lo recibió,
- la marca de tiempo,
- el tamaño del mensaje,
- y, en muchas implementaciones, la línea de asunto.
Así que el cifrado responde a «qué decía el mensaje», pero no a «quién habla con quién, cuándo y con qué frecuencia». Para un modelo de amenaza en el que ocultar tus contactos importa — no solo tus palabras — el cifrado del contenido por sí solo es insuficiente. Los proveedores que minimizan la retención de metadatos, y las herramientas de capa de red, abordan otra parte del problema. Trata el límite de los metadatos como un hecho de diseño del correo, no como un defecto de un proveedor concreto, y planifica en consecuencia.
Dónde se sitúan de verdad los grandes proveedores
| Proveedor | En tránsito | En reposo | Extremo a extremo por defecto | El proveedor puede leer tu correo |
|---|---|---|---|---|
| Gmail (consumo) | TLS | Sí (Google tiene las claves) | No | Sí |
| Outlook / Microsoft 365 (consumo) | TLS | Sí (Microsoft tiene las claves) | No | Sí |
| Gmail Workspace + CSE / S/MIME | TLS | Sí | Solo si se configura | Reducido con CSE |
| Proton Mail | TLS | Acceso cero (tú tienes las claves) | Sí, entre usuarios de Proton | No |
El patrón es constante: los servicios de consumo cifran en tránsito y en reposo pero tienen las claves, así que pueden — y para funciones y solicitudes legales, lo hacen — leer el contenido. Lograr el extremo a extremo en Gmail u Outlook es posible pero exige una configuración deliberada (S/MIME, o cifrado del lado del cliente en planes de pago concretos). Proton Mail está construido E2EE-y-acceso-cero por defecto, lo que lo convierte en el proveedor más citado cuando «correo cifrado» se refiere a la capa 2 o 3 en lugar de la capa 1.
Una nota sobre la verificación, en el espíritu de la soberanía de datos: una afirmación de cifrado que no puedes inspeccionar es una aseveración, no una garantía. Los clientes de código abierto — Proton publica los suyos — permiten que revisores independientes confirmen que las claves se generan en tu dispositivo y que el texto en claro nunca llega al servidor. Prefiere proveedores cuyas afirmaciones sean auditables a los que simplemente las enuncian.
Un marco de decisión
Deja de preguntar «qué correo está más cifrado» y pregunta mejor «¿quién no debe poder leer esto, y el destinatario está dispuesto a participar?»
El cifrado de transporte basta cuando el contenido es rutinario y tu única preocupación es un fisgón de red. Todo proveedor serio ya te lo da; no hay nada que configurar.
Usa extremo a extremo (PGP o S/MIME) cuando mensajes concretos deban ser ilegibles para todo servidor del camino y el destinatario pueda tener una clave — un colega, la fuente de un periodista, una organización con S/MIME gestionado. Acepta el paso de intercambio de claves como el precio de la garantía.
Usa un proveedor de acceso cero como Proton Mail cuando quieras todo tu buzón ilegible para el proveedor sin obligar a cada corresponsal a usar PGP, con un respaldo protegido por contraseña para el mensaje cifrado ocasional a un externo.
Elijas lo que elijas, recuerda dos cosas. Primero, los metadatos no están cifrados — el cifrado oculta las palabras, no la relación. Segundo, verifica la afirmación: prefiere clientes de código abierto y una jurisdicción respetuosa con la privacidad para que «no podemos leer tu correo» sea algo que puedas comprobar en vez de algo que debas creer.
Para la parte de almacenamiento de la misma configuración de privacidad, mira nuestra guía de almacenamiento cloud cifrado para desarrolladores, y para la cuestión más amplia de mantener los datos fuera de los servicios bajo jurisdicción estadounidense, el pilar sobre la soberanía de datos.
