È possibile la crittografia stile off-the-record con l'e-mail?

La semplice negazione in avanti è facile da ottenere con PGP: semplicemente non firmare l'e-mail che invii! Chiunque può inviare e-mail con contenuti arbitrari e presunti mittenti; le firme si intendono specificamente per annullare la negazione in avanti.

Tuttavia, se non ti firmi, perdi anche l'integrità. Quello che desideri è poter inviare un'email in modo che:

• il destinatario può essere ragionevolmente sicuro che l'email provenga da chi crede che il mittente sia, e non è stato alterato durante il transito;
• ma né gli aggressori esterni né il destinatario stesso ottengono alcuna prova che possa essere mostrata a terzi che il presunto mittente abbia davvero inviato l'email.

Protocolli connessi come la messaggistica istantanea possono ottenere queste proprietà usando un segreto condiviso stabilito con un protocollo come Diffie-Hellman . Quando Alice e Bob condividono il K segreto (e utilizzano l'autenticazione per stabilire quella conoscenza condivisa), e Bob riceve un messaggio con un MAC valore che utilizza K , quindi Bob sa che il messaggio proviene da Alice, perché solo Alice e lui stesso conoscono K e Bob no mandalo da solo Tuttavia, Bob non ha nulla di "convincente" da mostrare, perché poiché sa K , potrebbe aver falsificato tutti i messaggi.

Con le e-mail, non vi è alcuna connessione, quindi nessun segreto condiviso semi-transitorio: un valore segreto che il mittente e il destinatario condividono, mai archiviato in un file ma ancora conservato per diversi messaggi successivi. Tuttavia, esiste un tipo di formato "crittografia con MAC" in OpenPGP, sezione 5.13 . Il formato è anche molto flessibile, quindi un potrebbe creare un messaggio OpenPGP contenente:

• un pacchetto chiave di sessione crittografato a chiave pubblica che contiene un K > crittografato con la chiave pubblica del destinatario;
• un pacchetto di firma che include una firma calcolata sul pacchetto precedente (e solo su quel pacchetto, non i dati in testo normale);
• i dati in testo semplice, come un pacchetto "encryption-with-MAC".

Tale e-mail potrebbe incarnare in avanti la negabilità con integrità: dall'esterno, si può dimostrare che il presunto mittente ha inviato almeno un messaggio, un giorno, al destinatario; e il destinatario può mostrare K e la dimostrazione dice che K era noto anche al mittente. Tuttavia, nessuno può dimostrare che qualsiasi messaggio specifico contenuto sia stato crittografato con K .

Sfortunatamente, sebbene il formato OpenPGP possa supportare molte combinazioni, questo non è necessariamente il caso di implementazioni esistenti (come GnuPG ). Inoltre, il pacchetto "encryption-with-MAC" utilizza un MAC casalingo economico (semplicemente aggiunge l'hash SHA-1 dei dati e crittografa tutto) che non mi sembra molto sicuro. Non sono a conoscenza di studi approfonditi su questo tipo di costruzione MAC, ma non scommetterei la mia ultima maglia sulla sua robustezza.

Quindi puoi potenzialmente avere precedenti denunce con autenticazione e integrità in PGP ma solo finché il software pertinente supporta questa combinazione specifica, che, per quanto ne so , loro non. Eppure.

Nella ricerca crittografica, c'è anche un altro tipo di algoritmo chiamato firme ad anello che potrebbero essere applicate al soggetto: con in anello, il mittente (Alice) calcola uno speciale tipo di firma che coinvolge la sua chiave privata e la chiave pubblica del destinatario (Bob), in modo che possa essere provato, dall'esterno, che sia Alice che Bob hanno calcolato la firma, ma quale è stato effettivamente fatto è sconosciuto.

Non esiste un supporto attualmente definito per le firme degli squilli in OpenPGP.

Come hai chiesto espressamente "un'alternativa a SMTP", puoi affrontare questo problema anche da un'altra direzione.

Come @Thomas Pornin ha descritto in modo eloquente, l'OTR per la posta non funziona perché la posta è una forma di comunicazione asincrona mentre il protocollo Diffie-Hellman ha bisogno che entrambe le parti parlino direttamente prima di poter eseguire qualsiasi crittografia.

Se non vuoi cambiare il modo in cui funziona la crittografia, devi cambiare il modo in cui funziona la posta. Ci sono due opzioni:

1. Utilizzare una normale e-mail asincrona per ogni pacchetto di comunicazione che deve essere inviato. Come ha detto @Ross Dargan, OTR è piuttosto "chiacchierone", quindi è necessario scambiare diversi messaggi prima che i dati reali possano essere inviati. Questo potrebbe richiedere del tempo in base a quando il mittente / destinatario è online.
2. Invia solo un tipo di invito per posta, quindi connettiti direttamente al ricevitore e prosegui lungo il normale protocollo OTR-per-IM.

Entrambi i casi potrebbero essere ben nascosti dal client di posta elettronica per comodità. (Gmail mescola già chat e mail nella sua posta in arrivo (ma senza crittografia).)

Entrambi sfidano lo scopo originario della posta elettronica come comunicazione asincrona tra terminali che sono attivi o connessi a una rete solo per un periodo di tempo sconosciuto e breve. Ma se si guarda l'infrastruttura di oggi, questo non si adatta quasi mai. Di solito, sia il mittente che il destinatario (o almeno le loro macchine client) sono attivi e online 24 ore su 24, 7 giorni su 7. Anche se no, il tempo di attesa aggiuntivo è solo una piccola causa di disagio.

Le buone notizie? Entrambe le versioni non si basano su un protocollo modificato né su SMTP né su OTR. È possibile implementare facilmente tutte le modifiche necessarie nei client. Buon codice!

È già stato menzionato ma gli autori di OTR forniscono spiegazioni davvero interessanti nel loro articolo :

However, there is a solution Alice can use in this case, called ring signatures. A digital signature can prove that Alice sent a message. A ring signature extends this concept and can be used to prove that, given a set of people, some member of the set sent the message, but it is impossible to determine which one. So Alice can send her message signed with a ring signature for the set {Alice,Bob} (and encrypted to Bob.) In this case, Bob will be able to verify that it indeed came from Alice (since he knows he did not send it himself), but will not be able to prove this to anyone else, since he can just as easily generate the ring signature himself. Ring signatures have been implemented as an extension to PGP.