FAQ di GnuPG

Versione: 1.6.3
Ultima modifica: Jul 30, 2003
Curatore: David D. Scribner, <faq 'at' gnupg.org>

Questa è la GnuPG FAQ. L'ultima versione HTML è disponibile qui.

L'indice è generato automaticamente, quindi potrebbero esserci errori: è possibile che non tutte le domande siano nella sezione in cui dovrebbero essere. Sono benvenuti suggerimenti su come migliorare la struttura di questa FAQ.

Si prega di spedire aggiunte e correzioni al curatore. Ancora meglio se potete fornire anche le risposte alle nuove domande: il vostro aiuto è molto apprezzato!

Evitate di inviare messaggi come "Questa dovrebbe essere una FAQ: qual è la risposta?". Se una domanda non è mai stata posta prima, non è una FAQ. In questi casi, provate a cercare negli archivi della mailing-list.

1. DOMANDE GENERALI

1.1) Cos'è GnuPG?

GnuPG sta per GNU Privacy Guard ed è lo strumento GNU per comunicare e immagazzinare dati in modo sicuro. Può essere usato per cifrare dati e per creare firme digitali. Include funzioni avanzate per la gestione delle chiavi e rispetta lo standard internet OpenPGP, descritto nella RFC 2440. È inoltre progettato per essere compatibile con PGP della NAI.

1.2) GnuPG è compatibile con PGP?

In generale sì. Sia GnuPG che le nuove versioni di PGP dovrebbero implementare lo standard OpenPGP, ma rimangono alcuni problemi di interoperabilità. Si veda la domanda 5.1 per i dettagli.

1.3) GnuPG è liberamente utilizzabile per uso personale o commerciale?

Sì. GnuPG fa parte della famiglia di strumenti e applicazioni GNU, realizzate e distribuite in accordo con la Licenza Pubblica Generica (GPL) della Free Software Foundation (FSF). Quindi il software è liberamente copiabile, modificabile e distribuibile secondo i termini di questa licenza. Per maggiori informazioni, si legga il file COPYING che accompagna il programma.

1.4) Quali convenzioni sono usate in questa FAQ?

Sebbene GnuPG sia sviluppato per vari sistemi operativi (spesso in parallelo), le convenzioni usate in questa FAQ riflettono un ambiente shell UNIX. Per gli utenti Win32, i riferimenti al prompt della shell ("$") vanno interpretati come un prompt dei comandi (">"), i nomi delle directory separati da una barra obliqua ("/") vanno interpretati come separati da una barra obliqua inversa ("\") e una tilde ("~") rappresenta la directory "home" di un utente (si veda la domanda 4.18 per un esempio).

Alcune linee di comando presentate in questa FAQ sono troppo lunghe per essere visualizzate correttamente da alcuni browser usati per leggere la versione html di questo file e sono state divise in due o più linee. In questi casi, si ricordi di inserire l'intera serie di comandi su una linea unica, altrimenti il comando produrrà errori, o quantomeno non produrrà il risultato desiderato.

Si tenga presente che questa FAQ contiene informazioni che possono non essere valide per qualche versione particolare del programma, visto che vengono continuamente aggiunte caratteristiche e correzioni di bug (per i cambiamenti degni di nota tra le versioni del programma, si faccia riferimento al file NEWS incluso nei sorgenti o nel pacchetto). Un punto da tenere presente è che dalla versione 1.1.92 di GnuPG, il file che contiene le impostazioni e le opzioni dell'utente è stato rinominato da "options" a "gpg.conf". Le informazioni che nella FAQ si riferiscono al file "options", in molti casi sono valide anche per il nuovo file "gpg.conf". Si veda la domanda 5.8 per i dettagli.

2. FONTI di INFORMAZIONE

2.1) Dove posso trovare altre informazioni su GnuPG?

Risorse in linea:

• La pagina della documentazione si trova su <http://www.gnupg.org/documentation/>. Si può dare un'occhiata anche agli HOWTO e al GNU Privacy Handbook (Manuale GNU sulla Privacy, disponibile in inglese, spagnolo e russo), che fornisce una guida utente dettagliata per GnuPG. È disponibile anche un documento che spiega la migrazione da PGP 2.x a GnuPG.

• Su <http://www.gnupg.org/documentation/mailing-lists.html> si trova un archivio in linea delle mailing list di GnuPG. La più interessante per gli utenti del programma dovrebbe essere gnupg-users, mentre si può usare gnupg-devel per mettersi in contatto con gli sviluppatori.

  Inoltre, è possibile effettuare richerche negli archivi di MARC, ad es.:
  gnupg-users: <http://marc.theaimsgroup.com/?l=gnupg-users&r=1&w=2>
  gnupg-devel: <http://marc.theaimsgroup.com/?l=gnupg-devel&r=1&w=2>
  

  PER FAVORE: Prima di scrivere in una lista, si legga questa FAQ e la documentazione disponibile. Inoltre si cerchi negli archivi di lista: può darsi che la domanda sia già stata discussa. In questo modo sarà più facile concentrarsi sui problemi che non sono ancora stati risolti.

• La distribuzione dei sorgenti di GnuPG contiene una directory:
  ./doc

  che contiene documentazione supplementare (che interesserà più gli hacker che gli utenti comuni).

2.2) Dove trovo GnuPG?

È possibile scaricare GNU Privacy Guard dal suo server FTP principale <ftp://ftp.gnupg.org/gcrypt/> o da uno dei mirror:

<http://www.gnupg.org/download/mirrors.html>

La versione stabile attuale è la 1.2.2. È consigliabile aggiornare a questa versione, visto che include caratteristiche supplementari, funzioni e correzioni di sicurezza che potrebbero non esserci nelle versioni precedenti.

3. INSTALLAZIONE

3.1) Su quali sistemi operativi funziona GnuPG?

Dovrebbe funzionare su tutte le versioni di Unix, Windows (incluso Windows NT/2000) e Macintosh OS/X. Una lista dei SO pienamente supportati è disponibile su:

<http://www.gnupg.org/download/supported_systems.html>

3.2) Quale generatore di dati casuali dovrei usare?

Dei "buoni" numeri casuali sono cruciali per la sicurezza della cifratura. I diversi sistemi operativi forniscono una varietà di dati casuali di qualità più o meno buona. Linux e *BSD forniscono dati casuali generati dal kernel attraverso /dev/random; questa dovrebbe essere la scelta da preferire su questi sistemi. Anche gli utenti di Solaris con installato il pacchetto SUNWski hanno un /dev/random. In questi casi, si usi l'opzione di configure:

Inoltre, esiste anche il generatore casuale per il kernel di Andi Maier <http://www.cosy.sbg.ac.at/~andi/SUNrand/>, ma è ancora in fase beta. Lo si usi a proprio rischio e pericolo!

Su altri sistemi, l'Entropy Gathering Daemon (EGD) è una buona scelta. Si tratta di un demone Perl che controlla l'attività del sistema e la trasforma in dati casuali. Per avere EGD, si veda la pagina <http://www.gnupg.org/download/>. In questo caso si usi:

Se le opzioni di cui sopra non funzionano, è possibile usare il generatore di numeri casuali "unix", che è molto lento e andrebbe evitato. La qualità dei numeri casuali generati non è molto buona, quindi non lo si usi per cifrare dati importanti.

3.3) Come si può includere il supporto per RSA e IDEA?

RSA è incluso in GnuPG dalla versione 1.0.3.

La distribuzione ufficiale di GnuPG non contiene IDEA a causa di una limitazione di brevetto. Il brevetto non scadrà prima del 2007, quindi non si aspetti un supporto ufficiale prima di quella data.

In ogni caso, c'è un modulo non ufficiale per includerlo anche nelle versioni precedenti di GnuPG. È disponibile su <ftp://ftp.gnupg.dk/pub/contrib-dk/>. Si cerchino i file:

 idea.c.gz        (modulo c)
 idea.c.gz.sig    (file di firma)

 ideadll.zip      (modulo c e dll win32)
 ideadll.zip.sig  (file di firma)

Le istruzioni di compilazione si trovano nelle intestazioni di questi file. Quindi si dovrà aggiungere la seguente linea al file ~/.gnupg/gpg.conf o ~/.gnupg/options:

4. USO

4.1) Qual è la dimensione raccomandata per le chiavi?

1024 bit per le firme DSA; anche per le semplici firme ElGamal. È sufficiente, visto che se la dimensione della chiave supera i 1024 bit, probabilmente l'anello più debole del sistema diventa la dimensione dell'hash.

Le chiavi di cifratura possono essere più grandi, ma allora occorre controllare l'impronta digitale di queste chiavi con:

Per quanto riguarda gli algoritmi di cifratura, si dovrebbero usare quelli predefiniti (ossia firma DSA e cifratura ElGamal). Una chiave di firma ElGamal ha i seguenti svantaggi: produce firme più grandi, è difficile crearne una che resista agli attacchi che possono avvenire nel mondo reale, non si guadagna sicurezza rispetto a DSA e potrebbero esserci problemi di compatibilità con alcune versioni di PGP. Questo metodo di firma fu introdotto perché all'epoca non era chiaro se esistessero brevetti su DSA.

4.2) Perché alcune volte si impiega così tanto tempo per creare le chiavi?

Il problema sta nel fatto che occorrono molti byte casuali e per generarli occorre raccogliere alcuni dati casuali (su Linux si usa il dispositivo /dev/random). In effetti non è facile riempire il buffer di entropia di Linux; parlandone con Ted Ts'o mi è stato suggerito che il miglior modo per riempire il buffer è di usare la tastiera. La sicurezza ha il suo prezzo. Quello che faccio io è premere molte volte i tasti shift, control, alt e caps lock, visto che non generano caratteri sullo schermo. In questo modo si può accelerare la generazione delle chiavi (è la stesso metodo che si usa con PGP2).

Un altro problema potrebbe essere costituito da altri programmi che usano byte casuali (ad esempio un demone che legge da /dev/random).

4.3) E si impiega davvero tanto tempo facendolo su un sistema remoto. Perché?

Non fatelo per nessun motivo! Non si dovrebbe mai creare una chiave o anche solo usare GnuPG su un sistema remoto, perché quasi certamente non si avrà il controllo fisico sul proprio portachiavi privato (che nella maggior parte dei casi è vulnerabile ad attacchi avanzati basati su dizionari). È fortemente consigliato creare chiavi solo su computer locali (un portatile non connesso è probabilmente la scelta migliore) e se si ha necessità di farlo su un computer connesso (so che prima o poi capita a tutti), si faccia in modo perlomeno di avere una buona password sia per il proprio account che per la chiave privata, oltre che fiducia nel proprio amministratore di sistema.

Quando uso GnuPG su un sistema remoto via ssh (non ho Alpha qui) ;-) ho lo stesso problema. Ci vuole *molto* tempo per creare le chiavi, per cui uso un'opzione speciale, --quick-random, per generare chiavi non sicure, utili solo per alcune prove.

4.4) Che differenza c'è tra opzioni e comandi?

Con 'gpg --help' si ottengono due liste separate. La prima è una lista di comandi. La seconda una lista di opzioni. Ogni volta che si usa GPG, bisogna scegliere esattamente un comando (con un'eccezione, si veda oltre), mentre si può scegliere una o più opzioni. Il comando, solo per convenzione, andrebbe alla fine della lista degli argomenti, dopo tutte le opzioni. Se il comando richiede un file (tutti quelli di base lo fanno), il nome del file deve essere dato per ultimo. Quindi il modo basilare per usare gpg è:

Alcune opzioni richiedono argomenti. Per esempio, l'opzione --output (che può essere abbreviata con -o) è un'opzione che richiede un nome di file. L'argomento dell'opzione deve seguire immediatamente l'opzione stessa, altrimenti gpg non sa a quale opzione si riferisce l'argomento. Essendo un'opzione, --output e il suo nome di file devono precedere il comando. L'opzione --recipient (-r) richiede un nome o un keyID per cui cifrare il messaggio, che devono seguire immediatamente l'opzione -r. Il comando --encrypt (o -e) segue dopo tutte le opzioni ed è seguito dal file che si vuole cifrare. Quindi in questo esempio, la linea di comando da inviare sarebbe:

Scrivendo le opzioni per esteso, il tutto è più facile da leggere:

Se si sta creando un file con l'estensione ".txt", probabilmente si vorrà che il file contenga testo con armatura ASCII (non caratteri binari), quindi occorre specificare anche l'opzione --armor (-a), che non richiede alcun argomento:

Ponendo le parti opzionali tra parentesi quadre, tutto diventa un po' più chiaro:

Le parti opzionali possono essere riordinate a piacere:

Se il nome di un file inizia per un trattino (ad es. "-a.txt"), GnuPG lo interpreta come un'opzione e se ne lamenterà. Per evitare questo, si dovrà usare "./-a.txt", oppure indicare la fine delle opzioni e dei comandi con due trattini: "-- -a.txt".

L'eccezione alla regola dell'usare solo un comando: firmare e cifrare al tempo stesso. In questo caso è possibile combinare entrambi i comandi, come in:

4.5) Non riesco a cancellare uno user ID sul portachiavi privato perché è già stato cancellato dal portachiavi pubblico. Come posso fare?

Poiché è possibile selezionare gli user ID solo dal portachiavi pubblico, non c'è un modo diretto per farlo. Comunque non è neanche troppo complicato: occorre creare un nuovo user ID con lo stesso esatto nome e si vedranno comparire nel portachiavi privato due user ID identici. A questo punto si selezioni questo user ID e lo si cancelli. Entrambi gli user ID verranno cancellati dal portachiavi privato.

4.6) Non riesco a cancellare la mia chiave privata perché la chiave pubblica è sparita: cosa faccio?

Quando si seleziona una chiave, viene fatta una ricerca solo sul portachiavi pubblico, quindi non è possibile selezionare una chiave privata senza avere la chiave pubblica. Normalmente non dovrebbe mai accadere di perdere la chiave pubblica e conservare quella privata, ma la realtà è diversa e GnuPG possiede un metodo per far fronte a questa situazione: semplicemente, per specificare la chiave da cancellare, si usi il keyID lungo, che si ottiene con l'opzione --with-colons (è il quinto campo nelle linee che cominciano con "sec").

Se invece avete perso la chiave pubblica e volete ricrearla per continuare ad usarla con la chiave privata, potete usare gpgsplit, come spiegato in dettaglio nella domanda 4.21.

4.7) Cosa sono la fiducia, la validità e la fiducia nel proprietario?

GnuPG usa il termine "fiducia nel proprietario" (ownertrust), invece che "fiducia" (trust) per rendere chiaro che si tratta del valore assegnato a una chiave per esprimere quanta fiducia si ha nel proprietario di quella chiave, per quanto riguarda la firma (e quindi la presentazione) di altre chiavi. La "validità", o fiducia calcolata, è un valore che indica quanto GnuPG consideri una chiave valida, ossia effettivamente appartenente alla persona che afferma di esserne il proprietario. Per maggiori informazioni sui valori di fiducia, si veda il capitolo "La rete di fiducia" ("The Web of Trust") del GNU Privacy Handbook.

4.8) Come firmo un file di patch?

Si usi "gpg --clearsign --not-dash-escaped ...". Il problema di --clearsign è che tutte le linee che iniziano con un trattino vengono protette con "- "; ovviamente diff produce molte linee che iniziano con un trattino, e questa protezione non fa molto bene a patch ;-). Per firmare un file di patch in modo da poterlo usare senza dover rimuovere la firma in chiaro, occorre firmarlo usando l'opzione speciale --not-dash-escaped, in modo che non siano generate le sequenze di escape aggiuntive. File di questo tipo non vanno mai spediti per posta elettronica, perché i programmi di posta elettronica potrebbero non preservarne l'integrità. Se volete spedire un file, potete includerlo o allegarlo a un messaggio di posta elettronica e firmare quest'ultimo.

4.9) Dov'è l'opzione "encrypt-to-self"?

Usate "--encrypt-to vostro_keyID". Potete usare questa opzione più volte. Per disabilitare temporaneamente l'uso di questa chiave aggiuntiva, potete usare l'opzione "--no-encrypt-to".

4.10) Come posso liberarmi delle intestazioni con Version e Comment nei messaggi con armatura ASCII?

Usa "--no-version --comment ''". Si noti che la linea vuota lasciata è richiesta dal protocollo.

4.11) Cosa significa "You are using the xxxx character set." ("Stai usando il set di caratteri xxxx")?

Questo messaggio viene stampato quando occorre mappare a UTF-8. Occorre assicurarsi che l'insieme di caratteri usato sia quello attivato sul sistema. Visto che "iso-8859-1" è il set di caratteri più usato, è quello predefinito. È possibile cambiare il set di caratteri con l'opzione "--charset". È importante che il set di caratteri in uso sul sistema corrisponda a quello mostrato; in caso contrario, si usi il semplice ASCII a 7 bit e non occorrerà nessuna mappatura.

4.12) Come è possibile ricavare la lista dei key ID usati per cifrare un messaggio?

4.13) Non riesco a decifrare i file cifrati simmetricamente (-c) con una versione di GnuPG precedente alla 1.0.1.

C'era un bug nelle versioni di GnuPG precedenti alla 1.0.1, che riguardava i file cifrati simmetricamente con 3DES o Twofish (che non sono mai stati metodi predefiniti). Il bug è stato corretto, ma per decifrare i vecchi file occorre usare gpg con l'opzione "--emulate-3des-s2k-bug", decifrare il file e cifrarlo ancora con la stessa opzione.

NOTA: L'opzione è stata rimossa nelle versioni 1.1.0 e successive di GnuPG, quindi occorre usare una versione tra la 1.0.1 e la 1.0.7 per ri-cifrare i file in questione.

4.14) Come si usa GnuPG in modo automatizzato?

Occorre usare l'opzione --batch e non usare passphrase, visto che non c'è modo più sicuro di immagazzinarle che nel portachiavi privato. Il modo suggerito per creare chiavi per l'uso automatizzato è:

Su una macchina sicura:

1. Se si vuole firmare automaticamente, creare una sottochiave di firma per la propria chiave (usare il menù di modifica interattiva delle chiavi: 'gpg --edit-key keyID', poi "addkey" e selezionare il tipo di chiave DSA).
2. Assicurarsi di usare una passphrase (richiesto dall'implementazione attuale).
3. 'gpg --export-secret-subkeys --no-comment prova >secring.auto'
4. Copiare secring.auto e il portachiavi pubblico in una directory.
5. Andare in questa directory.
6. 'gpg --homedir . --edit prova' e usare "passwd" per rimuovere la passphrase dalle sottochiavi. Può anche essere utile rimuovere le sottochiavi non utilizzate.
7. Copiare secring.auto su un dischetto e portarlo sulla macchina da usare.

Sulla macchina da usare:

1. Installare secring.auto come portachiavi privato.
2. A questo punto tutto è pronto per l'uso. È anche buona norma installare un sistema di segnalazione delle intrusioni per avere notizia dei tentativi di intrusione e, nel caso, revocare le sottochiavi installate su questa macchina e reinstallarne di nuove.

4.15) Quali programmi di posta elettronica è possibile usare con GnuPG?

Cifrare la posta elettronica è uno degli usi più popolari di GnuPG. Svariati programmi di posta elettronica supportano GnuPG a vari livelli. Semplificando un po', ci sono due modi per cifrare posta con GnuPG: l'armatura ASCII "alla vecchia maniera" (ossia cifratura con testo in chiaro) e lo stile RFC 2015 (in precedenza chiamato PGP/MIME, ora OpenPGP), che ha pieno supporto MIME. Alcuni programmi di posta elettronica supportano solo uno di questi metodi, quindi la scelta dipende dalle proprie esigenze e dalle capacità dei propri corrispondenti. Ancora, il supporto può essere integrato nel programma, oppure fornito con "plug-in" o strumenti esterni.

La lista seguente non è esaustiva:

 Programma      OpenPGP ASCII   Come? (I,P,E)
 -------------------------------------------------------------
 Calypso           N      Y      P (Unixmail)
 Elm               N      Y      E (mailpgp,morepgp)
 Elm ME+           N      Y      I
 Emacs/Gnus        Y      Y      E (Mailcrypt,gpg.el)
 Emacs/Mew         Y      Y      I
 Emacs/VM          N      Y      E (Mailcrypt)
 Evolution         Y      Y      I
 Exmh              Y      Y      I
 GNUMail.app       Y      Y      P (PGPBundle)
 GPGMail           Y      Y      I
 KMail (<=1.4.x)   N      Y      I
 KMail (1.5.x)     Y(P)   Y(N)   P/I
 Mozilla           Y      Y      P (Enigmail)
 Mulberry          Y      Y      P
 Mutt              Y      Y      I
 Sylpheed          Y      Y      I
 Sylpheed-claws    Y      Y      I
 TkRat             Y      Y      I
 XEmacs/Gnus       Y      Y      E (Mailcrypt)
 XEmacs/Mew        Y      Y      I
 XEmacs/VM         N      Y      E (Mailcrypt)
 XFmail            Y      Y      I
 I - Integrato, P - Plug-in, E - Strumento Esterno

La tabella seguente elenca i programmi di posta elettronica proprietari. Il Progetto GNU sconsiglia l'uso di questi programmi, ma sono elencati comunque per motivi di interoperabilità.

 Programma      OpenPGP ASCII   How? (I,P,E)
 -------------------------------------------------------------
 Apple Mail        Y      Y      P (GPGMail)
 Becky2            Y      Y      P (BkGnuPG)
 Eudora            Y      Y      P (EuroraGPG)
 Eudora Pro        Y      Y      P (EudoraGPG)
 Lotus Notes       N      Y      P
 Netscape 4.x      N      Y      P
 Netscape 7.x      Y      Y      P (Enigmail)
 Novell Groupwise  N      Y      P
 Outlook           N      Y      P (G-Data)
 Outlook Express   N      Y      P (GPGOE)
 Pegasus           N      Y      P (QDPGP,PM-PGP)
 Pine              N      Y      E (pgpenvelope,(gpg|pgp)4pine)
 Postme            N      Y      P (GPGPPL)
 The Bat!          N      Y      P (Ritlabs)

Una buona panoramica sul supporto OpenPGP si può trovare a:
<http://www.openpgp.fr.st/courrier_en.html> e
<http://www.bretschneidernet.de/tips/secmua.html>.

Gli utenti dei programmi di posta per Win32 a cui manca il supporto OpenPGP possono considerare di usare GPGrelay <http://gpgrelay.sourceforge.net>, un piccolo server per inoltrare la posta elettronica, che usa GnuPG per abilitare molti programmi di posta a inviare e ricevere posta conforme a PGP-MIME (RFC 2015).

4.16) Non è possibile avere una libreria gpg?

È stato chiesto più volte, ma il punto di vista attuale dei curatori di GnuPG è che ciò causerebbe problemi di sicurezza, quindi non sarà implementata nel prossimo futuro. In ogni caso, per alcune aree applicative, gpgme potrebbe essere una buona soluzione. Lo si trova a <ftp://ftp.gnupg.org/gcrypt/alpha/gpgme>.

4.17) Ho generato un certificato di revoca, ma non capisco come spedirlo ai key server.

La maggior parte dei key server non accettano "semplici" certificati di revoca. Occorre prima importare il certificato in gpg:

e quindi spedire la chiave revocata ai keyserver:

(oppure usando un'interfaccia web per il keyserver).

4.18) Come sposto il portachiavi in una directory differente?

GnuPG conserva in una speciale directory "homedir" vari file: options, pubring.gpg, secring.gpg, trustdb.gpg e altri. GnuPG crea e usa sempre questi file. Su Unix, la directory homedir è di solito ~/.gnupg; su Windows "C:\gnupg\".

Se si vuole spostare i portachiavi altrove, si usi l'opzione:

in modo da far creare a GnuPG tutti i suoi file in quella directory. Il portachiavi diventerà "/mio/percorso/pubring.gpg". In questo modo è possibile immagazzinare i propri dati privati su un dischetto. Non si usi "--keyring", visto che il suo scopo è di specificare dei file-portachiavi aggiuntivi.

4.19) Come verifico i pacchetti firmati?

Prima di poter verificare la firma che accompagna un pacchetto, occorre assicurarsi di avere nel proprio portachiavi la chiave del fornitore del pacchetto, sia esso un'organizzazione o una persona. Per evitare i messaggi di avvertimento di GnuPG, la chiave dovrebbe essere convalidata (o almeno firmata localmente).

Occorrerà anche scaricare il file di firma che accompagna il pacchetto, che di solito ha lo stesso nome del pacchetto e un'estensione .sig (se è binario) o .asc (se ha armatura ASCII).

Una volta importata la chiave e scaricati i file del pacchetto e della firma, si usi:

Se il file di firma ha lo stesso nome del file del pacchetto (esclusa l'estensione), si può verificare il pacchetto indicando anche solo il file di firma, visto che GnuPG adotterà come nome del pacchetto il nome dato (escludendo l'estensione .sig or .asc). Ad esempio, per verificare un pacchetto chiamato prova.tar.gz con il suo file di firma binaria, si usi:

4.20) Come esporto un portachiavi selezionando solo alcune chiavi?

Se occorre creare un portachiavi che contiene solo un sottoinsieme delle chiavi selezionate da un portachiavi principale (ad esempio per un club, un gruppo di utenti, un dipartimento aziendale), basta semplicemente specificare le chiavi che si vuole esportare:

4.21) Ho ancora la mia chiave privata, ma ho perso quella pubblica. Cosa posso fare?

Tutte le chiavi private OpenPGP contengono una copia della chiave pubblica, in modo da permettere di creare una nuova chiave pubblica in situazioni disperate.

Uno strumento per convertire una chiave privata in una pubblica è stato incluso dalle versioni 1.2.1 e successive di GnuPG (in realtà si tratta di una nuova opzione per gpgsplit). Funziona così:

Per prima cosa si dovrebbe provare a esportare solo la chiave privata e convertirla, ma dovrebbe funzionare anche con l'intero portachiavi privato. Fatto questo, il file pubblica.gpg può essere importato nel portachiavi pubblico come al solito.

4.22) I messaggi firmati in chiaro mandati da un servizio di webmail hanno una firma non valida. Perché?

Occorre controllare nelle impostazioni del servizio webmail che non venga inserita formattazione HTML nel messaggio firmato, una volta che è stato incollato. Se ciò avviene, il messaggio viene alterato dai tag HTML o dagli spazi aggiunti, che invalidano la firma apposta sul messaggio originale. A volte è possibile che il destinatario sia in grado di copiare la parte del messaggio originale firmato in un file di testo e verificare così la firma; se il servizio webmail non permette di spedire messaggi in testo semplice, si può provare ad allegare come file il messaggio firmato.

5. QUESTIONI DI COMPATIBILITÀ

5.1) È possibile cifrare un messaggio con GnuPG in modo da poterlo decifrare con PGP?

Dipende dalla versione di PGP.

• PGP 2.x
  È impossibile, perché PGP 2.x di norma usa IDEA, che non è supportato da GnuPG ed è brevettato (si veda 3.3), ma se si dispone di una versione modificata di PGP si può provare così:
  $ gpg --rfc1991 --cipher-algo 3des ...

  Attenzione a fornire a gpg i dati da cifrare usando un file e non una pipe, altrimenti PGP 2 non sarà in grado di leggerli.

  Questo metodo non può essere usato per cifrare messaggi per PGP 2 usando crittografia convenzionale (simmetrica).

• PGP 5.x e superiori
  Occorre indicare sue opzioni aggiuntive:
  --compress-algo 1 --cipher-algo cast5

  Si può usare anche "3des" al posto di "cast5", mentre "blowfish" non funziona con tutte le versioni di PGP 5. Si può anche mettere:

  compress-algo 1

  nel proprio file ~/.gnupg/options; non interferirà con le normali operazioni di GnuPG.

  A differenza che per PGP 2, questa soluzione funziona anche per la crittografia convenzionale.

5.2) Come si migra da PGP 2.x a GnuPG?

PGP 2 usa gli algoritmi di cifratura RSA e IDEA. Il brevetto su RSA è scaduto, quindi RSA è incluso in GnuPG dalla versione 1.0.3, mentre l'algoritmo IDEA è ancora brevettato fino al 2007. Sotto determinate condizioni è possibile usare IDEA anche da subito: si veda la domanda 3.3 a proposito di come aggiungere a GnuPG il supporto per IDEA e si legga <http://www.gnupg.org/gph/en/pgp2x.html> per completare la migrazione.

5.3) (rimossa)

(rimossa)

5.4) Perché PGP 5.x non riesce a cifrare messaggi con alcune chiavi?

La PGP Inc. si rifiuta di accettare chiavi ElGamal di tipo 20 perfino per cifrare. Supportano solo il tipo 16 (che è identico, almeno per la decifratura). Per una migliore interoperabilità, GnuPG (a partire dalla versione 0.3.3) usa anche il tipo 16 per la sottochiave ElGamal che è creata se si sceglie l'algoritmo predefinito. È possibile aggiungere alla propria chiave pubblica una chiave ElGamal di tipo 16; ciò non pone problemi perché le firme resteranno comunque valide.

5.5) Perché PGP 5.x non riesce a verificare i miei messaggi?

PGP 5.x non accetta le firme v4 per i dati, ma OpenPGP richiede che siano generate firme v4 per tutti i tipi di dati e GnuPG le usa in modo predefinito. Si usi l'opzione "--force-v3-sigs" per generare firme v3 per i dati.

5.6) Come trasferisco valori di fiducia nel proprietario da PGP a GnuPG?

C'è uno script nella directory tools. Dopo aver importato il portachiavi di PGP, si usi il comando:

dove portachiavipgp è il portachiavi originale, non il portachiavi di GnuPG, che occorre avere già creato.

5.7) A PGP non piace la mia chiave privata.

Le versioni più vecchie di PGP possono lamentarsi per alcuni pacchetti contenenti commenti privati che sono usati da GnuPG. Questi pacchetti rispettano pienamente OpenPGP, è PGP a non essere completamente in linea con OpenPGP. Una soluzione consiste nell'esportare le chiavi private con il comando:

Un'altra possibilità è questa: di regola GnuPG cifra le chiavi private con l'algoritmo simmetrico Blowfish. I vecchi PGP conoscono solo gli algoritmi simmetrici 3DES, CAST5, o IDEA. Col metodo seguente è possibile ri-cifrare la propria chiave gpg con un algoritmo diverso:

Quindi si usi passwd per cambiare la password (si usi la stessa password, stavolta verrà usata per cifrare con l'algoritmo CAST5).

Ora è possibile esportarla e PGP dovrebbe riuscire a usarla.

Per PGP 6.x si usino le seguenti opzioni:

5.8) GnuPG non installa più un file ~/.gnupg/options. Dove è?

Il file ~/.gnupg/options è stato rinominato in ~/.gnupg/gpg.conf a partire dalla versione 1.1.92, ma se durante un aggiornamento viene trovato un file ~/.gnupg/options, continuerà ad essere usato. Questa modifica era necessaria per seguire uno schema più coerente nel chiamare i file, adottato anche dagli strumenti disponibili in futuro. Si può rinominare un file options esistente in gpg.conf, se si sta facendo un aggiornamento o se si riceve il messaggio che "old default options file" è ignorato (o "manca il file con le opzioni predefinite"); succede quando vengono rilevati entrambi i file gpg.conf e options.

5.9) Come si esportano le chiavi GnuPG per usarle con PGP?

Questa domanda viene fatta abbastanza spesso, quindi ecco un HOWTO:

PGP può usare le chiavi private generate da GnuPG per la maggior parte dei tipi di chiavi. I problemi che possono insorgere occasionalmente sono dovuti al fatto che GnuPG supporta qualche caratteristica dello standard OpenPGP che non è supportata da PGP. Se una chiave privata utilizza qualcuna di queste caratteristiche, PGP può rifiutare la chiave o creare problemi durante il suo uso. Si noti che PGP non usa chiavi di firma ElGamal, quindi queste chiavi non sono utilizzabili con alcuna versione.

Le istruzioni seguenti dovrebbero essere valide per le versioni 1.0.7 e seguenti di GnuPG e 7.0.3 di PGP.

Per prima cosa, si modifichi la chiave. La maggior parte di questa linea non è necessaria, visto che i valori predefiniti sono corretti, ma non fa male reimmettere i valori: andranno a sostituire eventuali valori errati contenuti nel file delle opzioni.

Poi si disabilitino alcune funzioni e si scelga la lista degli algoritmi preferiti di cifratura, di hash e di compressione in modo che possano essere usati da PGP (sì, lo so che è una strana lista di algoritmi, ma sono quelli usati da PGP, tranne l'IDEA).

Ora si scriva la lista delle preferenze sulla chiave.

Infine occorre decifrare la chiave e ri-cifrarla, assicurandosi di usare un algoritmo di cifratura riconosciuto da PGP. Questo è stato scelto col comando --edit precedente, quindi resta solo da cambiare la passphrase, in modo da rendere effettivao il cambiamento di cifratura. È possibile utilizzare ancora la stessa passphrase, oppure cogliere l'occasione per cambiarla.

Si salvi il tutto.

Si esporti la chiave al solito modo:

Grazie a David Shaw per queste informazioni!

6. PROBLEMI e MESSAGGI DI ERRORE

6.1) Perché ricevo il messaggio "gpg: Warning: using insecure memory!" ("Attenzione: si sta usando memoria insicura!")?

Su molti sistemi, questo programma deve essere installato come setuid(root). Ciò è necessario per bloccare le pagine di memoria, impedendo al sistema di scriverle sul disco e quindi mantenendo le chiavi private veramente segrete. Se non si ricevono messaggi di avvertimento riguardanti la memoria insicura, significa che il proprio sistema supporta il blocco della memoria senza necessità di essere root. Il programma rinuncia comunque ai diritti di root appena la memoria bloccata viene riallocata.

Per rendere il binario di gpg setuid(root) si può usare una delle seguenti linee di comando:

o

Alcuni, per motivi di sicurezza, evitano di usare setuid(root) a meno che non sia assoultamente richiesto. Si consulti il proprio amministratore di sistema se non si è in grado di valutare la situazione da soli.

Su UnixWare 2.x e 7.x occorre installare GnuPG col privilegio 'plock' per ottenere lo stesso effetto:

Se non si può o non si vuole installare GnuPG setuid(root), si può usare l'opzione "--no-secmem-warning" o aggiungere:

al file ~/.gnupg/options o ~/.gnupg/gpg.conf (per disabilitare il messaggio di avvertimento).

Su alcuni sistemi (ad es., Windows) GnuPG non blocca le pagine di memoria e le versioni di GnuPG precedenti alla 1.0.4 mostrano l'avviso:

Questo avviso non può essere disabilitato dall'opzione vista sopra perché era ritenuto troppo importante; però si è visto che confondeva gli utenti e quindi alla fine è stato rimosso.

6.2) Il supporto per i file grandi non funziona...

LFS (Large File Support) funziona correttamente nelle versioni successive alla 1.0.4. Se configure non lo riconosce, si provi con un compilatore diverso (ossia migliore). egcs 1.1.2 funziona bene, altri gcc alcune volte no. A proposito, vari problemi di compilazione du GnuPG 1.0.3 e 1.0.4 su HP-UX e Solaris erano dovuti a un supporto LFS difettoso.

6.3) Nel menù di modifica i valori di fiducia non vengono visualizzati correttamente dopo aver firmato degli uid. Perché?

Succede perché le informazioni sulla fiducia sono immagazzinate subito nel trustdb, ma il calcolo effettivo della fiducia è fatto solo dopo aver dato il comando "salva". Questo è un bug di progettazione difficile da risolvere, ma verrà considerato in qualche futura versione.

6.4) Cosa significa "skipping pubkey 1: already loaded"?

A partire da GnuPG 1.0.3 è incluso l'algoritmo RSA. Se si ha ancora un comando "load-extension rsa" nel file options, si riceve il messaggio visto sopra. Si rimuova semplicemente quel comando dal file options.

6.5) GnuPG 1.0.4 non crea il file ~/.gnupg ...

È un bug noto, già corretto nelle versioni successive.

6.6) Una firma ElGamal non viene più verificata a partire dalla versione 1.0.2 ...

Si usi l'opzione --emulate-md-encode-bug.

6.7) Le vecchie versioni di GnuPG non permettono di verificare le firme ElGamal.

Occorre aggiornare a GnuPG 1.0.2 o superiore.

6.8) Perché quando si usa --clearsign, ogni tanto al testo vengono aggiunti dei trattini in più?

Si chiama testo "protetto con il trattino" (dash-escaped) ed è richiesto da OpenPGP. Viene usato in presenza di linee che iniziano per un trattino ("-") e serve a far sì che le linee che delimitano la firma e il testo (ossia quelle tipo "-----BEGIN PGP SIGNATURE-----") siano le uniche linee del testo che iniziano con due trattini.

Se si usa GnuPG per processare il testo, i trattini in più vengono rimossi autometicamente. Anche i buoni programmi di posta elettronica rimuovono i trattini quando visualizzano messaggi di questo tipo.

6.9) Cosa significa "can't handle multiple signatures" ("Impossibile gestire queste firme multiple")?

A causa dei diversi formati di messaggio esistenti, GnuPG non è sempre in grado di dividere un messaggio con firme multiple nelle sue parti senza ambiguità. Questo messaggio di errore informa che qualcosa non va nel messaggio.

L'unico metodo sicuro per avere firme multiple su un file è usare il formato OpenPGP con pacchetti di firma a una sola passata (che è quello predefinito in GnuPG), oppure il formato di firma in chiaro.

6.10) Inviando una chiave a un keyserver, non succede niente...

Probabilmente si sta usando GnuPG 1.0.2 (o una versione precedente) per Windows, in cui quella funzionalità non era ancora implementata, ma ciò non era comunicato a causa di un bug. Le versioni dalla 1.0.4 in su mostrano un messaggio di avviso in proposito.

6.11) Cosa significa "gpg: waiting for lock ..."?

Probabilmente la precedente sessione di GnuPG si è conclusa in modo anormale e ha lasciato un lock file. Occorre cercare in ~/.gnupg i file .*.lock e rimuoverli.

6.12) Le vecchie versioni di gpg (ad es. 1.0) hanno problemi con le chiavi create dalle nuove versioni...

A partire dalla versione 1.0.3, le chiavi generate con gpg vengono incorporano le preferenze per TWOFISH (e AES a partire dalla 1.0.4); ciò significa anche che sono in grado di usare il nuovo sistema di cifratura MDC, che sarà presto incluso in OpenPGP ed è supportato anche da PGP 7. Questo nuovo metodo rende impossibile un certo tipo di attacchi (non così nuovo) su tutti i sistemi di cifratura della posta.

Ciò implica che tutti i binari di versioni precedenti alla 1.0.3 hanno problemi con le chiavi più recenti. Visto che per motivi di sicurezza è comunque consigliato mantenere aggiornata la propria installazione di gpg, si può aggirare il problema forzando gpg a usare l'algoritmo di cifratura che una volta era quello predefinito, inserendo:

nel file options.

6.13) Con la versione 1.0.4 ottengo il messaggio "this cipher algorithm is deprecated ..." ("questo algoritmo di cifratura è deprecato...")

Se è stata appena generata una chiave e si ottiene questo messaggio durante la cifratura, si è in presenza di un bug nella versione 1.0.4. Questa usa il nuovo metodo di cifratura AES Rijndael, che viene scorrettamente definito "deprecato". Si ignori questo messaggio, le versioni più recenti correggono questo bug.

6.14) Alcune date vengono visualizzate come ????-??-??. Perché?

A causa di vincoli nella maggior parte delle implementazioni delle libc, le date oltre il 19-01-2038 non possono essere visualizzate. I sistemi operativi a 64 bit non sono affetti da questo problema. Per evitare di visualizzare date scorrette, GnuPG usa invece dei punti di domanda. Per vedere il valore corretto è possibile usare le opzioni --with-colons e --fixed-list-mode.

6.15) In caso di ulteriori problemi, come si segnala un bug?

Ci si assicuri che non è ancora stato descritto nelle mailing list e si controlli nella lista dei bug (si trova un link ad essa nella pagina della documentazione). Se non si è sicuri che si tratta di un bug, si può mandare una mail alla lista gnupg-devel. Altrimenti si usi il sistema di tracciamento dei bug di GnuPG: <http://bugs.gnupg.org>.

6.16) Perché GnuPG non supporta i certificati X.509?

Principalmente perché GnuPG è un'implementazione dello standard OpenPGP (RFC 2440), che è un'infrastruttura diversa e in competizione con X.509.

Entrambi sono sistemi di crittografia a chiave pubblica, ma differiscono nella gestione delle chiavi pubbliche.

6.17) Perché i caratteri di alcune lingue usati negli user ID vengono mostrati in modo strano?

Secondo OpenPGP, GnuPG codifica le stringhe degli user ID (e altre cose) usando UTF-8. Secondo questa codifica di Unicode, la maggior parte dei caratteri tipici di alcune lingue vengono codificati con sequenze di due o tre bit. Per esempio, &aring; (0xE5 in ISO-8859-1) diventa &Atilde;&yen; (0xC3, 0xA5). Questo può anche essere il motivo per cui i keyserver non trovano le chiavi che usano questi caratteri negli user ID.

6.18) Si ottengono errori di 'sed' eseguendo ./configure su Mac OS X ...

Verranno corretti dopo che GnuPG sarà stato aggiornato a autoconf-2.50. Per ora, si può correggere cercando nello script configure la linea che imposta CDPATH e inserendo l'espressione:

sotto di essa.

6.19) Perché GnuPG 1.0.6 si lamenta se vengono usati portachiavi creati con GnuPG 1.0.7?

C'è un piccolo bug in GnuPG 1.0.6, che non analizza correttamente i pacchetti di fiducia. Se non si vuole aggiornare è possibile applicare questa patch:

<http://www.gnupg.org/developer/gpg-woody-fix.txt>

6.20) Dopo aver aggiornato a GnuPG 1.0.7 occorre più tempo per caricare i portachiavi. Cosa si può fare?

È stata modificata la modalità di immagazzinamento delle firme sulle chiavi in modo da poter supportare le firme v3. Per la migrazione è possibile usare il nuovo comando --rebuild-keydb-caches, che è stato inserito in questa nuova versione e che aumenta la velocità di molte operazioni compiute sui portachiavi esistenti.

6.21) L'esistenza di uno user ID su cui si ha piena fiducia non dovrebbe evitare messaggi di avvertimento quando si tenta di cifrare per altri ID della stessa chiave?

No. In realtà questo era un bug di validità delle chiavi nelle versioni 1.2.1 e precedenti di GnuPG. Durante lo sviluppo di GnuPG 1.2.2 è stato scoperto un bug nel codice di validazione delle chiavi: nelle chiavi con più di uno user ID, tutti gli ID ereditavano il livello di validità posseduto dall'ID che aveva il livello maggiore. Il bug è stato corretto nella versione 1.2.2 di GnuPG e si raccomanda l'aggiornamento per risolvere questo problema. Maggiori informazioni e una patch per alcune versioni di GnuPG precedenti alla 1.2.2 si trovano su:

<http://lists.gnupg.org/pipermail/gnupg-announce/2003q2/000268.html>

6.22) Ho appena compilato GnuPG dai sorgenti sul mio sistema GNU/Linux basato su RPM e non funziona. Perché?

Molte distribuzioni GNU/Linux che usano il sistema di pacchetti RPM durante l'installazione standard installano i binari di GnuPG nella directory /usr/bin. Se successivamente si compila e si installa GnuPG dai sorgenti invece che da un pacchetto RPM sorgente, questi file non verranno sovrascritti, visto che la posizione predefinita dei binari di GnuPG è in /usr/local/bin, a meno che durante la compilazione non venga usata l'opzione '--prefix' per indicare una posizione alternativa. Poiché probabilmente la directory /usr/bin precede la directory /usr/local/bin nel percorso predefinito, continueranno ad essere richiamati automaticamente i vecchi binari della versione RPM.

Per risolvere il problema, occorre disinstallare la versione RPM con il comando 'rpm -e gnupg' prima di installare i binari compilati dai sorgenti. Se si ottengono degli errori di dipendenze mentre si tenta di disinstallare l'RPM (ad esempio perché si ha installato up2date di Red Hat, che usa GnuPG), occorre disinstallare l'RPM con il comando 'rpm -e gnupg --nodeps'. Tutti i file che causano dipendenze dovrebbero essere sostituiti automaticamente installando la versione compilata. Se si usa la directory predefinita /usr/local/bin, potrebbe essere necessario dover configurare alcuni pacchetti, come l'aggiornamento online Yast di SuSE, per far sì che cerchino i binari di GnuPG in /usr/local/bin; alternativamente, è possibile creare dei link simbolici in /usr/bin, che puntano ai binari contenuti in /usr/local/bin.

7. ARGOMENTI AVANZATI

7.1) Come funziona tutto ciò?

Per generare una coppia di chiavi pubblica/privata, si usi:

e si scelgano i valori predefiniti.

I dati cifrati con una chiave pubblica possono essete decifrati solo con la corrispondente chiave privata. La chiave privata è protetta da una password, quella pubblica no.

Così, per spedire un messaggio a un amico, occorre cifrarlo con la sua chiave pubblica, in modo che lui solo possa decifrarlo, dopo aver immesso la password necessaria per utilizzare la propria chiave privata.

GnuPG è utile anche per firmare dati, che in questo caso vengono cifrati con la chiave privata e decifrati con la chiave pubblica corrispondente; durante la firma, viene calcolato un hash dei dati, che viene poi codificato usando la chiave privata: chiunque possieda la corrispondente chiave pubblica potrà quindi usarla per decodificare l'hash e verificare che i dati provengono veramente dal mittente e non sono stati modificati.

Un portachiavi non è altro che un grosso file dove sono immagazzinate le chiavi. C'è un portachiavi pubblico, che contiene la propria chiave pubblica e quella dei propri corrispondenti, e un portachiavi privato, che contiene la chiave privata. Quest'ultimo va trattato con molta cura: nessuno dovrebbe potervi accedere e i dati contenuti vanno protetti con una *buona* passphrase.

Uando l'opzione 'gpg -c', è possibile cifrare dati "in modo convenzionale", ossia senza usare la chiave pubblica o privata, ma usando una passphrase che dovrà essere conosciuta dalla persona che vuole decifrare i dati. Questa possibilità è utile soprattutto per cifrare cose per sé stessi (anche se è possibile raggiungere lo stesso scopo cifrando i dati con la propria chiave pubblica), o per comunicare con corrispondenti che si conosce e con cui si può facilmente scambiare la passphrase (ad es. il proprio ragazzo o la propria moglie). Il vantaggio sta nel fatto che è possibile cambiare la passphrase di tanto in tanto, in modo da ridurre il rischio che vecchi messaggi possano venire decifrati da persone accidentalmente venute a conoscenza della passphrase.

È possibile aggiungere chiavi al proprio portachiavi, o esportarle, con i comandi 'gpg --import' e 'gpg --export'. 'gpg --export-secret-keys' esporterà le chiavi private, funzione utile nel caso si sia generata la chiave su una macchina e la si voglia trasportare su un'altra.

Le chiavi possono essere firmate con l'opzione 'gpg --edit-key'. Firmando una chiave, si afferma di essere certi che quella chiave appartiene esattamente alla persona indicata dallo user ID della chiave. Per assicurarsi di ciò, occorre verificare l'impronta digitale (fingerprint) della chiave con:

al telefono (se si conosce perfettamente la voce dell'altra persona), a un key signing party (riunioni che vengono spesso organizzate durante le manifestazioni informatiche), o a una riunione del proprio gruppo di utenti GNU/Linux.

Altre cose: è possibile usare l'opzione "-o nomefile" per forzare l'output a un certo file (si usi "-" per forzare allo standard output). "-r" permette di specificare il destinatario (ossia la chiave pubblica con cui cifrare i dati) sulla linea di comando, invece di farlo successivamente in modo interattivo.

Ah, questo è importante: di regola i dati sono cifrati in uno strano formato binario. Se si vuole che i risultati siano in formato ASCII leggibile, basta aggiungere l'opzione '-a'. Ma la soluzione migliore consiste nell'usare un programma di posta elettronica compatibile con MIME (Mutt, Pine e molti altri).

C'è un piccolo problema di sicurezza nello standard OpenPGP (e quindi in GnuPG): per evitarlo, è buona norma cifrare e firmare sempre i messaggi, invece che semplicemente cifrarli.

7.2) Perché alcune firme fatte con chiavi ELG-E risultano valide?

Si tratta di chiavi ElGamal generate da GnuPG in pacchetti v3 (RFC 1991). In seguito, OpenPGP ha modificato il numero identificativo delle chiavi ElGamal utilizzabili per la cifratura e la firma da 16 a 20. GnuPG ora usa 20 quando genera nuove chiavi ElGamal, ma accetta ancora 16 (che secondo OpenPGP significa "solo per cifratura") se la chiave è contenuta in un pacchetto v3. GnuPG è l'unico programma che aveva usato queste chiavi ElGamal v3, quindi questo modo di procedere è abbastanza sicuro.

7.3) Come funziona il meccanismo della fiducia?

Più o meno come in PGP. La differenza sta nel fatto che la fiducia è calcolata nel momento in cui occorre. Questo è uno dei motivi per cui esiste il trustdb, che contiene una lista delle firme valide sulle chiavi. Se non si sta eseguendo gpg in modalità batch, viene sempre richiesto di assegnare un valore di fiducia nel proprietario (ownertrust) alla chiave.

È possibile vedere la validità (valore calcolato della fiducia) con questo comando:

Se il primo campo è "pub" o "uid", il secondo campo mostra la fiducia:

 o = Sconosciuta (la chiave è nuova per il sistema)
 e = La chiave è scaduta
 q = Indefinita (nessun valore assegnato)
 n = Nessuna fiducia in questa chiave
 m = Fiducia marginale in questa chiave
 f = Piena fiducia in questa chiave
 u = Fiducia definitiva in questa chiave; valore usato solo
 per chiavi di cui è disponibile anche la chiave segreta
 r = La chiave è stata revocata
 d = La chiave è stata disabilitata

Il valore nel campo "pub" è il migliore di tutti i campi "uid". È possibile vedere una lista dei valori di fiducia assegnati (quanto si ha fiducia nella capacità del proprietario di firmare correttamente le chiavi altrui) con:

Il primo campo è l'impronta digitale della chiave primaria, il secondo campo è il valore assegnato:

 - = Nessun valore di fiducia nel proprietario ancora assegnato o calcolato.
 n = Nessuna fiducia nelle capacità del proprietario di verificare
 correttamente le firme altrui
 m = Fiducia marginale nella capacità del proprietario di firmare
 altre chiavi
 f = Fiducia piena: assume che il proprietario sappia come firmare
 le chiavi.
 u = Non c'è bisogno di assegnare fiducia in sè stessi, visto che si
 possiede la chiave privata

Questi valori sono da considerare confidenziali, visto che esprimono le proprie opinioni a proposito degli altri. PGP immagazzina queste informazioni nel portachiavi, quindi non è una buona idea pubblicare un portachiavi di PGP invece di esportare le chiavi che contiene. GnuPG immagazzina i valori di fiducia nel file trustdb.gpg, quindi non c'è problema a distribuire un portachiavi di gpg (ma è comunque disponibile un comando "--export").

7.4) Cosa significa questo output: "key C26EE891.298, uid 09FB: ...."?

Questa è la rappresentazione interna di uno user ID nel trustdb. "C26EE891" è il keyid, "298" è l'ID locale (un numero identificativo nel trustdb) e "09FB" sono gli ultimi due byte di un hash ripe-md-160 dello user ID per questa chiave.

7.5) Come si interpretano alcune delle informazioni mostrate?

Mentre controlla la validità di una chiave, GnuPG a volte stampa alcune informazioni, a cui ne sono premesse altre riguardanti l'elemento che viene controllato.

Questo riguarda la chiave che ha 12345678 come key ID e 3456 come numero interno, che è un numero identificativo di elencazione nel trustdb.

Questo riguarda lo user ID della stessa chiave. Per identificarlo, vengono mostrati gli ultimi due byte di un hash ripe-md-160 sullo user ID.

Questa è una firma sulla chiave e sullo user ID, fatta con la chiave che ha key ID 9A8B7C6D; se la firma fosse stata fatta direttamente sulla chiave, la parte dello user ID sarebbe vuota (..//..).

7.6) Le linee di intestazione di una firma in chiaro fanno parte del materiale firmato?

No. Per esempio, è possibile aggiungere o rimuovere linee "Comment:". Lo scopo è simile a quello delle linee di intestazione dei messaggi di posta elettronica. Comunque una linea "Hash:" è richiesta dalle firme OpenPGP per comunicare al programma che dovrà analizzarle quale algoritmo di hash usare.

7.7) Cosa è la lista degli algoritmi preferiti?

La lista degli algoritmi preferiti è una lista di algoritmi di cifratura, hash e compressione, immagazzinata nell'autofirma apposta a una chiave durante la sua generazione. Quando viene cifrato un documento, GnuPG usa questa lista (che quindi fa parte della chiave pubblica) per scegliere quali algoritmi usare. In pratica la lista comunica agli altri utenti quali algoritmi il destinatario è in grado di usare e in quale ordine di preferenza.

7.8) Come si può modificare la lista degli algoritmi preferiti?

Dalla versione 1.0.7, è possibile usare il menù di modifica e impostare la nuova lista delle preferenze con il comando "setpref"; il formato di questo comando assomiglia all'output del comando "pref". Le preferenze non sono modificate immediatamente, ma il cambiamento avrà effetto solo quando verrà creato un nuovo user ID. Se si vuole cambiare le preferenze per gli user ID esistenti, occorre selezionare questi user ID (o non selezionarne alcuno per aggiornarli tutti) e usare il comando "updpref". Si noti che la data dell'autofirma viene aumentata di un secondo quando viene usato questo comando.

8. RICONOSCIMENTI

Molti ringraziamenti a Nils Ellmenreich per aver curato questo file FAQ per così tanto tempo, a Werner Koch per il file FAQ originale e a tutti coloro che hanno scritto a gnupg-users e gnupg-devel. La maggior parte delle risposte è stata fornita da loro.

Grazie anche a Casper Dik per averci fornito uno script per generare questa FAQ (lui lo usa per l'eccellente FAQ su Solaris2).

Copyright (C) 2000, 2001, 2002, 2003 Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111, USA

La copia letterale e la distribuzione di questo intero articolo sono permesse con ogni mezzo, a patto che questa nota sia preservata.