Inoltra segretezza con GnuPG

Question

Inoltra segretezza con GnuPG

#1 da (7 voti)

6

Mi piacerebbe sapere come implementare la sicurezza in avanti usando GnuPG e presumo di aver bisogno di una sorta di scambio di chiavi autenticato. Supponendo che ho già il seguente lavoro:

Alice e Bob hanno entrambi generato i propri normali keypair asimmetrici
Alice ha la chiave pubblica di Bob e Bob ha la chiave pubblica di Alice
Alice e Bob hanno verificato di avere le chiavi corrette e quindi si fidano l'un l'altra
Alice può inviare messaggi crittografati asimmetricamente con la chiave pubblica di Bob e Bob può decrittografarli, leggerli e verificare le firme (e viceversa)

Il problema che vorrei risolvere è che se qualcuno fosse riuscito a intercettare e archiviare un messaggio crittografato dalla scorsa settimana e successivamente a ottenere la corrispondente chiave privata da Alice o Bob, potrebbe decodificare e leggere il messaggio vecchio messaggio. Spero che con una chiave di sessione temporanea (negoziata ma non inviata) ciò non sia più possibile, poiché il messaggio della settimana scorsa sarebbe stato simmetricamente crittografato con una chiave di sessione casuale, e questa chiave di sessione era mai inviato in qualsiasi messaggio.

Credo che ciò di cui ha bisogno è un Authenticated Key Exchange (AKE) come Diffie-Hellman, quindi il mio programma può farlo usando GnuPG come libreria?

Generazione di token casuali adatti
Combinazione di questo token con chiave privata
(il programma è quindi responsabile della memorizzazione di dati temporanei in memoria e della trasmissione di messaggi crittografati e firmati)
Combinazione di ricevuto (token + chiave) dall'altra parte con la propria chiave privata per fornire la chiave di sessione temporanea k
Uso di questo% co_de concordato come chiave di sessione simmetrica

Idealmente questa chiave di sessione non dovrebbe essere aggiunta a nessun portachiavi, e la sua creazione sarebbe molto più rapida di quella di generare una coppia di chiavi asimmetrica.

Confusioni

Secondo le FAQ al link :

“Diffie-Hellman” is what PGP calls the Elgamal encryption algorithm. If your PGP-generated keypair uses a Diffie-Hellman encryption subkey, it will appear in GnuPG as an Elgamal subkey.

ma secondo il manuale link la generazione della chiave per ElGamal produce una coppia di chiavi:

Option 4 creates a single ElGamal keypair usable for both making signatures and performing encryption.

Questo suona come una coppia di chiavi asimmetrica che non è quello che voglio, e suona anche come se fosse aggiunta al portachiavi, che sembra indesiderabile e inefficiente. Quindi sono un po 'confuso su cosa GnuPG intenda per "ElGamal", e non vedo come un protocollo di scambio chiavi possa essere considerato equivalente a un algoritmo di crittografia.

Conclusioni

Grazie alla risposta di Forest qui sotto, capisco che questo non è possibile, anche se sembra che GnuPG sia più che capace di fare la matematica richiesta. L'ho lasciato aperto ancora per un po 'nel caso in cui qualcun altro avesse saputo un modo.

Dovrò esaminare ulteriormente l'OTR, che ovviamente è una domanda separata.

Ho anche realizzato dopo aver posto questa domanda che forse avrei dovuto metterlo in crypto.stackexchange - le mie scuse se metterlo lì sarebbe stato più appropriato. Grazie per i commenti!

key-exchange forward-secrecy gnupg

posta user171587 26.02.2018 - 11:17

fonte

1 risposta

Leggi altre domande sui tag key-exchange forward-secrecy gnupg

Quale codifica potrebbe essere? Sembra simile a base64 [chiuso] Integrità dei dati in PKC

score 7 · Accepted Answer

C'è qualcosa di simile?

In realtà c'è una bozza specifica per farlo, intitolata Estensioni di segretezza per OpenPGP . L'essenza della bozza è che le chiavi temporanee devono essere create per ogni messaggio e cancellate in modo sicuro dopo essere state utilizzate. Questo ha alcuni problemi. Ancora più importante, un'estensione OpenPGP non sarà in grado di garantire che i dati siano rimossi in modo sicuro da un dispositivo di archiviazione. Molti dispositivi di archiviazione non consentiranno la cancellazione dei dati. Questo viene fatto da unità a stato solido come una forma di livellamento dell'usura , con lo scopo di ridurre l'usura su ogni singola area di stoccaggio. Alcuni filesystem impiegano una tecnica per migliorare l'affidabilità in caso di arresti anomali chiamati copy-on-write che ha il effetto collaterale di causare scritture nella stessa posizione per non sovrascrivere i dati precedentemente presenti. Inoltre, molti sistemi eseguono istantanee del loro stato, vanificando lo scopo di cancellare in modo sicuro una chiave.

Che cosa rende la segretezza difficile con PGP?

La differenza principale tra qualcosa come PGP e TLS è che TLS è veloce. Puoi essere sicuro che una stretta di mano verrà completata in un secondo o due. Ciò consente di memorizzare interamente il materiale della chiave temporanea in memoria. Un messaggio crittografato con PGP, d'altra parte, può rimanere non letto per un periodo indefinito, aumentando le possibilità che una chiave venga rubata. La segretezza di inoltro è quindi facile da implementare con sistemi live che iniziano e finiscono lo scambio di chiavi in una singola sessione, ma molto più difficile da implementare su un sistema altamente asincrono in cui non vi è alcuna garanzia che un messaggio possa essere letto velocemente.

Nel complesso, le ragioni principali per cui PGP è molto più difficile da utilizzare con la segretezza in avanti sono:

PGP è interattivo, quindi non puoi tenere le chiavi effimere in memoria solo per una frazione di secondo.
Le chiavi devono essere memorizzate su un dispositivo di memorizzazione non volatile, a quel punto la cancellazione sicura è incerta.

Possibili alternative

L'alternativa più valida che hai adesso è quella di avere delle sottochiavi di crittografia piuttosto brevi. Crea una chiave master longeva, preferibilmente memorizzata su un dispositivo esterno (e quindi resistente al compromesso). Le sottochiavi devono essere conservate per un periodo più breve e revocate dopo un periodo di tempo minimo, ad esempio un mese o una dozzina di messaggi. Quando si revoca una chiave, aggiornare la chiave pubblica per includere le sottochiavi generate di recente. Le persone che comunicano con te dovranno aggiornare regolarmente la loro copia della tua chiave pubblica per comunicare con te. Dovrai essere consapevole di come funziona il tuo sistema per evitare di lasciare tracce di chiavi private precedenti sul tuo dispositivo. Questo potrebbe essere attenuato conservandoli su una smart card diversa, poiché sono progettati per archiviare queste chiavi e spesso possono anche cancellarle in sicurezza in un attimo. GnuPG supporta utilizzando le smart card come fonte di materiale chiave.

Puoi anche utilizzare OTR , che consente comunicazioni crittografate in tempo reale con segretezza in avanti. È un plugin per vari sistemi di messaggistica che crittografa i dati utilizzando lo scambio di chiavi Diffie-Hellman e AES. Attualmente è supportato su varie applicazioni di messaggistica di social media (ad esempio messenger di Facebook), oltre a IRC e XMPP. C'è anche un plugin per Pidgin , un client di chat che supporta un'ampia varietà di protocolli. Qualsiasi protocollo supportato da Pidgin può essere crittografato utilizzando OTR.