30 Kio
GnuPG for Dummies
||||||||||||||
||||||||||||||||
/// \\\
// _ \\
/ (o) _ \
(( ˉ (o) ))
\ UU ˉ /
\ /
\ /\/\/\/\ /
\ U /
\ /
--------
| |
GPG (GnuPG) Breve guida alle principali funzioni da riga di comando per sistemi Linux.
Per gli altri OS (Windows e Mac OSX) che sono proprietari e non ci piacciono, cercate sul uebbe :-P
I N D I C E
- Premessa
- Breve intro sulla crittografia a chive pubblica
- Consigli generali
- Generazione e gestione delle nostre chiavi GnuPG
- Utilizzo delle chiavi GnuPG
- Altri comandi utili per la gestione delle chiavi
1 - Premessa
Questo manualetto fornisce una guida sintetica, da tenere a portata di mano, per effettuare le operazioni di base necessarie all'utilizzo, gestione e manutenzione delle chiavi GnuPG. Per tutto il resto fare riferimento alla documentazione disponibile on-line sulle decine di siti specializzati. Potete partire da qui, da qui per qualche info su come funziona la crittografia a chiave pubblica, o da qui per la lista completa dei comandi. Per farsi un'idea del perché, a volte, è consigliabile cifrare le comunicazioni digitali, consigliamo la lettura della nostra guida di autodifesa digitale disponibile qui.
2 - Breve intro sulla crittografia a chiave pubblica
Una storia di privacy, di messaggi, di cassette e di chiavi...
________
/ /| ____
/_______/ | / \________
| | | ( 0 \
| =O= | | \ /ˉˉˉVˉVˉV/
| | / ˉˉˉˉ
| |/
ˉˉˉˉˉˉˉˉˉ
Alice e Barbara sono due amiche/compagne che condividono esperienze di vita e di lotta. Barbara deve trasferirsi in un'altra città per motivi di lavoro, così decidono di organizzarsi per poter comunicare anche a distanza in modo sicuro.
Alice e Barbara si incontrano irl (fisicamente).
Alice consegna a Barbara una cassetta aperta e vuota, che chiamiamo cassetta_A (immagina una piccola cassaforte a prova di scasso che si chiuda automaticamente chiudendo lo sportello) tenendosi però la chiave per aprirla che chiameremo chiave_A e, contemporaneamente, riceve da Barbara una cassetta aperta e vuota simile alla sua, che chiamiamo cassetta_B, la cui chiave che chiameremo chiave_B resta a Barbara.
Un bel giorno, Barbara si trasferisce nell'altra città.
Barbara vuole mandare un messaggio riservato ad Alice, prende la cassetta_A (quela che le ha dato Alice) scrive il messaggio su un foglietto, lo mette nella cassetta e chiude lo sportello. Da questo momento neanche Barbara può più aprire la cassetta. Barbara si incontra con un'amica, che chiameremo Claudia, che si deve recare nella città dove vive Alice, le affida la cassetta chiedendole di consegnarla ad Alice, sicura del fatto che in nessun modo né Claudia né nessun altro, potrà aprirla e leggerne il contenuto. Quando Alice riceve da Claudia la cassetta_A, la apre con la sua chiave_A che aveva conservato (e che ha solo lei) e può così leggere il messaggio di Barbara.
Questo esempio, che funzionerebbe anche nella vita reale ma con qualche complicazione dovuta all'andare avanti e indietro delle cassette, funziona in realtà benissimo (sin dagli anni '70) nella sua implementazione digitale.
Basta sostituire...
| Nell'esempio delle cassette | > | Nell'implementazione digitale |
|---|---|---|
| cassetta_A | con | chiave pubblica (pub) di Alice |
| cassetta_B | con | chiave pubblica (pub) di Barbara |
| chiave_A | con | chiave privata (sec) di Alice |
| chiave_B | con | chiave privata (sec) di Barbara |
| Claudia | con | email service provider |
... ed abbiamo un sistema di crittografia a chiave pubblica, ovvero:
Alice e Barbara si scambiano le chiavi pubbliche (che è molto più comodo che scambiarsi delle cassette).
Quando Alice invia una e-mail a Barbara la crittografa con la chiave pubblica di Barbara.
Quando Barbara riceve la e-mail la può decrittografare con la sua chiave privata.
Chiunque stia nel mezzo del percorso che fa la mail tra Alice e Barbara (normalmente uno o più service provider) non può, non avendo la chiave privata di Barbara, leggerne il contenuto.
Boh, così dovrebbe essere abbastanza chiaro, eh. Se non bastasse... -▸
3 - Consigli generali
- Utilizza sempre PASSWORD ROBUSTE -▸ per gli account di posta (e non solo) e passphrases altrettanto robuste per proteggere le chiavi.
- Ricordati che se usate le funzioni qui descritte su una rete telnet -▸, per un malintenzionato sarà relativamente facile spiare i tuoi messaggi!
- Fatti SUBITO almeno una copia (più avanti capirai come farlo) delle chiavi (pub e sec) e del certificato di revoca in un posto sicuro, diverso dal pc che normalmente usi.
- Visto che non è semplice per tutti, memorizzare differenti password e passphrases, ti consiglio di utilizzare un password manager (ad es. keepassxc -▸). Naturalmente la masterpassword del password manager dovrà essere robusta e soprattutto... fai in modo di non dimenticarla!!! Una buona regola è avere più copie del file cifrato del password manager archiviate in posti sicuri, con la tecnologia... non si sa mai!
4 - Generazione e gestione delle chiavi GnuPG
Apriamo il Terminale della nostra distro Linux ed iniziamo con un pò di pratica
>_
Negli esempi che seguono, immagina che la tua mail sia "mia@mail.org" e che hai un'amica che si chiama Lea con la quale vuoi comunicare in modo riservato. La mail di Lea è lea@mail.org.
Lea, che è una tosta (e sta sempre un passo avanti a noi!) ha già una chiave GnuGP collegata alla sua mail, la cui fingerprint (cioè l'impronta digitale della sua chiave) è "5678EFGH5678EFGH5678EFGH5678EFGH5678EFGH".
I comandi che seguono quindi sono basati su questo esempio, tu dovrai sostituire tutte le parti contenute tra " " con i tuoi dati reali, per esempio...
il comando:
>_ gpg --output "mia"-revoke.asc --gen-revoke "mia@mail.org"
poterbbe diventare:
>_ gpg --output alice-revoke.asc --gen-revoke alice@bruttocarattere.org
4.1 - Generiamo la nostra chiave GPG completa
[completa significa: chiave pubblica (pub) + chiave privata (sec) + certificato di revoca]
>_ gpg --full-generate-key
Verrà richiesto di selezionare un tipo di crittografia da un menu. A meno che non si abbia una buona ragione per non farlo, digitare '1' e premere Invio. L'opzione 1 di default, attiva la generazione di sottochiavi RSA che permettono non solo di firmare/crittografare le e-mail, ma anche i files.
È necessario inoltre, scegliere una lunghezza in bit (tra 1024 e 4096) per le chiavi di crittografia, o premendo Invio si accetta l'impostazione predefinita visualizzata. Più la chiave è lunga, più è difficile da decifrare in caso di tentativo di attacco.
È necessario indicare la durata della chiave. Se si imposta '0' avrà durata illimitata. Se si imposta ad es. '1y' durerà un anno. Leggere le indicazioni e scegliere la durata che si desidera. Confermare la scelta con 'Y'.
Digitare quindi il nome che vogliamo dare alla chiave (es. il nostro nome o nickname) e l'indirizzo e-mail a cui la chiave sarà associata.
È possibile aggiungere un commento (facoltativo).
Verrà richiesto di immettere (2 volte) la passphrase.
Avremo bisogno della passphrase ogni volta che lavoriamo con le chiavi, quindi assicuriamoci di !!! NON DIMENTICARLA !!!.
Dopo aver inserito la passphrase che abbiamo scelto, clicchiamo sul pulsante 'OK'.
La chiave sarà generata, salvata nel keyring (portachiavi) del nostro pc e verrà restituito il prompt dei comandi.
4.2 - Generiamo una copia del certificato di revoca (utile per archiviazione)
>_ gpg --output "mia"-revoke.asc --gen-revoke "mia@mail.org"
Ci verrà chiesto il motivo della richiesta del certificato di revoca, se non c'è uno dei motivi elencati scegli 0 e prosegui.
Sarà così generato il file "mia-revoke.asc"
4.2.1 - Mettiamo in sicurezza il certificato di revoca
Se condividiamo il pc con altre persone o semplicemente perché questo ci fa dormire più tranquilli, possiamo cambiare i permessi di accesso al file del certificato di revoca impedendone, di fatto, l'utilizzo ad altri utenti mediante il comando chmod -▸ Rimuoviamo dal certificato tutte le autorizzazioni oltre alle nostre.
>_ chmod 600 ~/"mia"-revoke.asc
4.2.2 - Esportiamo la nostra chiave PRIVATA (sec) in un file utilizzando l'ID della chiave
Ad esempio, ipotizziamo che la nostra chiave abbia questa fingerprint "1234 ABCD 1234 ABCD 1234 ABCD 1234 ABCD 1234 ABCD" e quindi l'ID sia 1234ABCD (short key ID) o 1234ABCD1234ABCD (long key ID) [l'ID della chiave è rappresentato dalle ultime 8 (short) o 16 (long) cifre della fingerprint]
Attenzione: la chiave privata/segreta dobbiamo averla solo noi (non va data MAI a nessunx) e non deve essere pubblicata. Deve essere conservata in modo sicuro come la passphrase, ad esempio su un dispositivo (HD o chiavetta) crittografato. Ed è una buona regola averne più di una copia, su dispositivi (sicuri) ed in luoghi diversi.
>_ gpg --export-secret-keys --armor "1234ABCD1234ABCD" "secret".asc
4.2.3 - Esportiamo la chiave PUBBLICA (pub) in un file
Per condividere la chiave come file, è necessario esportarla dall'archivio chiavi locale gpg (portachiavi).
A tale scopo, utilizzeremo l'opzione --export, che deve essere seguita dall'indirizzo e-mail associato alla chiave.
L'opzione --output deve essere seguita dal nome del file in cui si desidera esportare la chiave.
L'opzione --armor consente a gpg di generare un output con armatura ASCII anziché un file binario.
>_ gpg --output ~/"mia.key" --armor --export "mia@mail.org"
4.2.3.1 - Ora guardiamo il contenuto del file esportato
>_ less "mia.key"
per uscire dalla visualizzazione digitare 'q'.
4.3 - Condividiamo la nostra chiave pubblica
4.3.1 - Esportiamo la chiave pubblica su un key-server remoto utilizzando la fingerprint della nostra chiave
>_ gpg --send-keys --keyserver hkp://pgp.mit.edu "1234ABCD1234ABCD1234ABCD1234ABCD1234ABCD"
(la fingerprint è l'impronta digitale della chiave. Per saperne di più -▸)
4.4 - Importiamo le chiavi pubbliche dei nostri contatti (es. della nostra amica Lea)
4.4.1 - Se Lea ci ha già passato la sua chiave in un file (es. Lea.key)
>_ gpg --import "Lea.key"
4.4.2 - Se invece dobbiamo cercarla su un key-server remoto (ce ne sono tanti qui ne citiamo solo uno come esempio) utilizziamo il suo indirizzo mail associato alla chiave
>_ gpg --keyserver hkp://pgp.mit.edu --search-keys "lea@mail.org"
\\\\\\\\\\\\\\\\\\ CORRETTO FINO QUI \\\\\\\\\\\\\\\\\\\\\\
4.3.3 - Oppure la cerchiamo su un key-server remoto tramite la fingerprint
>_ gpg --recv-keys "5678EFGH5678EFGH5678EFGH5678EFGH5678EFGH"
4.4) Verifichiamo e firmiamo la chiave di Lea:
4.4.1) verificare la fingerprint (per confrontarla con quella che ci ha comunicato Lea) ˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍ | | | >_ gpg --fingerprint lea@mail.org | | | ˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉ 4.4.2) Firmiamo la chiave (solo quando siamo certi che appartenga realmente a Lea)
L'impronta digitale di una chiave va verificata con il possessore di quella chiave. Ciò può essere fatto di persona (consigliato), per telefono o attraverso un qualsiasi altro mezzo con il quale sia possibile garantire che si sta comunicando con il vero possessore della chiave. Se l'impronta digitale è la stessa che il possessore della chiave detiene, allora si può essere sicuri della sua autenticità. ˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍ | | | >_ gpg --sign-key lea@mail.org | | | ˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉ
//--- [ 5 - Utilizzo delle chiavi GnuPG ] ---\
/ˉˉˉˉˉˉˉˉ\
/ \
_______________ / \
|\ /| |ˉˉˉˉˉˉˉˉˉˉˉˉˉˉ|
| \ ENCRYPT / | o | |
| \ / | - - - - - - - - - /|\ - - - - - - - - > | DECRYPT |
| ˉˉˉˉˉˉˉ | / \ | |
| | | |
ˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉ ˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉ
Ora che Lea può avere la nostra chiave pubblica (perché le abbiamo passato il file mia.key o perché se l'è procurata da un key-server remoto) possiamo iniziare a scambiarci mail in modo sicuro, ma come?
5.1) Utilizziamo le chiavi GnuPG
Il modo più semplice (se volevo fare il figo avrei scritto "user-friendly") è quello di utilizzarle tramite un client di posta tipo Thunderbird -▸ che richiede l'installazione del add-ons Enigmail -▸, o Evolution -▸. In entrambi i casi questi tools hanno già nei loro menu, le funzioni che ci permettono di firmare e/o cifrare le mail che inviamo e decifrare quelle che riceviamo, ovviamente solo se abbiamo nel nostro portachiavi le chiavi pubbliche dei nostri contatti e la nostra chiave privata.
Molto brevemente: Se usate Thunderbird+Enigmail avrete una voce "Enigmail" nella barra del Menu con tutte le opzioni disponibili (firmare/crittografare un messaggio, allegarvi la vostra chiave pubblica più altre funzioni per la generazione e la gestione delle chiavi) Se usate "Evolution" quando componete un messaggio, cliccando sul menu "Opzioni" si ha la possibilità di firmare/cifrare, in ricezione di un messaggio cifrato avrete la possibilità di decifrarlo. Il loro utilizzo è comunque molto semplice ed intuitivo, quindi non stiamo a dilungarci troppo. Per una guida più completa per Thunderbird + Enigmail vedi -▸, per Evolution vedi -▸.
Un altro tool disponibile per la gestione delle chiavi (ma non delle email) sui sistemi Linux è Seahorse -▸
per installarlo (se non già fatto) ˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍ | | | >_ sudo apt install seahorse | | | ˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉ lo si lancia da riga di comando ˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍ | | | >_ seahorse | | | ˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉ e permette di eseguire con l'ausilio di un'interfaccia grafica, le operazioni più comuni compresa la sincronizzazione del proprio keyring (il portachiavi) con i key-server remoti.
//--- [ 6 - Altri comandi utili per la gestione delle chiavi ] ---\
- Visualizziamo la lista delle chiavi sul nostro pc, cioè il contenuto del portachiavi
1.1) per vedere la lista delle chiavi pubbliche (pub) ˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍ | | | >_ gpg -k | | | ˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉ 1.2) per vedere la lista delle chiavi private (sec) ˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍ | | | >_ gpg -K | | | ˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉ
- Aggiorniamo periodicamente le chiavi
Periodicamente, è possibile chiedere a gpg di controllare le chiavi in uso rispetto ad un key-server e di aggiornare le chiavi modificate. Lo si può fare ogni pochi mesi o quando si riceve una chiave da un nuovo contatto.
L'opzione --refresh-keys consente a gpg di eseguire il controllo. L'opzione --keyserver deve essere seguita dal key-server scelto. I key-server si sincronizzano tra loro periodicamente, pertanto la scelta di quale utilizzare non è così importante. Il key-server hkp://pgp.mit.edu è comunque sempre una buona scelta iniziale. ˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍ | | | >_ gpg --keyserver hkp://pgp.mit.edu --refresh-keys | | | ˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉ
-
Applichiamo la chiave ad un altro acount Quando abbiamo creato le chiavi GnuGP, le abbiamo associate ad un accont (indirizzo e-mail). Molti però possiedono più di un indirizzo e-mail, ad esempio: uno privato, uno per il lavoro e così via. Per evitare di creare chiavi diverse per ogni indirizzo e poi dovrele gestire, è bene sapere che una chiave può essere associata a più indirizzi mail, vediamo come.
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX gpg --edit-key your.email@your-domain.com
You are now on the GPG command line. To add a mail identity simply type “adduid” and hit enter. You will then be prompted for the following:
Real name: You probably want to enter your real name here, but you might have a pseudonym which you want to add for convenience. Don’t do this if you don’t want the pseudonym to be associated with your real name though! I actually have two PGP keys, the other for my “alternative community” pseudonym.
Email address: The new email address that you’re adding to your key.
Comment: I generally enter a URL here and that seems to be a convention. Most of my email identities are associated with a different organisation or Web site.
Next check the details and if you’re happy hit “o” (okay) then .
For some reason it shows the new identity as untrusted. I don’t think this step is necessary, but I also typed “trust” and selected “ultimate” (press 5 and hit enter) just to be sure. You should only ever trust yourself ultimately by the way! Even my brother Nick only gets “full” trust from me for example.
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
- Revochiamo una chiave
Potremmo accorgerci, o anche solo avere il dubbio, che la nostra chiave sia stata compromessa. In questi casi è bene revocare la chiave affinché nessuno possa utilizz16arla spacciandosi per noi. Ricordiamoci che oltre alla nostra privacy, dobbiamo sempre pensare anche a salvaguardare la rete di persone che ci ha dato fiducia. ˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍ | | | >_ gpg --import -revoke.asc | | | ˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉ Una volta revocata la chiave localmente, è necessario inviare il certificato revocato a un keyserver, indipendentemente dal fatto che la chiave sia stata originariamente rilasciata in questo modo. La distribuzione tramite un server consente ad altri utenti di rendersi rapidamente conto che la chiave è stata compromessa.
- Esportiamo la revoca in un key-server ˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍˍ | | | >_ gpg --keyserver hkp://pgp.mit.edu --send mia@mail.org | | | ˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉ
Bah, possiamo fermarci qui per ora.
Ah, no, ma c'è anche un'altra cosa utile che potete fare con le chiavi GnuPG, cioè crittografare i files.
//--- [ Crittografiamo/decrittografiamo file per scambi via mail ] ---\
- Pensiamo di voler crittografare un file che contiene informazioni riservate ed inviarlo ad un altra persona (es. Lea). Il file, nell'esempio, si chiama "prova.txt"
Nell'esempio vogliamo crittografare un file che si chiama "prova.txt" e vogliamo inviarlo alla nostra amica Lea. L'opzione --encrypt consente a gpg di crittografare il file, mentre l'opzione --sign le consente di firmare il file con i dettagli. L'opzione --armor consente a gpg di creare un file ASCII. L'opzione -r (destinatario) deve essere seguita dall'indirizzo e-mail della persona a cui si sta inviando il file.
gpg --encrypt --sign --armor -r <lea@mail.org> <prova.txt>
1.1) Il file viene generato con lo stesso nome dell'originale, ma con ".asc" aggiunto al nome del file. Diamo un'occhiata a cosa contiene.
less <prova.txt.asc>
Il file è del tutto illeggibile e può essere decrittografato solo da un utente che possiede tua chiave pubblica e la chiave privata di Lea (quindi solo da lei). Ora possiamo inviare il file a Lea fiduciosi che nessun altro possa decifrarlo, perchè solo Lea possiede, oltre alla nostra chiave pubblica, la sua chiave privata.
- Decrittografiamo un file che riceviamo via mail
Lea ci ha inviato una risposta. Si trova in un file crittografato denominato "testo.asc". Possiamo decrittografarlo molto facilmente utilizzando l'opzione decrypt. L'output verrà reindirizzato in un altro file chiamato "messaggio.txt".
2.1) Non dobbiamo dire a gpg da chi proviene il file. Questa informazione è già presente nel contenuto crittografato del file.
gpg --decrypt <testo.asc> <messaggio.txt>
2.2) Ora esaminiamo il contenuto file "messaggio.txt"
less <messaggio.txt>
//--- [ Spostiamo (privatamente) le nostre chiavi GnuPG da un pc ad un altro ] ---\
Per diversi motivi, potremmo aver bisogno di spostare le nostre chiavi da un computer ad un altro. Per la chiave pubblica, non ci sono problemi essendo appunto pubblica e da divulgare. Spostare la chiave privata invece dovrebbe essere fatto senza lascire tracce della stessa sugli eventuali dispositivi (es. chiavetta usb) utilizzati per il trasferimento. Assolutamente da evitare di far transitare la propria chiave privata su servizi di cloud-sharing, anche se gestiti da persone o gruppi di cui ci fidiamo. Un modo che ci sentiamo di consigliare è questo.
Questo metodo consente di esportare insieme chiavi pubbliche e private, in modo che possano essere facilmente importate e con il minimo di dati segreti scritti su disco.
-
Find out the keyid of the key you wish to export. You can get this from the output of
gpg -K
Note that the capital K is important so that it lists secret rather than public keys.
-
First, export the public key. This is of course public info, so no worries about security here
gpg --output pubkey.gpg --export {KEYID} -
Now, in one fluid step, we will export the secret key, combine it into one file with the public key, and then encrypt it for transfer
gpg --output - --export-secret-key {KEYID} |\ cat pubkey.gpg - |\ gpg --armor --output keys.asc --symmetric --cipher-algo AES256 -
You will be prompted for a passphrase during this, this is the passphrase just for this temporary encryption for transfer. So use a good passphrase for security, and remember that passphrase! Now, transfer the keys.asc file to the new computer or wherever. Because it’s encrypted you could technically do this over the internet and it should still be secure, but I would suggest not using the internet for added security. When I last did this I just used a normal flash drive.
-
On the new computer, we need to import the keys from the file. So, run this command to unpack and then import the keys (using pipes again)
gpg --no-use-agent --output - keys.asc | gpg --import -
And that, should be, that.
Made with ♥ by underscore_to hacklab
da qui da cancellare!!! vedere qua e provare i comandi: [https://fedoraproject.org/wiki/Creating_GPG_Keys] fonte https://www.howtogeek.com/427982/how-to-encrypt-and-decrypt-files-with-gpg-on-linux/