E-mail PGP bidirezionale senza pubblicare la chiave / l'indirizzo su un server delle chiavi?

Trasmissione chiave riservata

Devi discriminare tra diversi problemi:

1. Chiavi private di trasmissione

   Questa è la tua sfida principale, su come ottenere la chiave dall'altra parte senza rivelarla al pubblico. Puoi farlo in qualsiasi modo desideri, di cui ti fiderei anche in caso di trasmissione di dati riservati. Se OTR va bene per te, allora è anche per trasmettere le tue chiavi.

   L'invio di chiavi senza l'utilizzo di server chiave è facile come

   gpg --armor --export [key-id] > key.asc     # Send file key.asc to the recipient
   gpg --import key.asc                        # Recipient can import the key
   

2. Verifica della validità delle chiavi

   Questo è un problema completamente disconnesso, che si verifica anche se non trasmette i dati chiave in privato (ad esempio, utilizzando i server delle chiavi). Di solito, questo viene eseguito comunicando l'impronta digitale della chiave (una sorta di somma hash) su un canale sicuro, spesso la comunicazione faccia a faccia.

Se hai già stabilito un canale sicuro e affidabile (come OTR con chiavi verificate), puoi usarlo per fare entrambe le cose: sai che nessuno è in grado di penetrare e l'altro lato è autenticato.

Se ti fidi della tua posta e degli operatori di rete non per manomettere i messaggi di testo in chiaro senza segno (e non di loro), e le agenzie governative non sono un vettore di attacco a cui tieni, un piano la posta di testo potrebbe andar bene per farlo. Se tutto ciò che si vuole fare è impedire agli spammer di ottenere la chiave (che include il proprio indirizzo di posta), è molto probabilmente un modo sufficientemente privato di scambiare le chiavi, basti pensare a chi potrebbe avere accesso al percorso di trasmissione: probabilmente gli spammer non sono tra questi.

Vale la pena?

O meglio: quanto sforzo vale?

Sii consapevole che chiunque sia l'uomo nel mezzo sarà in grado di osservare con chi stai comunicando comunque. Lo spam è un problema con le chiavi sui server a chiave pubblica, ma devi comunque gestirlo. Tenere le chiavi private funziona solo finché nessuno commette un errore; caricare le chiavi sbagliate o anche tutte le chiavi nel keystore locale è detto che accada (e si verifica facilmente).

OpenPGP con la sua infrastruttura server chiave è principalmente progettato per mantenere privati i contenuti della tua comunicazione, garantendo al tempo stesso l'autenticità condividendo chiavi e firme pubbliche. Anche se può essere usato nel modo in cui vorresti che fosse, tieni presente che questo non è uno degli obiettivi principali. Se vuoi utilizzare OpenPGP senza caricare le chiavi, aspettati che diventi pubblico e non fare affidamento su di esso se una chiave pubblica che perde sarebbe un disastro.

Utilizzo di posta elettronica crittografato governativo

And do many privacy-conscious people (like members of law enforcement, such as NSA agents) do this to avoid having their (government) email addresses publically 'outed' by being on public PGP key lists? Maybe they have their own private PGP servers within each organication to take care of that?

Molto probabilmente, semplicemente non usano OpenPGP. Queste sono organizzazioni organizzate centralmente, che sono spesso meglio usare sistemi gerarchici come X.509. E peggio, non sarei troppo sicuro che l'uso di messaggi crittografati end-to-end sia ampiamente diffuso comunque.

Se lo fanno, molto probabilmente useranno le chiavi S / MIME e X.509 insieme a un server delle chiavi interno integrato nel loro database utente. Molto probabilmente non esiste un elenco completo di chiavi / certificati disponibili; ma quando stanno già comunicando con te, molto probabilmente condivideranno il certificato firmando i loro messaggi (in S / MIME, il certificato contenente la chiave pubblica è allegato a qualsiasi messaggio firmato).

Non devi includere il tuo indirizzo email.

Un ID utente di solito consiste in un nome, un commento (spesso omesso) e un indirizzo email, ma questo è non richiesto dalla specifica OpenPGP.

Si noti che gli strumenti per la creazione di chiavi OpenPGP possono richiedere l'inserimento dell'ID utente in qualche modo specifico, però. GnuPG 1.4, ad esempio, richiede un nome con più di 4 caratteri (che non può iniziare con un numero), ma i commenti e l'indirizzo e-mail sono opzionali.

Contra

Non specificare un indirizzo email ha tre possibili svantaggi:

• {a} alcuni partner di comunicazione potrebbero confondersi durante la gestione della chiave. ( Huh, perché manca l'indirizzo e-mail? Di chi è stata la chiave? A quale dei tre John è noto che questa chiave appartiene? )

• {b} Se i gestori di chiavi del client di posta elettronica associano / preselezionano automaticamente le chiavi quando compongono un messaggio di posta elettronica a un nuovo destinatario, ciò ovviamente fallirebbe. ( Accidenti, devo selezionare manualmente la chiave! )

• {c} Alcuni partecipanti al Web of Trust potrebbero non voler firmare la tua chiave se manca un indirizzo email.

Nel tuo scenario, probabilmente nessuno di questi problemi:

• Informazioni su {a}: il tuo partner di comunicazione probabilmente lo capisce e saprà di chi è la chiave (inoltre, potresti usare un nome (nick) che solo il tuo partner conosce / capisce).

• Informazioni su {b}: il tuo partner di comunicazione dovrebbe associare la tua chiave con il tuo indirizzo e-mail al client di posta solo la prima volta, dopo di che il client lo ricorda tipicamente.

• Informazioni su {c}: Non vuoi partecipare al Web of Trust con questa chiave (e anche se, senza il tuo indirizzo email in ogni caso).

Pro

• {A} Potresti persino utilizzare i server con chiave pubblica se l'indirizzo email è la tua unica preoccupazione.

• {B} Se la tua chiave viene pubblicata su un server delle chiavi in qualche modo, il tuo indirizzo email non può / non può perdere.

Penso che questi siano anche dei pro nel tuo scenario:

• su {A}: puoi utilizzare i server delle chiavi che ti semplificano la vita e il tuo partner di comunicazione se modifichi / aggiorni le sottochiavi. Dovresti semplicemente usare l'ID della chiave per trovare la chiave.

• su {B}: alcuni strumenti potrebbero rendere le chiavi di pubblicazione troppo semplici, quindi il tuo partner di comunicazione potrebbe accidentalmente pubblicarlo un giorno.

Verificare che la chiave corretta funzioni esattamente allo stesso modo in cui inseriresti il tuo indirizzo email: devi comunicare con il tuo partner su un canale sicuro per una volta (solo) e confronta le impronte digitali.

Sì, l'invio della chiave nella prima e-mail in chiaro funzionerebbe.

Questo è essenzialmente ciò che la maggior parte delle persone fa quando accetti ciecamente una nuova chiave ssh host.

Anche se non verifichi l'identità dell'altra parte - come dovresti -, prima di inviare dati delicatamente riservati, le scommesse ti fanno comunque bene:

• Forse non ti viene spiato ogni volta. La tua email potrebbe passare attraverso
• Se a un certo punto inizi a essere spiato, gli scambi passati potrebbero essere sicuri.
• Potrebbero non avere il programma disponibile / abilitato per MITM tutti i tuoi scambi di chiavi.
• Non sanno se stai per telefonare immediatamente al destinatario per confermare l'impronta digitale.
• I messaggi a due vie devono essere modificati per un tempo indefinito.
• È possibile verificare l'identità del partner settimane / mesi dopo.
• C'è un periodo di tempo limitato al MITM per il tuo scambio (confronta con la lettura di un archivio email).

A differenza di una lettura passiva dei tuoi messaggi (come l'accesso alla casella di posta del bersaglio), eseguire un MITM su uno scambio di tasti è rumoroso (e probabilmente più illegale) e metterà la vittima in modalità paranoia se scoperto. Quindi, a meno che tu non sia un obiettivo di alto profilo, non credo sarebbe sensato giocherellare a quel livello (potresti essere considerato più importante del previsto, anche se ci sono anche stupidi aggressori).

Quindi sì, lo scambio di chiavi tramite e-mail non crittografate è una soluzione praticabile. Ma fai la tua parte e prova a verificarli.

Attenzione: se hai a che fare con persone non tecniche, molti tecnici e in genere, ti aspetti molte domande "come usare questo?", le persone ti inviano la loro chiave privata con quella pubblica, ecc.

Alcune idee:

Se vuoi scambiare solo messaggi PGP, puoi automaticamente filtrare come spam tutto ciò che non è firmato / crittografato sulla tua chiave. (Problema dello spam)

Poiché l'esistenza dell'email è destinata a essere segreta, puoi utilizzare un indirizzo email casuale come < fingerprint > @domain (solo un pezzo da trasmettere, invece di e-mail + impronta digitale). Il lato positivo, questo costringe il vostro corrispondente a ottenere l'impronta digitale giusta se sta per iniziare la comunicazione. Dal lato con, gli attacchi omografi sono più facili.

Credo che questo sistema sia effettivamente usato da persone [governative] attente alla privacy. Anche la pubblicazione di chiavi / impronte digitali in pagine https è comune.

Per quanto il sistema X.509 possa essere più adatto a tale organizzazione, non penso che lo utilizzeranno. C'è anche la doppiezza se usano OpenPGP per altri corrispondenti. E, naturalmente, un agente segreto in una missione segreta non avrebbe usato una chiave X.509 - o un indirizzo e-mail - che lo identificasse come tale. ;)

PS: Esegui gpg --search nsa.gov per alcune chiavi divertenti pubblicate nel keyserver.