¿Es posible el cifrado fuera del registro con el correo electrónico?

La negación directa simple es fácil de lograr con PGP: ¡simplemente no firme el correo electrónico que envía! Cualquiera puede enviar correos electrónicos con contenido arbitrario y presunto remitente; las firmas se significan específicamente para cancelar la negabilidad de reenvío.

Sin embargo, si no firmas, también pierdes integridad. Lo que desea es poder enviar un correo electrónico tal que:

• el destinatario puede estar razonablemente seguro de que el correo electrónico proviene de quién cree que es el remitente y no se ha modificado en tránsito;
• pero ni los atacantes externos ni el destinatario obtienen ninguna prueba que pueda mostrar a terceros que el presunto remitente realmente envió el correo electrónico.

Protocolos conectados , como la mensajería instantánea, puede lograr estas propiedades mediante el uso de un secreto compartido establecido con un protocolo como Diffie-Hellman . Cuando Alice y Bob comparten el secreto K (y usaron la autenticación para establecer ese conocimiento compartido), y Bob recibe un mensaje con un MAC valor que usa K , entonces Bob sabe que el mensaje proviene de Alice, porque solo Alice y él saben K , y Bob no. envíalo él mismo. Sin embargo, Bob no tiene nada "convincente" que mostrar, porque como sabe K , podría haber falsificado todos los mensajes.

Con los correos electrónicos, no hay conexión, por lo que no hay un secreto compartido semitransitoria: un valor secreto que el remitente y el destinatario comparten, nunca se almacenan en un archivo, sino que se conservan para varios mensajes sucesivos. Sin embargo, hay un tipo de formato de "cifrado con MAC" en OpenPGP, sección 5.13 . El formato también es muy flexible, por lo que uno podría crear un mensaje OpenPGP que contenga:

• un paquete de clave de sesión cifrada de clave pública que contiene un K cifrado con la clave pública del destinatario;
• un paquete de firma que incluye una firma calculada sobre el paquete anterior (y solo sobre ese paquete, no los datos de texto simple);
• los datos de texto sin formato, como un paquete de "cifrado con MAC".

Dicho correo electrónico encarnaría la negabilidad hacia adelante con integridad: desde el exterior, se puede probar que el presunto remitente envió al menos un mensaje, un día, al destinatario; y el destinatario puede mostrar K y la prueba indica que K también fue conocido por el remitente. Sin embargo, nadie puede demostrar que cualquier mensaje específico contenidos se haya cifrado con K .

Desafortunadamente, aunque el formato OpenPGP puede admitir muchas combinaciones, este no es necesariamente el caso de implementaciones existentes (como GnuPG ). Además, el paquete de "cifrado con MAC" utiliza un MAC casero barato (simplemente agrega el hash SHA-1 de los datos, y encripta todo el lote) que no me parece muy seguro. No estoy al tanto de los estudios extensivos de ese tipo de construcción de MAC, pero no apostaría mi última camiseta a su robustez.

Por lo tanto, puede potencialmente tener denegación hacia adelante con autenticación e integridad en PGP pero solo mientras el software relevante admita esta combinación específica, que, por lo que sé , ellos no. Sin embargo.

En la investigación criptográfica, también hay otro tipo de algoritmo denominado firmas en anillo que podría aplicarse al tema: con En las firmas, el remitente (Alice) computa un tipo especial de firma que involucra su clave privada y la clave pública del destinatario (Bob), de manera que se puede probar, desde afuera, que Alice o Bob computaron la firma, pero cuál en realidad lo hizo es desconocido.

Actualmente no hay soporte definido para firmas de anillo en OpenPGP.

Como solicitó específicamente una "alternativa a SMTP", también podría abordar este problema desde una dirección totalmente diferente.

Como se describe con tanta elocuencia en @Thomas Pornin, OTR para correos no funciona porque el correo es una forma asincrónica de comunicación, mientras que el protocolo Diffie-Hellman necesita que ambas partes hablen entre sí directamente antes de que se pueda realizar cualquier cifrado.

Si no desea cambiar la forma en que funciona el cifrado, debe cambiar la forma en que funciona el correo. Hay dos opciones:

1. Use un correo electrónico asíncrono normal para cada paquete de comunicación que deba enviarse. Como dijo @Ross Dargan, OTR es bastante "hablador", por lo que es necesario intercambiar varios mensajes antes de poder enviar los datos reales. Esto puede llevar algún tiempo según el momento en que el remitente / receptor esté en línea.
2. Solo envíe una clase de invitación por correo, luego conéctese directamente al receptor y continúe siguiendo el protocolo normal de OTR para IM.

Ambos casos podrían estar bien ocultos por el cliente de correo electrónico para su conveniencia. (Gmail ya mezcla chats y correos en su bandeja de entrada (pero sin cifrado).)

Ambos desafían el propósito original del correo electrónico como comunicación asíncrona entre terminales que solo están activos o conectados a una red por tiempo desconocido y corto. Pero si nos fijamos en la infraestructura de hoy, esto ya casi no encaja. Por lo general, tanto el remitente como el receptor (o al menos las máquinas de sus clientes) están activos y en línea 24/7. Incluso si no, el tiempo de espera adicional es solo una causa menor de inconvenientes.

¿Las buenas noticias? Ambas versiones no se basan en un protocolo modificado ni en SMTP ni en OTR. Puede implementar fácilmente todos los cambios necesarios en los clientes. ¡Feliz codificación!

Ya se ha mencionado, pero los autores de OTR proporcionan una explicación muy buena en su documento :

  

Sin embargo, hay una solución que Alice puede usar en este caso, llamada anillo   firmas Una firma digital puede probar que Alice envió un   mensaje. Una firma de anillo extiende este concepto y puede usarse para   demostrar que, dado un conjunto de personas, algún miembro del conjunto envió el   Mensaje, pero es imposible determinar cuál. Asi que alicia puede   envíe su mensaje firmado con una firma de timbre para el juego {Alice, Bob}   (y cifrado a Bob). En este caso, Bob podrá verificar que   de hecho vino de Alicia (ya que él sabe que él mismo no lo envió),   pero no podrá demostrar esto a nadie más, ya que él simplemente puede   tan fácilmente generar la firma del anillo a sí mismo. Las firmas del anillo tienen   implementado como una extensión de PGP.