Base de conocimiento
Cifrado de extremo a extremo
Claves OpenPGP creadas en tu navegador. El correo que envías a otra dirección de OpenEmail se puede sellar antes de salir de la pestaña, y el correo sellado dirigido a ti se abre en el panel de lectura, descifrado en tu máquina. Las claves nunca son nuestras para entregarlas.
Detalles
- Las dos mitades están conectadas de extremo a extremo. Redactar a un destinatario cuya clave está publicada sella el cuerpo en el navegador antes de que salga la petición; al servidor se le entrega un blindaje que no puede leer, lo marca como
pgp-mimey construye un mensajemultipart/encryptedreal. La lectura funciona igual a la inversa: el texto cifrado se descarga, se descifra en la pestaña y se muestra como correo corriente. - El algoritmo es el que ya usa todo el mundo: OpenPGP, a través de openpgp.js, y PGP/MIME en el cable. Una clave v4 sobre Curve25519, la misma forma que emite Proton y que produce gpg con su algoritmo moderno por defecto. Así que el correo que esto lee es en principio el mismo correo que producen Thunderbird, gpg y Proton, y aquí no hay ningún formato propio que hubiera que deshacer más adelante.
- En la práctica, eso sí, es de OpenEmail a OpenEmail. No hay Web Key Directory, ni consultas a servidores de claves, ni análisis de cabeceras Autocrypt en ninguna parte de este código: el único sitio donde se encuentra la clave de un destinatario es nuestro propio directorio, que contiene claves publicadas desde esta aplicación por personas cuya dirección está en un dominio alojado aquí. Tampoco hay forma de repartir tu clave. La aplicación publica tu mitad pública en ese directorio y no ofrece copiarla ni exportarla, así que un corresponsal en Thunderbird no tiene ninguna vía admitida para obtenerla. Interoperar con el mundo PGP más amplio es una propiedad del formato, no algo que el producto haga por ti todavía.
- La lectura no está limitada así, porque descifrar no necesita un directorio. Cualquier mensaje PGP/MIME o PGP en línea que llegue a este buzón sellado con una clave de este navegador se abre, lo envíe quien lo envíe y con el cliente que use. Eso incluye los mensajes sellados con una clave que desde entonces hayas rotado: las claves retiradas permanecen en el llavero y se prueban junto a la actual, así que rotar no te cuesta el correo que ya recibiste.
- El verde significa abierto, y no se llega a él de ninguna otra manera. La fila Details → Security se pone verde solo después de que un descifrado haya devuelto realmente texto plano en esta pestaña, nunca a partir de un campo del mensaje ni del hecho de que llegara un sobre cifrado. Dice «Encrypted end-to-end. Opened with your key in this browser». Todo lo que se queda corto tiene su propia frase en lugar de una compartida: aún buscando, clave bloqueada, sellado con una clave que este navegador no tiene, no se pudo abrir, aquí no hay clave alguna, y este navegador no nos dejó mirar. «We could not check» y «you do not have the key» son afirmaciones distintas y la fila te obliga a leer cuál te tocó.
- S/MIME todavía no se puede abrir. Es CMS bajo un certificado X.509, openpgp.js no puede tocarlo y en el producto no hay ningún almacén de certificados donde guardar la clave aunque pudiera, así que un mensaje S/MIME dice que OpenEmail no puede abrirlo, y no se le ofrece un desbloqueo que no serviría de nada.
- La mitad privada se genera en tu navegador y nunca sale de él: ni cifrada, ni dentro de una copia de seguridad, ni en una herramienta de soporte. Al servidor nunca se le envía, así que aquí no hay nada que entregar, requisar judicialmente ni filtrar. Se guarda bloqueada con frase de contraseña en una base de datos IndexedDB propia, openemail-keyring, deliberadamente fuera del alcance del consejo de «borra la caché» y del reinicio de la consola de depuración: ambos limpian la caché de consultas, y una clave guardada junto a ella haría que un consejo de soporte rutinario destruyera para siempre todos los mensajes cifrados que la cuenta hubiera recibido. Eliminar tu cuenta sí la elimina, porque ahí el correo también se va. Desbloquearla la mantiene en memoria durante 15 minutos de inactividad y 8 horas como máximo, tras lo cual leer el siguiente mensaje sellado vuelve a pedir la frase de contraseña.
- No hay depósito ni recuperación, y eso es permanente y no algo por construir. Tu frase de contraseña es la única vía de entrada; olvídala y todos los mensajes que alguien te selló se quedan en nuestros servidores como texto cifrado que nadie puede leer, nosotros incluidos. El correo se ha ido, y por mucho que se pida no se recupera. La pantalla de alta lo dice antes de que exista la primera clave, tras una casilla que tienes que marcar, y el archivo de respaldo es obligatorio, y el botón Done sigue desactivado hasta que lo hayas descargado. Ese archivo se escribe sin el endurecimiento adicional en reposo que usa este navegador, a propósito, para que siga importándose en versiones antiguas de gpg: una copia de seguridad que no puedes abrir en otro sitio no es una copia de seguridad. La clave vive además en un navegador de un dispositivo, y un teléfono o un segundo portátil no tienen nada hasta que importes ese archivo allí.
- El directorio contiene claves públicas y nada más, y una clave pertenece a una persona y no a un buzón, ya que una atada a una dirección tendría que copiarse entre todas las personas con las que se comparte esa dirección, lo cual es depósito con otro nombre. Consultar una requiere una sesión iniciada y permiso para enviar, nunca un extremo público, porque un sondeo abierto de direcciones es un oráculo que le dice a cualquiera qué direcciones son buzones activos aquí. Responde igual para «no alojamos eso» y «lo alojamos y nadie ha publicado una clave», ya que distinguirlos solo mueve el oráculo detrás de un inicio de sesión en lugar de eliminarlo. Y una clave deja de repartirse en el momento en que su propietario pierde el acceso a la dirección, y no cuando alguien se acuerda de revocarla.
- Cada byte se sella en el navegador en el momento en que lo escribes, que es lo que hace que los envíos diferidos funcionen siquiera: un mensaje programado o uno que espera en la ventana de deshacer se guarda como texto cifrado y lo despacha después una cola que no tiene ninguna clave y no puede leer nada de él. Un destinatario cuya consulta en el directorio FALLÓ bloquea el envío en lugar de tratarse en silencio como si no tuviera clave. Y un mensaje sellado solo sale por una vía que transporta un mensaje entero. Una vía de salida que aceptara un cuerpo HTML publicaría el blindaje como texto visible e informaría de un éxito, así que un envío que fuera a acabar ahí se rechaza antes de que salga un byte y no después.
- Lo que costará sellar, medido en lugar de conjeturado: el blindaje es unas 1,86 veces los bytes en bruto, así que unos 2,7 MB de adjuntos caben en los 5 MB que permite la vía de envío, y el redactor rechaza una carga superior a eso antes de dedicar segundos a cifrar una que el transporte rechazaría. El correo cifrado no informa de aperturas ni de clics, porque el seguimiento por destinatario funciona variando el cuerpo por persona y un único bloque sellado no puede variar, y un enlace reescrito es un enlace que podemos leer, que es lo contrario de la afirmación. Un envío cifrado tampoco se puede deduplicar nunca con una clave de idempotencia: una clave de sesión nueva hace que el texto cifrado sean bytes distintos en cada intento, así que un reintento nunca tiene la misma huella que su original.
- La programación sella en el momento de redactar, no en el de enviar. El redactor construye el texto cifrado contra las claves que tienen sus destinatarios el día que lo escribes, no el día en que saldría el mensaje, la regla que este producto ya aplica a las plantillas y las traducciones, donde un mensaje programado lleva lo que aprobaste y no lo que cambiara después. La diferencia es que una plantilla desfasada solo está anticuada y una clave desfasada es ilegible, así que el redactor nombra la fecha con palabras en lugar de ofrecer una advertencia: «Sealed now, sent on …. Everyone on it will need the key they have today.» El rechazo que protege la otra mitad está desplegado pero nunca se ha disparado, porque todavía no puede existir un mensaje así: si existiera, editarlo después se rechazaría en lugar de permitirse en silencio, ya que parchear el cuerpo escribiría texto plano sobre el texto cifrado y cambiar los destinatarios cambiaría a quién se selló, y cualquiera de las dos cosas se entrega en claro mientras todas las pantallas lo siguen llamando cifrado.
- Dos cosas que el redactor no ofrecerá en absoluto, y lo dice en lugar de fallar en el cable. Una plantilla se renderiza en el servidor a partir de una versión publicada, así que no hay nada en este navegador que sellar. Una respuesta cita la conversación debajo y esa cita se añade después del punto en que se sellaría el cuerpo, dejando una copia legible del hilo entero fuera del sello, así que las respuestas y los reenvíos no se pueden cifrar hasta que el historial citado se pliegue dentro del texto cifrado.
- Nada de esto oculta tu línea de asunto, a quién escribiste ni cuándo. El asunto viaja en claro en un mensaje sellado exactamente igual que en cualquier otro, y el panel de lectura lo dice en el propio mensaje: «The subject and the addresses travelled in the clear; this text did not.» PGP cubre el cuerpo y ninguna implementación suya cubre el resto. Los borradores tampoco están sellados, porque el autoguardado sigue escribiendo texto plano en tu buzón mientras redactas, porque no guardar en silencio perdería trabajo, y el candado lo declara con palabras.
- Reconocer el correo que llega sellado fue lo primero y sigue en pie. PGP/MIME, el blindaje PGP en línea y S/MIME se renderizaban como un cuerpo vacío con dos adjuntos sin sentido, porque el analizador solo trata el texto plano y el HTML como legibles y dejaba caer el resto en la tira de archivos. Esas partes ahora se identifican, el mobiliario del protocolo se mantiene fuera de la lista de adjuntos, el texto cifrado se guarda intacto, que es de donde descifra el lector en lugar de descargar nada nuevo, y un mensaje que nadie aquí puede abrir sigue diciéndolo claramente.
- Un mensaje firmado se trata como algo aparte, porque lo es. El cuerpo de uno es legible, así que la búsqueda, las reglas y todo lo demás siguen funcionando sobre él; nunca se bloquea tras un candado ni se pasa por un descifrado. La fila informa «Signed by the sender. Signature not checked», atenuada, y sigue atenuada hasta que algo de aquí pueda verificar de verdad una firma, cosa que todavía no hace nada, incluso en un mensaje que se descifró correctamente. Ver que un mensaje está sellado no es lo mismo que haberlo abierto, y abrirlo no es lo mismo que saber quién lo selló.
- En un mensaje cifrado el cuerpo se retira de todo lo que de otro modo lo leería: el fragmento de búsqueda, el barrido del cuerpo del puntuador de phishing, la comprobación de escritura con IA, las condiciones sobre el cuerpo en las reglas, la importación de invitaciones de calendario y los resúmenes de hilo. La mitad de autenticación de la comprobación de phishing sigue ejecutándose, porque DMARC, DKIM y SPF se leen de cabeceras que el texto cifrado no oculta. Descifrar no cambia nada de eso. El texto plano existe solo en la pestaña que lo abrió, así que un mensaje sellado sigue sin poder buscarse y sigue fuera de las funciones de IA incluso después de que lo hayas leído, y no se ofrece traducirlo. Ese es el coste de la afirmación, no una omisión.