Eleaml



Riportiamo integralmente - senza modifica alcuna - la versione in italiano del manuale ufficiale del PGP versione 2.6.2, tradotta in italiano da Marco Giaiotto.

Si riferisce ad una vecchia versione per DOS, ma le indicazioni fondamentali sono ancora valide, la differenza tra le versioni di PGP di allora e quelle di oggi stanno nella interfaccia grafica, mentre una volta si dovevano digitare i comandi da tastiera oggi si fa tutto con la interfaccia grafica (oggi siamo alla versione 8.03 di PGP - alla 7.03 versione internazionale).

Zenone di Elea

__________________________________________________________________________________


[Nota: questa e' la documentazione originale della versione 2.6.2 del MIT, inclusa qui senza modifiche. Per una spiegazione delle differenze tra PGP 2.6.3i e 2.6.2 si legga il file readme.1st. incluso nel pacchetto di distribuzione]

Phil's Pretty Good Software


Presenta

PGP(tm)


Pretty Good(tm) Privacy


Crittografia a chiave pubblica per tutti


Manuale d'uso del PGP(tm)
Volume I: funzioni essenziali

di Philip Zimmermann
Ultima revisione 11 Ottobre 94
Tradotto in Italiano da:
Marco Giaiotto
[email protected]

PGP Versione 2.6.2 - 11 Ott. 94
Software di
Philip Zimmermann, e molti altri.

Sinopsi:

PGP(tm) utilizza la crittografia a chiave pubblica per proteggere e-mail e file di dati. Comunicate in modo sicuro con persone che non avete mai visto, senza bisogno di canali sicuri per lo scambio delle chiavi. PGP ha molte funzioni ed e' veloce, con un sofisticato sistema di gestione delle chiavi, un sistema di firma digitale, comprime i dati ed ha un progetto ergonomicamente valido.

Software e documentazione (c) Copyright 1990-1994 Philip Zimmermann. Tutti i diritti riservati. Per informazioni sulla licenza d'uso di PGP, la distribuzione, il copyright, i brevetti, i marchi, le limitazioni ed i controlli sulle esportazioni, vedere la sezione "Aspetti Legali" nel "Manuale D'uso del PGP Volume II - Funzioni avanzate". Distribuito dal Massachusetts Institute of Technology.

"Qualunque cosa voi facciate sara' insignificante, ma e' molto importante che voi la facciate." -Mahatma Gandhi

Indice

Vista d'insieme

Pretty Good(tm) Privacy (PGP), di Phil's Pretty Good Software, e' un applicativo software di crittografia di elevata sicurezza per MSDOS, Unix, VAX/VMS e altri computers. PGP permette alle persone di scambiare files e messaggi con riservatezza, sicurezza di autenticita' e comodita'. Riservatezza significa che solo le persone a cui e' diretto il messaggio possono leggerlo. Sicurezza di autenticita' significa che il messaggio che sembra provenire da una particolare persona puo' solo essere stato inviato da quella persona. Comodita' significa che riservatezza e sicurezza di auten- ticita' sono raggiunte senza il fastidio di dover gestire le chiavi associate al software di crittografia convenzionale. Non e' richiesto nessun canale sicuro per lo scambio delle chiavi fra gli utenti, per cui PGP e' molto piu' facile da usare. La ragione e' che PGP e' basato su di una nuova potente tecnologia chiamata crittografia "a chiave pubblica".

PGP associa la comodita' del sistema di crittografia a chiave pubblica Rivest-Shamir-Adleman (RSA) con la velocita' della crittografia conven- zionale, l'adattamento dei messaggi per la firma digitale, un buon progetto ergonomico ed un sofisticato sistema di gestione delle chiavi. PGP svolge le funzioni associate alle chiavi pubbliche piu' velocemente di molti altri applicativi software. PGP e' la crittografia a chiave pubblica per tutti.

PGP non prevede nessuna funzione interna per la gestione di modems. Dovrete usare per questo un prodotto software separato.

Questo documento, "Volume I: funzioni essenziali", si limita a spiegare i concetti essenziali per l'uso di PGP, e dovrebbe essere letto da tutti gli utilizzatori. Il "Volume II - funzioni avanzate" spiega le possibilita' avanzate di PGP ed altre funzioni speciali, e puo' essere letto dagli utilizzatori di PGP piu' evoluti. Nessuno dei due documenti spiega i dettagli della tecnologia di fondo degli algoritmi di critto- grafia, o la struttura dei dati.

Ritorno all'Indice

Perche' vi serve PGP?

E' personale. E' privato. E non sono affari di nessuno tranne vostri. Voi potreste pianificare una campagna politica, discutere delle vostre tasse, o avere una relazione clandestina. Oppure potreste fare qualcosa che sentite che non dovrebbe essere illegale, ma lo e'. Qualunque cosa sia, voi non volete che la vostra posta elettronica privata (e-mail) o i vostri documenti confidenziali vengano letti da altri. Non c'e' niente di sbagliato nel voler affermare il proprio diritto alla riservatezza. La riservatezza e' parte della nostra vita come la Costituzione.

Forse potreste pensare che la vostra e-mail sia sufficientemente legittima da non richiedere cifratura. Ma se siete cittadini rispettosi della legge senza nulla da nascondere, perche' non spedite sempre la vostra posta usando le cartoline? Perche' non vi sottoponete ai test antidroga su semplice richiesta? Perche' richiedere un mandato se la polizia vuole perquisire la vostra casa? State cercando di nascondere qualcosa? Dovete essere dei sovversivi o dei trafficanti di droga se nascondete la vostra posta nelle buste. O forse paranoici. Che bisogno hanno i cittadini rispettosi della legge di cifrare la propria e-mail?

Cosa succederebbe se tutti pensassero che i cittadini rispettosi della legge dovrebbero usare le cartoline per la propria posta? Se qualche spirito coraggioso tentasse di difendere la propria riservatezza usando una busta attirerebbe i sospetti. Forse le autorita' aprirebbero la sua posta per vedere cio' che nasconde. Per fortuna, non viviamo in questo tipo di mondo, perche' tutti proteggono la maggior parte della propria posta con le buste, cosi' nessuno attira sospetti facendo la stessa cosa. C'e' sicurezza nei grandi numeri. Analogamente, sarebbe bello se tutti usassero regolarmente la crittografia per la propria e-mail, innocente o meno, di modo che nessuno attirerebbe sospetti difendendo la propria riservatezza. Pensate a questo come ad una forma di solidarieta'.

Oggi, se il Governo vuole violare il diritto alla riservatezza dei cittadini ordinari, deve impegnare una certa quantita' di denaro e di lavoro per intercettare, aprire col vapore e leggere la posta, e ascoltare e possibilmente trascrivere le conversazioni telefoniche. Questo tipo di sorveglianza ad alto impegno lavorativo non e' pratica se applicata su larga scala. Questo viene fatto solo in casi importan- ti, quando sembra che valga la spesa.

Una parte sempre crescente delle nostre comunicazioni private si sta dirigendo verso i canali elettronici. La posta elettronica sta gradualmente rimpiazzando la posta tradizionale. I messaggi e-mail sono semplicemente troppo facili da intercettare e controllare ricercando parole significative. Puo' essere fatto semplicemente, regolarmente, automaticamente e senza essere scoperti su vasta scala. I cablogrammi internazionali sono gia' controllati in questo modo su larga scala dalla NSA [National Security Agency, N.d.T.]

Ci stiamo muovendo verso un futuro in cui la nazione sara' attraversata da reti dati in fibra ottica ad alta capacita' che collegheranno fra loro tutti i nostri sempre piu' diffusi personal computers. L'e-mail sara' normale per tutti, non una novita' come oggi. Il Governo proteggera' la nostra posta con protocolli di crittografia progettati dal Governo stesso. Probabilmente la maggior parte delle persone accettera' una simile situazione. Ma forse qualche persona preferira' le proprie misure di protezione personali.

Il progetto di legge 299 del senato, una proposta anti crimine multifunzionale del 1991, conteneva un provvedimento nascosto sconvolgente. Se questa risoluzione non vincolante fosse entrata in vigore, avrebbe costretto i produttori di sistemi di comunicazioni sicure ad inserire delle speciali "trappole" nei loro prodotti, di modo che il Governo potesse leggere i messaggi cifrati di chiunque. Il testo era: "E' volonta' del Congresso che i fornitori di servizi di comunicazione elettronica assicurino che i sistemi permettano al Governo di ottenere il testo in chiaro di voce, dati ed altre comunicazioni quando adeguatamente autorizzato dalla legge." Questa misura venne ritirata dopo rigorose proteste di singoli libertari e gruppi industriali.

Nel 1992 fu presentata al Congresso la proposta di sorveglianza della telefonia digitale dell'FBI. Questa avrebbe richiesto a tutti i produttori di sistemi di comunicazione di includervi speciali "porte" di sorveglianza remota che avrebbero permesso all'FBI di controllare dai propri uffici tutte le forme di comunicazione elettronica. Sebbene la proposta non abbia attratto nessun sostenitore al Congresso nel 1992 a causa dell'opposizione dei cittadini, essa fu ripresentata nel 1994.

Piu' allarmante di tutto e' la baldanzosa nuova politica sulla crittografia della Casa Bianca, sviluppata dalla NSA sin dall'inizio dell'amministrazione Bush, e rivelata il 16 aprile 1993. Il punto centrale di questa iniziativa e' un dispositivo di crittografia costruito dal Governo, chiamato "Clipper", contenente un nuovo algoritmo segreto di crittografia della NSA. Il Governo spinge l'industria privata ad utilizzare il Clipper in tutti i propri prodotti di comunicazione sicura, come telefoni, Fax, ecc. AT&T sta utilizzando il Clipper nei propri prodotti sicuri per trasmissione di voce. Il punto chiave: Al momento della produzione ogni Clipper viene programmato con una sua chiave unica, ed il Governo deve riceverne una copia, che viene tenuta al sicuro. Nessuna preoccupazione comunque-- il Governo promette che usera' quelle chiavi per decifrare le vostre comunicazioni solo quando debitamente autorizzato dalla legge. Naturalmente il logico passo successivo per rendere il Clipper assolutamente efficace sarebbe quello di rendere illegali le altre forme di crittografia.

Se la propria riservatezza e' fuorilegge, solo i fuorilegge avranno riservatezza. Le agenzie di spionaggio hanno accesso a sistemi di crittografia ottimi, cosi' come i trafficanti di armi e droga, i fornitori della Difesa, le compagnie petrolifere ed altri giganti industriali. Le persone comuni e le organizzazioni politiche minori non hanno generalmente avuto accesso a tecnologie di crittografia a chiave pubblica di "livello militare" a costi abbordabili. Fino ad oggi.

PGP da' alle persone il potere di avere la propria riservatezza nelle proprie mani. C'e' un bisogno sociale crescente di questo. Ecco perche' l'ho scritto.

Ritorno all'Indice

Come funziona

Sarebbe piu' semplice se voi aveste gia' una conoscenza dei concetti della crittogrfia in generale e di quella a chiave pubblica in particolare. Comunque, ecco alcune note introduttive sulla crittografia a chiave pubblica.

Per cominciare, un po' di terminologia. Supponiamo che io voglia inviarvi un messaggio che solo voi possiate leggere. Posso "criptarlo" o "cifrarlo", ovvero posso modificarlo in un modo terribilmente complicato, rendendolo illeggibile per chiunque tranne voi, il destinatario del messaggio. Io creo una "chiave" crittografica per cifrare il messaggio, e voi dovete usare la stessa chiave per decifrarlo o "decrittarlo". Almeno, il sistema convenzionale a chiave singola funziona cosi'.

Nei sistemi convenzionali, come il DES (US Federal Data Encryption Standard), si usa una sola chiave per cifrare e decifrare. Questo significa che la chiave deve essere trasmessa prima attraverso canali sicuri, in modo che i due corrispondenti la conoscano prima di inviare messaggi cifrati attraverso canali insicuri. Questo puo' essere scomodo. Poi, se avete un canale sicuro per scambiarvi le chiavi, perche' vi serve la crittografia?

Nei sistemi a chiave pubblica, ognuno possiede due chiavi complementari, una conosciuta pubblicamente ed una segreta (spesso chiamata privata). Ogni chiave sblocca il codice che l'altra crea. La conoscenza della chiave pubblica non vi aiuta a dedurre la chiave segreta corrispondente. La chiave pubblica puo' essere distribuita in modo capillare attraverso una rete di comunicazione. Questo protocollo assicura riservatezza senza richiedere l'uso di canali sicuri come quelli necessari per i sistemi di codifica convenzionali.

Chiunque puo' usare la chiave pubblica di una persona per cifrare ed inviare un messaggio, e il destinatario usera' la chiave privata corrispondente per decifrarlo. Nessuno oltre al destinatario potra' decifrarlo, perche' nessuno ha accesso alla chiave segreta. Neppure la persona che ha cifrato il messaggio sara' in grado di decifrarlo.

Si possono anche autenticare i messaggi. La chiave segreta del mittente puo' essere usata per cifrare un messaggio, e quindi "firmarlo". Questo crea nel messaggio una firma digitale che il destinatario (o chiunque) puo' verificare usando la corrispondente chiave pubblica. E' la prova che il mittente e' effettivamente la fonte del messaggio, e che il messaggio non e' stato modificato successivamente da altri, perche' solo il mittente possiede la chiave segreta che ha generato la firma. E' impossibile falsificare un messaggio firmato, ed il mittente non puo' successivamente negare di averlo firmato.

Questi due processi possono essere combinati per assicurare la riservatezza e l'autenticita', prima firmando il messaggio con la vostra chiave segreta, e quindi cifrandolo con la chiave pubblica del destinatario. Il destinatario inverte questo processo, decifrando il messaggio con la propria chiave e controllando la firma con la vostra chiave pubblica. Questi passi sono svolti automaticamente dal software del destinatario.

Siccome l'algoritmo di crittografia a chiave pubblica e' molto piu' lento di un metodo convenzionale, la cifratura e' effettuata meglio usando un metodo convenzionale veloce e di alta qualita' per cifrare il messaggio. Il messaggio originale non cifrato e' chiamato "testo in chiaro". In un processo non visibile all'utilizzatore, una chiave casuale temporanea viene generata, ed usata solo per questa cifratura, per cifrare convenzionalmente il testo in chiaro. Quindi la chiave pubblica del destinatario viene usata per cifrare la chiave temporanea. Questa chiave cifrata viene inviata assieme al testo cifrato al destinatario. Il destinatario usa la propria chiave segreta per ricuperare la chiave temporanea, e quindi la usa con l'algoritmo veloce di cifratura convenzionale a chiave singola per decifrare il messaggio originale.

Le chiavi pubbliche sono conservate in "certificati di chiave" che comprendono l'ID del proprietario (ovvero il suo nome), il momento (tempo) in cui la chiave e' stata generata e la chiave stessa. I certificati pubblici contengono le chiavi pubbliche, mentre i certificati segreti contengono le chiavi segrete. Ogni chiave segreta e' anche cifrata con la propria frase chiave, nel caso venisse rubata. Un file di chiavi, o "portachiavi" contiene uno o piu' di questi certificati. Il portachiavi pubblico contiene certificati pubblici ed il portachiavi segreto contiene certificati segreti.

Le chiavi sono anche indicate nel portachiavi con il loro "id di chiave", che e' un'abbreviazione della chiave pubblica (i 64 bits meno significativi). Quando questo id di chiave e' mostrato, per ulteriore semplicita' si usano solo gli ultimi 32. Mentre molte chiavi possono avere lo stesso ID (nome del proprietario), a tutti i fini pratici non ci sono due chiavi con lo stesso id di chiave.

PGP usa una "selezione del messaggio" per creare le firme. Una selezione del messaggio e' una funzione del messaggio formata da 128 bits. E' qualcosa di simile ad un checksum o al codice di controllo per gli errori di CRC. In essa PGP "rappresenta il messaggio", e serve per controllare se sono avvenuti cambiamenti. A differenza del CRC, pero', non e' pensabile che un estraneo riesca a sostituire il messaggio con un'altro che produca la stessa selezione. La selezione del messaggio viene cifrata con la chiave segreta per formare la firma.

I documenti sono firmati facendoli precedere dai certificati di firma, che contengono l'id di chiave della chiave usata per produrli, una selezione del messaggio firmata con la chiave segreta e il tempo in cui la firma e' stata fatta. L'id di chiave viene usato dal destinatario per trovare la chiave pubblica del mittente e controllare la firma. Il software del destinatario trova automaticamente la chiave pubblica e l'id di chiave nel portachiavi pubblico.

I file cifrati sono preceduti dall'id di chiave della chiave pubblica usata per cifrarli. Il destinatario usa questo id di chiave per trovare la chiave segreta richiesta per decifrare il messaggio. Il suo software la trova automaticamente nel portachiavi segreto.

Questi due tipi di portachiavi sono i metodi principali di conserva- zione e gestione delle chiavi pubbliche e private. Invece di tenere le singole chiavi in files separati, esse sono raccolte in portachiavi per facilitarne la ricerca automatica per id di chiave o ID. Ogni utilizzatore possiede la sua coppia di portachiavi. Una singola chiave pubblica e' tenuta in un file separato il tempo necessario per inviarla ad un vostro corrispondente che la aggiungera' al suo portachiavi.

Ritorno all'Indice

Installazione di PGP

Il pacchetto di PGP rilasciato per MSDOS e' compresso in un file archivio del tipo PGPxx.ZIP (ogni versione ha un numero diverso al posto di "xx"). Per esempio, il pacchetto relativo a PGP 2.6.2 si chiama PGP262.ZIP. L'archivio puo' essere decompresso usando il software shareware PKUNZIP per MSDOS, o con il comando "unzip" per Unix. Quando il pacchetto e' decompresso, ne escono molti files. Uno di essi, chiamato README.DOC, dovrebbe sempre essere letto prima di procedere all'installazione. Questo file contiene le notizie dell'ultimo minuto sulle novita' di quella versione, come pure informazioni sugli altri files compresi nel pacchetto.

Se avete gia' una versione precedente di PGP, dovreste rinominarla o cancellarla, per evitare conflitti .

Per i dettagli completi sull'installazione di PGP, si veda la guida dedicata, nel file SETUP.DOC incluso nel pacchetto di questa versione. Essa descrive dettagliatamente come devono essere preparati la directory che conterra' PGP ed il vostro file AUTOEXEC.BAT, e come utilizzare PKUNZIP per effettuare l'installazione. Verra' dato qui un breve sommario, nel caso siate troppo impazienti per leggere subito il manuale dettagliato.

Per installare PGP sul vostro sistema MSDOS, dovete copiare il file compresso PGPxx.ZIP nel vostro hard disk, in una directory che si presti alla bisogna (come c:\PGP)e decomprimerlo con PKUNZIP. Per ottenere risultati migliori dovreste anche modificare il vostro file AUTOEXEC.BAT, come descritto altrove in questa guida, ma potrete farlo piu' tardi, dopo aver provato PGP per un po' ed aver letto qualcosa in piu' in questo manuale. Se non avete mai usato PGP in precedenza, il primo passo dopo l'installazione (e la lettura di questo manuale), e' la generazione di una coppia di chiavi per voi stessi. Viene effettuata con il comando "pgp -kg". Leggete prima la sezione "Generazione della chiave RSA" del manuale.

L'installazione in ambiente Unix o VAX/VMS e' generalmente simile a quella in MSDOS, ma potreste prima dover compilare il codice sorgente. Un makefile Unix e' fornito a questo scopo con il pacchetto del sorgente.

Ritorno all'Indice

Uso di PGP

Ritorno all'Indice

Per vedere un indice veloce delle funzioni di PGP, battete:

pgp -h

Ritorno all'Indice

Per criptare un file in chiaro con la chiave pubblica del destinatario, battete:

pgp -e filetesto dest_ID

Questo comando produce un file cifrato chiamato filetesto.pgp. Per esempio:

pgp -e lettera.txt Alice
or:
pgp -e lettera.txt "Alice S"

Il primo esempio cerca nel vostro portachiavi pubblico "pubring.pgp" un certificato di chiave che contenga la stringa "Alice" nella sezione degli ID. Il secondo esempio cerchera' "Alice S". Non e' possibile usare spazi nelle stringhe, a meno che non le chiudiate fra virgolette. La ricerca non tiene conto di maiuscole/minuscole. Se viene trovata una chiave che corrisponda all'ID, PGP la usa per cifrare il file "lettera.txt" e produrre il file "lettera.pgp".

PGP tenta di comprimere il file in chiaro prima di cifrarlo, migliorando la resistenza alla criptoanalisi. Quindi e' probabile che il file cifrato sia piu' corto di quello in chiaro.

Se volete inviare questo messaggio cifrato per e-mail, convertitelo in formato ASCII "radix-64" aggiungendo l'opzione -a, come descritto piu' avanti.

Ritorno all'Indice

Se volete spedire lo stesso messaggio a piu' persone, potete indicare diversi destinatari, ognuno dei quali potra' decifrare lo stesso testo. Per fare questo basta aggiungere altri ID alla linea di comando. Cosi':

pgp -e lettera.txt Alice Bob Carol

Questo creera' il file cifrato lettera.pgp che potra' essere letto da Alice o Bob o Carol. Puo' essere indicato un numero qualunque di destinatari.

Ritorno all'Indice

Per firmare un file in chiaro con la vostra chiave segreta, battete:

pgp -s filetesto [-u mio_ID]

Si noti che le [parentesi] indicano che un parametro e' opzionale, quindi non inseritele nel comando.

Questo comando genera un file firmato chiamato filetesto.pgp. Esempio:

pgp -s lettera.txt -u Bob

PGP cerchera' un certificato di chiave nel vostro portachiavi segreto che contenga la stringa Bob nel campo ID. Naturalmente vi dovete chiamare Bob... La ricerca non tiene conto di maiuscole/minuscole. Se una chiave segreta corrispondente e' trovata, la si usa per firmare "lettera.txt" e produrre un file firmato "lettera.pgp".

Se non mettete il vostro ID, verra' usata la prima chiave del vostro portachiavi segreto.

PGP tenta di comprimere il messaggio dopo averlo firmato. E' quindi probabile che il file firmato sia piu' piccolo dell'originale, il che e' utile per le applicazioni di archivio. Pero', questo rende il file illeggibile anche se il messaggio originale era in chiaro. Sarebbe bello poter generare un file firmato, ma leggibile. Soprattutto se volete spedire un messaggio firmato via e-mail.

Per firmare un messaggio e-mail, dove e' probabile che vogliate sia leggibile, e' probabilmente meglio usare la funzione CLEARSIG, spiegata piu' avanti. Questo permette che la firma sia apposta in forma leggibile alla fine del testo, e disabilita la compressione. Il testo e' quindi leggibile anche se il destinatario non usa PGP per controllare la firma. Questa funzione e' spiegata in dettaglio nella sezione "CLEARSIG - Messaggi firmati inseriti come testo in chiaro" nel "Volume II - Funzioni avanzate". Se non potete attendere di aver letto quella sezione, potete vedere il risultato con questo esempio:

pgp -sta lettera.txt

PGP creera' un messaggio cifrato nel file "lettera.asc" con il testo originale leggibile ed un certificato di firma ASCII. Il messaggio potra' essere spedito per e-mail. Questo esempio suppone che usiate le impostazioni normali per abilitare il flag CLEARSIG nel file di configurazione.

Ritorno all'Indice

Per firmare un file in chiaro con la vostra chiave segreta, e poi cifrarlo con la chiave segreta del destinatario:

pgp -es filetesto dest_ID [-u mio_ID]

Si noti che le [parentesi] indicano che un parametro e' opzionale, quindi non inseritele nel comando.

Questo esempio produce un file annidato chiamato filetesto.pgp. La vostra chiave segreta per firmare e' trovata automaticamente nel portachiavi segreto. La chiave pubblica del destinatario e' trovata automaticamente nel portachiavi pubblico. Se non inserite il dest_ID nel comando, vi sara' richiesto.

Se non inserite il vostro ID, verra' usata la prima chiave del vostro portachiavi segreto.

Si noti che PGP tentera' di comprimere il testo prima di cifrarlo.

Se volete inviare questo messaggio cifrato via e-mail, convertitelo in formato ASCII "radix-64" aggiungendo l'opzione -a, come descritto piu' avanti.

Se volete spedire lo stesso messaggio a piu' persone, potete indicare diversi destinatari, ognuno dei quali potra' decifrare lo stesso testo.

Ritorno all'Indice

A volte vi serve solo cifrare un file con i vecchi sistemi, con la crittografia a chiave singola. Puo' essere utile per proteggere i vostri archivi che non verranno spediti a nessuno. Sara' la stessa persona che ha cifrato i files a doverli decifrare, quindi non servira' un sistema a chiave pubblica.

Per cifrare un file in chiaro con il sistema convenzionale, battere:

pgp -c filetesto

PGP creera' un file cifrato chiamato filetesto.pgp, senza usare crittografia a chiave pubblica, portachiavi, ID, o altre cose simili. Vi chiedera' una frase chiave da usare come chiave convenzionale. Non e' necessario che questa frase chiave sia la stessa che protegge la vostra chiave segreta (in effetti dovrebbe essere diversa). Si noti che PGP tentera' di comprimere il testo prima di cifrarlo.

PGP non cifrera' lo stesso testo due volte nello stesso modo, anche se userete sempre la stessa frase chiave.

Ritorno all'Indice

Per decifrare un file cifrato, o per verificare l'integrita' della firma:

pgp filecifrato [-o filechiaro]

Si noti che le [parentesi] indicano che un parametro e' opzionale, quindi non inseritele nel comando.

PGP assume che il file cifrato abbia estensione di default ".pgp". Il nome opzionale del file di uscita, specifica dove salvare il risultato decifrato. Se non e' specificato un nome, verra' usato il nome del file cifrato senza estensione. Se all'interno del file esiste una firma, questa e' decifrata e verificata, e viene visualizzato l'ID completo del mittente.

Si noti che l'"apertura" del file cifrato e' completamente automatica, sia che il file sia firmato, o cifrato, o ambedue le cose. PGP usa l'id di chiave che precede il testo cifrato per trovare la chiave segreta nel vostro portachiavi. Se c'e' una firma annidata, PGP usa l'id di chiave per trovare la chiave corrispondente nel vostro portachiavi pubblico. Se vengono trovate tutte le chiavi non e' richiesto nessun intervento, eccetto per l'inserimento della vostra frase chiave. Se il file e' cifrato convenzionalmente PGP richiede la frase chiave per decifrarlo convenzionalmente.

Ritorno all'Indice

Dai tempi di Giulio Cesare, la gestione delle chiavi e' sempre stata la parte piu' difficile della crittografia. Una delle caratteristiche che distinguono PGP e' la sua gestione sofisticata delle chiavi.

Ritorno all'Indice

Per generare la vostra coppia di chiavi pubblica/segreta di un formato specifico, battete:

pgp -kg

PGP vi presenta una scelta dei formati principali (sicurezza commerciale di basso livello, commerciale di alto livello, "militare") e vi chiede di scegliere il vostro formato, fino a 1024 bits. Piu' lunga e' la chiave, piu' siete al sicuro, ma pagate in velocita'.

Quindi vi chiede un ID, il vostro nome. E' buona norma usare il vostro nome completo, perche' ci sono meno rischi che altre persone usino una chiave pubblica errata nel cifrare messaggi per voi. Si possono usare spazi e punteggiatura. Sarebbe utile che voi inseriste il vostro indirizzo e-mail fra <parentesi "spigolose"> dopo il vostro nome, cosi':

Luigi Verdi <[email protected]>

Se non avete un indirizzo e-mail, usate il vostro numero di telefono, o qualunque altra informazione che renda il vostro ID unico.

PGP vi chiede quindi una "frase chiave" che proteggera' la vostra chiave segreta se cadra' nelle mani sbagliate. Nessuno puo' usare la vostra chiave segreta senza frase chiave. La frase chiave e' come una parola chiave, solo che puo' essere una frase completa di spazi, punteggiatura o qualunque altra cosa. Non perdete la frase chiave, perche' non c'e' nessun modo di recuperarla. Questa frase vi servira' ogni volta che dovrete usare la vostra chiave segreta. La frase tiene conto di maiuscole/minuscole, e non dovrebbe essere troppo corta o facile da indovinare. Non e' mai mostrata sullo schermo. Non lasciatela scritta in posti dove altri potrebbero vederla, e non memorizzatela nel vostro computer. Se non volete una frase chiave (pazzi!) premete solo enter quando vi viene richiesta.

La coppia di chiavi pubblica/segreta e' derivata da numeri molto casuali generati principalmente misurando l'intervallo fra le vostre battute con un timer veloce. PGP vi chiedera' di battere dei tasti a caso per permettergli di accumulare dei bits casuali per le chiavi. Quando vi verra' richiesto, dovrete battere alcuni tasti, ad intervalli ragionevolmente casuali, e non guasterebbe scegliere i caratteri irregolarmente. Parte della casualita' proviene dall'imprevedibilita' di cio' che batterete. Quindi non ripetete sequenze fisse di caratteri.

Si noti che la generazione di chiavi RSA e' un processo lento. Potra' richiedere pochi secondi per una chiave piccola su di un processore veloce, o alcuni minuti per una chiave lunga su di un IBM PC/XT. PGP vi indichera' la situazione della generazione in corso.

La coppia di chiavi generata sara' inserita nei vostri portachiavi pubblico e segreto. Voi potrete poi utilizzare il comando -kx per estrarre (copiare) la vostra nuova chiave pubblica dal portachiavi e piazzarla in un file per distribuirla ai vostri corrispondenti, che la inseriranno nei loro portachiavi. Naturalmente terrete la chiave segreta per voi e la dovreste inserire nel vostro portachiavi segreto. Ogni chiave segreta in un portachiavi e' protetta dalla sua specifica frase chiave.

Non date a nessuno la vostra frase segreta, e per lo stesso motivo non generate coppie di chiavi per i vostri amici. Ognuno dovrebbe generare le proprie. Mantenete sempre il controllo materiale della vostra chiave segreta e non rischiate di esporla mettendola in un computer remoto con piu' utilizzatori contemporanei. Tenetela nel vostro personal computer.

Se PGP non trova questa guida sul vostro computer e rifiuta di generare le chiavi, non agitatevi. Leggete la spiegazione del parametro NOMANUAL nella sezione "Preparare i parametri di configurazione" nel "Volume II - Funzioni avanzate".

Ritorno all'Indice

Volete aggiungere al vostro portachiavi una chiave che qualcuno vi ha dato sotto forma di file.

Per aggiungere il contenuto di un file di chiavi al vostro portachiavi pubblico o segreto (le [parentesi] indicano campi opzionali):

pgp -ka filechiavi [portachiavi]

L'estensione di default per il file di chiavi e' ".pgp". Il nome di default del portachiavi e' "pubring.pgp" o "secring.pgp", secondo il contenuto del file di chiavi. Voi potete specificare un portachiavi diverso, con estensione di default ".pgp"

Se la chiave e' gia' nel vostro portachiavi, PGP non la aggiungera' di nuovo. Tutte le chiavi presenti nel file saranno aggiunte, eccetto i duplicati.

Piu' avanti nel manuale verra' spiegato il concetto di certificazione di chiavi con le firme. Se la chiave da aggiungere ha delle firme collegate che la certificano, queste verranno aggiunte al portachiavi. Se la chiave e' gia' presente nel portachiavi, PGP aggiungera' le eventuali firme di certificazione che ancora non avete.

PGP e' stato progettato originalmente per maneggiare piccoli portachiavi. Se volete maneggiare quelli molto grandi, leggete la sezione "Maneggiare portachiavi molto grandi" del "Volume II - Funzioni avanzate"

Ritorno all'Indice

Per rimuovere una chiave od un ID dal vostro portachiavi pubblico:

pgp -kr ID [portachiavi]

PGP cerca l'ID specificato nel vostro portachiavi e lo rimuove. Ricordatevi che e' sufficiente anche solo una parte dell'ID per trovarlo. Si assume che il nome del portachiavi sia "pubring.pgp". Puo' essere omesso, potete inserire "secring.pgp" se volete eliminare una chiave segreta, o potete inserire il nome di un altro portachiavi. L'estensione di default e' ".pgp".

Se' esiste piu' di un ID per la chiave specificata, vi verra' richiesto se volete rimuovere solo quell'ID e lasciare gli altri e la chiave.

Ritorno all'Indice

Per estrarre (copiare) una chiave dal vostro portachiavi:

pgp -kx ID filechiavi [portachiavi]

PGP copia, senza distruggerle, le chiavi specificate dall'ID dal vostro portachiavi pubblico/segreto al file di chiavi specificato. E' particolarmente utile quando volete dare ad altri copia della vostra chiave pubblica.

Se la chiave ha delle firme di certificazione allegate, queste sono copiate assieme alla chiave.

Se volete che la chiave sia estratta in caratteri ASCII adatti ad essere spediti via e-mail, usate l'opzione -kxa.

Ritorno all'Indice

Per vedere il contenuto del vostro portachiavi:

pgp -kv[v] [ID] [portachiavi]

PGP mostra qualunque chiave del vostro portachiavi che contenga la stringa specificata nel campo ID. Se omettete l'ID, le mostra tutte. Si assume che il nome del portachiavi sia "pubring.pgp". Puo' essere omesso, potete inserire "secring.pgp" se volete vedere una chiave segreta, o potete inserire il nome di un altro portachiavi. L'estensione di default e' ".pgp".

Piu' avanti nel manuale verra' spiegato il concetto di certificazione delle chiavi con le firme. Per vedere tutte le firme di certificazione, usate l'opzione -kvv:

pgp -kvv [ID] [portachiavi]

Se volete specificare un nome di portachiavi, ma vedere tutte le chiavi contenute, provate questa alternativa:

pgp filechiavi

Senza specificare opzioni, PGP mostra tutte le chiavi in filechiavi.pgp, e cerca di aggiungerle al vostro portachiavi, se non sono gia' presenti.

Ritorno all'Indice

In un sistema di crittografia a chiave pubblica, non dovete proteggere le chiavi pubbliche dall'esposizione. In effetti e' meglio che siano diffuse capillarmente. E' importante pero' proteggere le chiavi dalla manomissione, per essere sicuri che una chiave pubblica appartenga realmente al suo supposto proprietario. Questo puo' essere il punto piu' vulnerabile del sistema a chiave pubblica. Ipotizziamo un potenziale disastro, e poi vediamo come evitarlo con PGP.

Supponiamo che vogliate mandare un messaggio ad Alice. Vi procurate la sua chiave pubblica da una BBS. Cifrate la vostra lettera e la inviate via e-mail.

Sfortunatamente, senza che voi od Alice lo sapeste, un altro utente di nome Charlie si e' infiltrato nella BBS ed ha generato una sua chiave pubblica usando l'ID di Alice. Di nascosto ha sostituito la sua chiave a quella di Alice. Quindi voi avete la chiave generata da Charlie e pensate sia di Alice. Tutto sembra normale, poiche' la chiave fasulla ha l'ID di Alice. Ora Charlie puo' decifrare il messaggio diretto ad Alice perche' ha la chiave segreta associata. Potrebbe anche ricifrarlo con la vera chiave pubblica di Alice e rimandarglielo. Nessuno potrebbe sospettare alcunche'. Ancora peggio, Charlie potrebbe produrre delle firme di Alice apparentemente valide, perche' tutti userebbero la chiave pubblica fasulla per verificarle.

L'unico modo per prevenire questo disastro, e' quello di impedire a chiunque di manomettere le chiavi pubbliche. Se voi ricevete la chiave pubblica di Alice direttamente da Alice, nessun problema. Potrebbe pero' essere complicato se Alice abitasse a 1000 km di distanza, o non fosse comunque raggiungibile subito.

Forse potreste ricevere la chiave pubblica di Alice da un comune amico fidato, David, che sa di averne una copia autentica. David potrebbe firmare la chiave di Alice, garantendone l'integrita'. David creerebbe la firma con la propria chiave segreta.

Questo creerebbe un certificato di chiave pubblica firmato, e mostrerebbe che la chiave di Alice non e' stata manomessa. Naturalmente voi dovete avere una copia valida della chiave di David per controllare la sua firma. Forse David puo' anche fornire ad Alice una copia firmata della vostra chiave pubblica. David e' il "presentatore" tra voi ed Alice.

Il certificato di chiave pubblica firmato di Alice puo' essere caricato da David o da Alice nella BBS, e voi potete ritrovarlo piu' tardi. Poi potete controllare la firma con la chiave pubblica di David ed essere sicuro che sia veramente la chiave pubblica di Alice. Nessun impostore puo' indurvi ad accettare una chiave fasulla di Alice, perche' nessuno puo' falsificare la firma di David.

Una persona notoriamente fidata potrebbe perfino specializzarsi in questo servizio di "presentazione" tramite certificati di chiave pubblica firmati. Questa persona sarebbe un "gestore di chiavi", o un'"Autorita' di Certificazione". Ogni certificato di chiave pubblica recante la firma del gestore di chiavi potrebbe essere considerato come veramente appartenente al proprietario dichiarato. Tutti gli utilizzatori interessati avrebbero solo bisogno di una copia autentica della chiave pubblica del gestore di chiavi, per poter verificare la sua firma.

Un gestore di chiavi fidato centralizzato o un'Autorita' di Certificazione e' particolarmente appropriato per grandi, impersonali organizzazioni controllate dal centro, o per le istituzioni governative. Alcuni ambienti istituzionali usano delle gerarchie di Autorita' di Certificazione.

Per ambienti piu' decentralizzati e terra terra, stile "guerriglia", probabilmente funzionerebbe meglio permettere a qualunque utente di garantire per i propri amici. PGP tende ad enfatizzare questo approccio organico non istituzionale e decentralizzato. Riflette maggiormente il modo in cui gli esseri umani interagiscono fra loro nei normali rapporti sociali, e permette alle persone di scegliere quali sono le persone di cui si fidano per la gestione delle chiavi.

Questo grosso problema della protezione delle chiavi pubbliche dalle manomissioni e' il problema piu' importante nell'applicazione pratica del sistema. E' il tallone di Achille della crittografia a chiave pubblica, e buona parte della complessita' del software e' dovuta alla necessita' di affrontarlo.

Bisognerebbe usare una chiave pubblica solo quando si e' sicuri che sia originale e non manomessa, ed appartenga veramente al proprietario dichiarato. Potete essere sicuri di questo se ricevete la chiave direttamente dal proprietario, o se porta la firma di qualcuno di cui vi fidate e di cui gia' possedete una chiave pubblica sicura. Inoltre l'ID dovrebbe contenere il nome completo del proprietario della chiave, e non solo il nome di battesimo.

Non importa quanto siate tentati-- e sarete tentati-- : mai, MAI cedere e fidarvi di una chiave pubblica ricevuta da una BBS se non e' firmata da qualcuno di cui vi fidate. Una chiave pubblica non certificata puo' essere stata manomessa da chiunque, forse perfino dall'amministratore della BBS.

Se vi viene chiesto di firmare la chiave pubblica di qualcuno, assicuratevi che appartenga veramente al proprietario dichiarato nell'ID. Questo perche' con la vostra firma garantite personalmente che la chiave e' genuina. Altre persone che si fidano di voi accetteranno quella chiave perche' porta la vostra firma. Sarebbe sbagliato fidarvi di un "sentito dire". Non firmate quella chiave fino a quando non avrete prove indipendenti e di prima mano che sia genuina. Possibilmente dovreste firmarla solo se l'avete ricevuta direttamente dal proprietario.

Per firmare una chiave pubblica, dovete essere molto piu' sicuri della sua autenticita' di quando volete solo usarla per cifrare un messaggio. Per essere convinti della genuinita' di una chiave abbastanza da usarla, dovrebbero essere sufficienti le firme di certificazione di persone fidate che la accompagnano. Per firmarla voi pero', dovreste ottenere una vostra conoscenza personale di prima mano di questa genuinita'. Forse potreste telefonare al proprietario e (naturalmente essendo sicuri di parlare con la persona giusta) leggergli la chiave per ottenerne conferma. Per i dettagli vedere la sezione "Verifica di una chiave attraverso il telefono" del "Volume II - Funzioni avanzate".

Tenete in mente che la vostra firma sulla chiave pubblica di una persona non garantisce l'integrita' di quella persona, bensi' l'integrita' (la proprieta') della sua chiave. Voi non rischiate la vostra credibilita' firmando la chiave di uno psicopatico, se avete piena conoscenza che la chiave appartiene a lui. Altre persone accetteranno quella chiave come appartenente a lui perche' voi l'avete firmata, ma non si fideranno di lui. Fidarsi di una chiave non significa automaticamente fidarsi del suo proprietario.

La fiducia non e' necessariamente trasferibile; io ho un amico fidato e so che non mente. E' una persona influenzabile che crede che il Presidente non menta. Questo non significa che io creda che il Presidente non menta. E' solo questione di buon senso. Se io mi fido della firma di Alice su una chiave, ed Alice si fida della firma di Charlie su una chiave, questo non implica che io mi debba fidare della firma di Charlie su una chiave.

Sarebbe buona cosa tenere la vostra chiave pubblica assieme ad una buona collezione di firme di certificazione di diversi "presentatori", nella speranza che la maggioranza delle persone si fidera' di almeno uno fra coloro che garantiscono la validita' della chiave. Voi potrete distribuire la vostra chiave assieme a questa collezione di firme nelle varie BBS. Se firmerete la chiave di altri, rispeditela con la vostra firma, cosi' che i proprietari possano aggiungerla alla propria collezione di credenziali.

PGP tiene conto di quali chiavi nel vostro portachiavi pubblico sono adeguatamente certificate con firme di presentatori di cui vi fidate. Tutto cio' che dovete fare e' dire a PGP di quali persone vi fidate come presentatori e certificare voi stessi le loro chiavi con la vostra firma. PGP da qui' validera' automaticamente tutte le chiavi firmate da questi presentatori. Naturalmente potete anche firmare voi direttamente delle chiavi. Altri dettagli piu' avanti.

Siate sicuri che nessun altro possa manomettere il vostro portachiavi pubblico. Il controllo di un certificato di chiave firmato, alla fine dipende dall'integrita' della chiave pubblica fidata che appare gia' nel vostro portachiavi. Mantenete il controllo fisico del vostro portachiavi pubblico, preferibilmente tenendolo nel vostro PC piuttosto che in un sistema remoto con piu' utilizzatori contemporanei, proprio come dovreste fare con la vostra chiave segreta. Nel caso del portachiavi pubblico pero', si tratta di proteggerlo dalla manomissione, non dall'apertura. Tenete una copia di backup sicuramente valida dei vostri portachiavi su di un supporto protetto da scrittura.

Siccome la vostra propria chiave pubblica e' l'autorita' suprema che, direttamente od indirettamente, certifica tutte le altre chiavi del vostro portachiavi, essa e' la chiave piu' importante da proteggere dalla manomissione. Per rilevare ogni manomissione su di essa, PGP puo' essere predisposto per compararla con una copia di backup su supporto protetto da scrittura. Per i dettagli vedere la descrizione del comando "-kc" nel "Volune II - Funzioni avanzate".

PGP in generale presume che voi manteniate la sicurezza fisica del vostro sistema, dei vostri portachiavi e del PGP stesso. Se un abusivo puo' manomettere il vostro disco, in teoria puo' manomettere lo stesso PGP, disabilitando i controlli che esso puo' fare per verificare la manomissione delle vostre chiavi.

Un sistema in un certo senso complicato per proteggere il vostro portachiavi pubblico dalle manomissioni puo' essere quello di firmarlo con la vostra chiave segreta. Potete creare un certificato di firma staccato del portachiavi pubblico, firmandolo con l'opzione "-sb" (si veda la sezione "Firme separate dai messaggi" nel "Volume II - Funzioni avanzate"). Sfortunatamente, dovrete sempre tenere una copia fidata separata della vostra chiave pubblica per poter verificare la vostra firma. Non potete fidarvi della vostra chiave pubblica presente nel portachiavi pubblico per verificare il portachiavi pubblico stesso. Essa fa parte di cio' che volete verificare.

Ritorno all'Indice

Prima di leggere questa sezione dovete aver letto quella precedente: "Come proteggere il vostro portachiavi pubblico dalle manomissioni"

PGP tiene conto di quali chiavi pubbliche nel vostro portachiavi sono adeguatamente certificate da firme fidate. Tutto cio' che dovete fare e' dire a PGP quali sono le persone di cui vi fidate come presentatori, e certificare voi stessi le loro chiavi con la vostra firma. PGP quindi valida tutte le chiavi firmate da queste persone. Ovviamente voi stessi potete firmare delle chiavi.

Esistono due criteri separati che PGP usa per giudicare l'utilita' di una chiave pubblica. Attenzione a non confonderli:

1) La chiave appartiene veramente al proprietario dichiarato? In altre parole, e' certificata da una firma fidata?
2) Appartiene a qualcuno di cui vi fidate come presentatore?

Mentre PGP puo' ricavare la risposta alla prima domanda, siete voi a dover fornire la risposta alla seconda. Avendo la risposta alla domanda 2, PGP puo' ricavare la risposta 1 per le chiavi firmate da persone indicate come fidate.

Le chiavi certificate da presentatori fidati sono considerate valide da PGP. Le chiavi appartenenti a presentatori fidati devono esse stesse essere certificate da voi o da altri presentatori fidati.

PGP vi da' anche la possibilita' di assegnare vari gradi di affidabilita' ai presentatori. La vostra fiducia in un proprietario di chiave per agire come presentatore non riflette semplicemente la vostra stima dell'integrita' di quella persona-- deve anche considerare la vostra valutazione della sua competenza nel capire la gestione delle chiavi e decidere se firmarle. Voi potete dire a PGP che una persona e' sconosciuta, non fidata, abbastanza fidata o completamente fidata per cio' che riguarda la certificazione di chiavi. Questa informazione e' conservata nel vostro portachiavi assieme alle chiavi corrispondenti, ma quando copiate delle chiavi dal vostro portachiavi pubblico queste informazioni non vengono estratte, perche' le vostre opinioni personali sono confidenziali.

Quando PGP calcola la validita' di una chiave, esamina il livello di affidabilita' di tutte le firme collegate. Calcola un punteggio pesato di validita'-- 2 firme abbastanza fidate sono considerate credibili come una firma completamente affidabile. Lo scetticismo di PGP e' regolabile-- per esempio, potreste richiedere 2 firme completamente affidabili o 3 parzialmente affidabili per validare una chiave.

La vostra chiave e' "assiomaticamente" valida per PGP, e non richiede firme per essere considerata valida. PGP sa qual e' la vostra chiave pubblica perche' trova quella segreta corrispondente nel vostro portachiavi segreto. PGP presume che voi vi fidiate di voi stessi come certificatori di altre chiavi.

Col passare del tempo accumulerete chiavi di altre persone, e vorrete poterle indicare come presentatori fidati. Cosi' faranno tutti gli altri utenti. Quindi ognuno gradualmente accumulera' e distribuira' una collezione di certificati della propria chiave, nella speranza che ogni persona che la ricevera' si fidera' almeno di una o due firme fra quelle presenti. Questo causera' lo sviluppo di un sistema decentralizzato di fiducia per tutte le chiavi pubbliche.

Questo approccio popolare contrasta fortemente con gli schemi standard di gestione delle chiavi pubbliche del Governo, come il PEM (Privacy Enhanced Mail), che sono basati sul controllo centrale e sulla fiducia centralizzata obbligatoria. Gli schemi standard si basano su di una gerarchia di Autorita' di Certificazione che vi impongono le persone di cui dovete fidarvi. Il metodo probabilistico decentralizzato di PGP per determinare la legittimita' delle chiavi pubbliche e' l'elemento centrale della sua gestione delle chiavi. PGP permette solo a voi di decidere di chi vi fidate, mettendovi al vertice della vostra propria piramide di certificatori. PGP e' per le persone che preferiscono piegare personalmente il proprio paracadute.

Ritorno all'Indice

Proteggete attentamente la vostra chiave segreta e la vostra frase chiave. Molto, molto attentamente. Se la vostra chiave segreta viene compromessa spargete subito la voce fra tutte le persone interessate (buona fortuna) prima che qualcuno usi la vostra chiave per firmare a vostro nome. Per esempio potrebbero usarla per firmare delle chiavi pubbliche fasulle, creando problemi per molte persone, soprattutto se la vostra firma e' ritenuta fidata da molti utenti. Inoltre la compromissione della vostra chiave segreta renderebbe naturalmente vulnerabili tutti i messaggi che vi vengono inviati.

Per proteggere la vostra chiave segreta potete cominciare col mantenerne il controllo fisico. Tenerla nel vostro PC a casa va bene, cosi' come nel notebook che vi portate appresso. Se dovete usare un PC sul lavoro e non ne avete il controllo fisico continuo, tenete la chiave in un floppy disk protetto da scrittura, e non lasciatelo in giro quando lasciate l'ufficio. Non e' una buona idea lasciare la vostra chiave in un sistema remoto con piu' utenti contemporanei, come una rete Unix. Qualcuno potrebbe sorvegliare la vostra linea e catturare la vostra frase chiave, quindi ottenere la vostra chiave segreta dal sistema remoto. Dovreste usare la vostra chiave segreta solo su di una macchina su cui mantenete il controllo fisico.

Non scrivete la vostra frase chiave da nessuna parte sul computer che contiene il vostro portachiavi segreto. Mettere chiave segreta e frase chiave nello stesso computer sarebbe come scrivere il numero segreto della tessera Bancomat sulla tessera stessa. Voi non volete che qualcuno possa accedere ad un disco che contenga frase chiave e chiave segreta. Sarebbe piu' sicuro se memorizzaste la frase chiave e non la registraste da nessuna parte che non sia il vostro cervello. Se ritenete di doverla scrivere, proteggetela bene, forse meglio del portachiavi segreto.

Tenete copie di backup del vostro portachiavi segreto-- ricordatevi che ne possedete l'unica copia, e perderla renderebbe inutili tutte le copie della vostra chiave pubblica che avete distribuito per il mondo.

L'approccio decentralizzato non istituzionale di PGP alla gestione delle chiavi pubbliche ha i suoi vantaggi, ma implica purtroppo il non poter fare riferimento ad una lista centralizzata di chiavi compromesse. Questo rende un po' piu' difficile contenere il danno provocato da una chiave segreta compromessa. Potete solo spargere la voce e sperare che tutti la sentano.

Nella situazione peggiore-- chiave segreta e frase chiave entrambe compromesse (si spera che in qualche modo ve ne accorgiate)-- dovrete generare un certificato di "chiave compromessa". Questo certificato serve ad avvisare le altre persone di smettere di usare la vostra chiave pubblica. Potete creare questo certificato con PGP usando il comando "-kd". Dovrete in qualche modo inviare questo certificato a tutti gli utilizzatori, o almeno agli amici, agli amici degli amici, ecc.. Il loro PGP installera' questo certificato nel loro portachiavi pubblico e impedira' automaticamente l'uso accidentale della vostra chiave pubblica per sempre. Voi potrete poi generare una nuova coppia di chiavi pubblica/segreta e pubblicare la nuova chiave pubblica. Potreste anche distribuire un pacchetto contenente la vostra nuova chiave pubblica ed il certificato di compromissione di quella vecchia.

Ritorno all'Indice

Supponete che la vostra chiave segreta e la vostra frase chiave siano entrambe compromesse. Dovete spargere la voce nel resto del mondo, in modo che tutti smettano di usare la vostra chiave pubblica. Per fare questo dovete generare un certificato di "chiave compromessa" o "chiave revocata" per revocarla.

Per generare un certificato di revoca della vostra chiave, usate il comando -kd:

pgp -kd mio_ID

Questo certificato reca la vostra firma fatta con la chiave che volete revocare. Dovreste distribuirlo capillarmente appena possibile. Altre persone che lo riceveranno potranno aggiungerlo al proprio portachiavi pubblico e PGP impedira' loro di usare ancora accidentalmente la vostra vecchia chiave. A questo punto potrete generare una nuova coppia di chiave pubblica/segreta.

Potreste decidere di revocare la vostra chiave per ragioni diverse dalla compromissione della chiave segreta. Usate lo stesso procedimento.

Ritorno all'Indice

Normalmente, se volete revocare la vostra chiave, potete usare il comando "-kd" per generare un certificato di revoca firmato con la stessa chiave (si veda "Revocare una chiave pubblica").

Cosa potete fare se avete perso la vostra chiave segreta o se e' stata distrutta? Non potete revocarla voi, perche' dovreste usare proprio quella chiave, e non ne siete piu' in possesso. Una versione futura di PGP offrira' un metodo piu' sicuro per revocare chiavi in queste circostanze, permettendo ai presentatori fidati di dichiarare che una chiave e' stata revocata. Per ora dovrete spargere la voce con qualunque mezzo informale conosciate, chiedendo agli utilizzatori di "disabilitare" la vostra chiave nei loro portachiavi pubblici.

Gli altri utilizzatori possono disabilitare la vostra chiave pubblica nei propri portachiavi pubblici con il comando "-kd". Se si specifica un ID che non corrisponde ad una chiave segreta nel portachiavi segreto, il comando -kd cerca l'ID nel portachiavi pubblico e contrassegna la chiave come disabilitata. Una chiave disabilitata non puo' essere usata per cifrare messaggi e non puo' essere estratta con il comando -kx. Puo' ancora essere usata per controllare una firma, ma viene visualizzato un richiamo. Se l'utilizzatore cerca di aggiungere di nuovo la stessa chiave al proprio portachiavi pubblico, non gli e' permesso perche' la chiave disabilitata e' gia' presente. Queste funzioni combinate aiutano a limitare la successiva diffusione di una chiave disabilitata.

Se la chiave pubblica specificata e' gia' disabilitata, il comando -kd vi chiedera' se volete riabilitarla.

Ritorno all'Indice

Funzioni avanzate

La maggior parte delle "Funzioni avanzate" e' descritta nel "Volume II - Funzioni avanzate". Eccone pero' alcune che meritano di essere citate qui.

Ritorno all'Indice

Molti sistemi di posta elettronica accettano solo testo ASCII, e non i dati binari ad 8 bits che costituiscono il testo cifrato. Per superare il problema, PGP supporta il formato ASCII radix-64 per testi cifrati, simile al formato PEM (Privacy Enhanced Mail) per Internet, cosi' come al formato Internet MIME. Questo formato speciale rappresenta i dati binari utilizzando solo caratteri ASCII stampabili, sicche' e' utile per trasmettere file cifrati binari tramite canali a 7 bits o per inviare dati binari come testo di e-mail. Questo formato si comporta come una forma di "armatura di trasporto" che protegge il testo contro i danni causati dal viaggio attraverso i vari sistemi od Internet. PGP aggiunge anche un CRC per verificare eventuali errori di trasmissione.

Il formato radix-64 converte il testo espandendo gruppi di 3 bytes binari da 8 bits in 4 caratteri ASCII stampabili, sicche' il file cresce di circa il 33%. Questa espansione non e' cosi' grave, poiche' il file e' gia' stato probabilmente compresso di piu' prima di essere cifrato.

Per produrre un file cifrato in formato ASCII radix-64, aggiumgere l'opzione "a" quando si cifra o si firma un messaggio, cosi':

pgp -esa lettera.txt dest_ID

Questo esempio produce un file cifrato "lettera.asc" contenente dati in formato ASCII radix-64 simile al MIME. Questo file puo' essere maneggiato da qualunque editor di testo per essere trasmesso via e-mail.

La decifrazione di un messaggio con armatura di trasporto radix-64 e' uguale a quella normale. Esempio:

pgp lettera

PGP cerca automaticamente il file ASCII "lettera.asc" prima di cercare "lettera.pgp". Riconosce che il file e' in formato radix-64 e lo riconverte in binario prima di processarlo normalmente, producendo un file cifrato temporaneo ".pgp". Il risultato finale e' un file in chiaro, esattamente come il messaggio originale "lettera.txt".

La maggior parte dei servizi e-mail su Internet proibisce l'invio di messaggi piu' lunghi di 50000 o 65000 bytes. I messaggi piu' lunghi devono essere spezzati in blocchi piu' piccoli da spedire separatamente. Se il vostro messaggio e' molto lungo e voi richiedete il formato radix-64, PGP lo spezza in blocchi sufficientemente piccoli da poter essere spediti. I blocchi sono posti in files con estensione ".as1", ".as2", ".as3", ecc. Il destinatario dovra' concatenare questi files nel giusto ordine in un unico file piu' grande. Durante la decifrazione, PGP ignorera' tutto il testo estraneo non compreso nei blocchi di messaggio radix-64.

Se volete inviare una chiave pubblica a qualcuno usando il formato radix-64, aggiungete l'opzione -a quando estraete la chiave dal portachiavi.

Se dimenticate di usare l'opzione -a quando cifrate un testo o estraete una chiave, potete ancora convertire il file in radix-64 semplicemente usando l'opzione -a da sola, senza richiedere nessuna cifratura. PGP convertira' il vostro file in un file ".asc".

Se firmate un testo in chiaro senza cifrarlo, PGP lo comprimera' dopo averlo firmato, rendendolo illeggibile. Questo va bene per applicazioni di archiviazione di files firmati. Se pero' volete inviare il file per e-mail, ed il file e' in formato testo (non binario); e' possibile inviarlo senza comprimerlo ed applicare l'armatura ASCII solo alla firma. Questo rende possibile al destinatario leggere il messaggio senza l'aiuto di PGP. Naturalmente PGP servira' per controllare la firma. Per maggiori informazioni su questa funzione, si veda la spiegazione del parametro CLEARSIG nella sezione "Preparare i parametri di configurazione" nel "Volume II - Funzioni avanzate".

Se voleste inviare un file binario per e-mail senza cifrarlo o firmarlo, potreste utilizzare uuencode, come fanno molti. PGP puo' anche svolgere questa funzione, usando l'opzione -a da sola, e svolge un lavoro migliore di uuencode. Per i dettagli, si veda la sezione "Usare PGP come un uuencode migliore", nel "Volume II - Funzioni avanzate."

Ritorno all'Indice

PGP utilizza per il suo funzionamento diversi files speciali, come i vostri portachiavi, il file di numeri casuali "randseed.bin", il file di configurazione "config.txt" (o "pgp.ini", o ".pgprc"), ed il file di traduzione "language.txt". Questi files possono essere tenuti in qualsiasi directory, inserendone il nome nella variabile di ambiente "PGPPATH". Per esempio in ambiente MSDOS, il comando:

SET PGPPATH=C:\PGP

dice a PGP che il nome del vostro portachiavi pubblico e' "C:\PGP\pubring.pgp". Ovviamente se questa directory esiste. Usate il vostro editor di testo preferito per modificare il vostro file AUTOEXEC.BAT in MSDOS in modo che assegni automaticamente il valore giusto della variabile all'avviamento del sistema. Se PGPPATH non e' definita, PGP cerchera' i files speciali nella directory corrente.

Ritorno all'Indice

PGP ha dei parametri impostabili dall'utente che possono essere definiti in uno speciale file di configurazione chiamato "config.txt", situato nella directory definita in PGPPATH. Questo file permette all'utente di definire diversi flags e parametri che verranno utilizzati da PGP senza dover sempre essere immessi nella linea di comando.

Per poter essere compatibile con i diversi sistemi operativi, il file puo' anche essere chiamato ".pgprc" in ambiente Unix, o "pgp.ini" in ambiente MSDOS.

Con questi parametri di configurazione, potete ad esempio stabilire dove PGP salvera' i suoi files temporanei, che lingua PGP utilizzera' per dare istruzioni e messaggi, oppure potrete stabilire il livello di scetticismo di PGP nel determinare la validita' di una chiave dalle firme di certificazione.

Per maggiori dettagli su questo file di configurazione, si veda la sezione relativa nel "Volume II - Funzioni avanzate.

Ritorno all'Indice

Vulnerabilita'

Nessun sistema di sicurezza e' inviolabile. PGP puo' essere reso non efficace in molti modi. Le vulnerabilita' potenziali di cui dovreste tener conto, comprendono la compromissione della vostra chiave segreta o della vostra frase chiave, la manomissione della vostra chiave pubblica, i files che dopo essere stati cancellati esistono ancora da qualche parte sul disco, i virus ed i cavalli di Troia, le falle nel vostro sistema di sicurezza, le emissioni elettromagnetiche, l'esposizione tipica dei sistemi multiutente, l'analisi del traffico, e forse anche l'analisi crittografica.

Per un'analisi dettagliata di questi punti, si veda la sezione "Vulnerabilita'" nel "Volume II - Funzioni avanzate"

Ritorno all'Indice

Attenzione all'"olio di serpente"

Quando si esamina un programma di crittografia, rimane sempre la domanda: perche' dovrei fidarmi di questo prodotto? Anche se esaminate direttamente il codice sorgente, non tutti abbiamo un'esperienza sufficiente in crittografia per poter giudicare il livello di sicurezza. Anche se siete un crittografo esperto, possono ancora sfuggirvi delle piccole debolezze degli algoritmi.

Quando ero al college all'inizio degli anni 70, sviluppai quello che credevo fosse uno schema brillante di crittografia. Una serie di numeri pseudo casuali veniva aggiunta al testo in chiaro per creare il testo cifrato. Questo avrebbe presumibilmente ingannato qualunque sistema di analisi in frequenza del testo cifrato, e sarebbe stato inviolabile anche dalle agenzie di Informazione Governative piu' ricche di risorse. Ero cosi' compiaciuto della mia realizzazione. Cosi' stupidamente sicuro.

Anni dopo, scoprii lo stesso schema in diversi testi introduttivi alla crittografia. Che bello. Altri crittografi avevano pensato allo stesso schema. Sfortunatamente lo schema era presentato come un semplice esercizio su come utilizzare le tecniche di analisi crittografica elementare per violarlo in modo triviale. Il mio brillante schema.

Da questa esperienza mortificante imparai quanto fosse facile cadere in un falso senso di sicurezza fidandosi di un algoritmo di crittografia. La maggior parte delle persone non capisce quanto sia difficile sviluppare un algoritmo che possa affrontare un attacco prolungato e determinato da parte di un avversario ricco di risorse. Molti sviluppatori software di grido hanno realizzato schemi di crittografia ingenui come il mio (spesso proprio lo stesso), ed alcuni di loro lo hanno inserito in pacchetti software commerciali di crittografia e venduto per denaro a migliaia di utilizzatori fiduciosi.

E' come vendere cinture di sicurezza per automobile che sembrano ottime ma si strappano in occasione del piu' piccolo urto. Dipendere da loro puo' essere peggio che non indossare del tutto le cinture. Nessuno sospetta che siano inaffidabili fino al primo incidente. Dipendere da un software crittografico debole puo' portarvi a mettere a rischio senza saperlo informazioni importanti. Non l'avreste fatto se non aveste avuto del tutto un software crittografico. Addirittura potreste non scoprire mai che i vostri dati sono stati compromessi.

A volte i pacchetti commerciali usano il DES (Federal Data Encription Standard), un algoritmo commerciale abbastanza buono raccomandato dal Governo per l'uso commerciale (ma non per le informazioni classificate, stranamente-- hmmm). Ci sono diversi "modi operativi" nel DES, alcuni migliori di altri. Il Governo raccomanda specificamente di non usare il modo piu' semplice e debole, l'ECB (Electronic Codebook). Raccomanda invece di usare i piu' robusti e complessi CFB (Cipher Feedback) e CBC (Cipher Block Chaining).

Sfortunatamente la maggior parte dei pacchetti commerciali di crittografia che ho visto usa il modo ECB. Parlando con gli autori di queste implementazioni, ho saputo che non avevano mai sentito nominare CBC o CFB, e non sapevano niente della debolezza dell'ECB. Il fatto che essi non avessero imparato abbastanza sulla crittografia per conoscere questi concetti elementari non e' rassicurante. A volte gestiscono anche le chiavi in maniera impropria o insicura. In piu' questi pacchetti contengono spesso un secondo algoritmo piu' veloce da utilizzare al posto del piu' lento DES. L'autore del pacchetto spesso crede che il suo algoritmo sia sicuro come il DES, ma dopo poche domande, di solito scopro che e' solo una variazione del mio brillante schema dei tempi del college. A volte non mi rivelano neppure come il loro algoritmo funziona, ma mi assicurano che e' uno schema brillante e che devo fidarmi. Io sono sicuro che loro credano che l'algoritmo sia brillante, ma come posso saperlo senza vederlo?

In tutta franchezza devo sottolineare che nella maggior parte dei casi questi prodotti terribilmente deboli non sono venduti da societa' specializzate in tecnologia crittografica.

Perfino i pacchetti di software veramente buoni, che usano il DES nel modo corretto, hanno ancora dei problemi. Il DES standard utilizza una chiave di 56 bits, troppo pochi per gli standard odierni, che puo' essere violata facilmente con metodi di ricerca intensiva e macchine ad alta velocita'. Il DES ha raggiunto la fine della sua vita utile, e cosi' e' per ogni software basato su di esso.

Una ditta di nome AccessData (87 East 600 South, Orem, Utah 84058, tel. +1-800-658-5199) vende per 185$ un pacchetto che viola gli schemi di crittografia usati da WordPerfect, Lotus 1-2-3, MS Excel, Symphony, Quattro Pro, Paradox e MS Word 2. Esso non si limita ad indovinare la parola chiave, ma esegue una vera analisi crittografica. Alcune persone lo comprano dopo aver dimenticato la parola chiave per accedere ai propri files. Le forze di Polizia comprano lo stesso pacchetto per poter leggere i files che sequestrano. Ho parlato con Eric Thompson, l'autore, e mi ha detto che il programma impiega una frazione di secondo per rompere il codice, ma che lui ha inserito dei ritardi per non farlo sembrare troppo facile. Mi ha anche detto che la parola chiave opzionale di PKZIP puo' spesso essere violata facilmente, e che le forze di Polizia hanno usufruito sovente di questo servizio fornito da un altro venditore.

In un certo senso, la crittografia e' come un farmaco. La sua integrita' e' fondamentale. La penicillina guasta ha lo stesso aspetto di quella buona. Voi potete giudicare se il vostro programma di contabilita' sbaglia, ma come potete dire se il vostro programma di crittografia e' debole? Il testo cifrato prodotto da un algoritmo debole ha lo stesso aspetto di quello prodotto da un algoritmo forte. C'e' un mucchio di olio di serpente in vendita. Un mucchio di cure "miracolose". Solo che, a differenza dei venditori di medicine dei vecchi tempi, gli sviluppatori di software normalmente non sanno che cio' che usano e' olio di serpente. Possono essere degli ottimi tecnici, ma di solito non hanno letto niente della letteratura accademica sulla crittografia. Pero' pensano di poter scrivere del buon software crittografico. E in fondo, perche' no? Dopo tutto sembra intuitivamente facile, ed il loro software sembra funzionare bene.

Chiunque pensi di aver sviluppato uno schema di cifratura inattaccabile, puo' essere un genio incredibilmente raro, oppure e' ingenuo ed inesperto. Sfortunatamente devo trattare a volte con degli aspiranti crittografi che vogliono apportare "miglioramenti" a PGP aggiungendo degli algoritmi di cifratura sviluppati da loro.

Ricordo una conversazione con Brian Snow, un crittografo di alto livello della NSA. Mi disse che non si sarebbe mai fidato di un algoritmo di cifratura sviluppato da qualcuno che non si fosse fatto le ossa spendendo un mucchio di tempo a violare codici. Questo ha molto senso. Io osservai che praticamente nessuno sviluppatore commerciale poteva qualificarsi secondo questo criterio. "Esatto" mi rispose sorridendo, "e questo rende il nostro lavoro alla NSA molto piu' semplice". Un pensiero raggelante. Neanche io sono qualificato.

Anche il Governo ha distribuito olio di serpente. Dopo la seconda guerra mondiale, gli Stati Uniti hanno venduto le macchine cifratrici tedesche Enigma ad alcuni governi del terzo mondo. Non e' stato pero' detto loro che gli Alleati avevano gia' violato il codice Enigma durante la guerra, fatto che e' rimasto classificato per molti anni. Ancora oggi molti sistemi Unix in tutto il mondo usano la cifratura Enigma per i files, in parte anche perche' il Governo ha creato ostacoli legali all'uso di algoritmi migliori. Hanno anche tentato di impedire la prima pubblicazione nel 1972 dell'algoritmo RSA. Inoltre hanno di fatto spento sul nascere qualunque sforzo commerciale volto a sviluppare telefoni effettivamente sicuri per l'uso generale.

Il lavoro principale della NSA consiste nella raccolta di informazioni (si veda il libro di James Bamford, "The Puzzle Palace"). La NSA ha accumulato capacita' e risorse per violare codici. Se le persone non possono accedere a sistemi crittografici di qualita' per proteggere se' stesse, il lavoro della NSA e' molto piu' facile. La NSA e' anche responsabile per la raccomandazione e l'approvazione degli algoritmi di cifratura. Qualche critico sostiene che questo sia un conflitto di interessi, come mettere la volpe a guardia del pollaio. La NSA ha cercato di promuovere un algoritmo di crittografia convenzionale di suo sviluppo, senza dire a nessuno come funziona perche' e' classificato. Essi vogliono che altri si fidino di esso e lo usino. Qualunque crittografo pero', potra' dirvi che un algoritmo valido non ha bisogno di essere classificato per rimanere sicuro. Solo la chiave necessita di protezione. Come si fa a sapere se l'algoritmo della NSA e' veramente sicuro? Non e' cosi' difficile per la NSA progettare un algoritmo di cifratura violabile solo da loro se nessuno puo' vederlo. Che stiano deliberatamente vendendo olio di serpente?

Sono tre i fattori principali che hanno minato la qualita' del software crittografico prodotto negli Stati Uniti. Il primo e' la mancanza di competenza virtualmente universale degli sviluppatori del software crittografico commerciale (sebbene questo abbia iniziato a cambiare dopo la pubblicazione di PGP). Ogni tecnico software pensa di essere un crittografo, e questo ha portato alla proliferazione di software molto scadente. Il secondo fattore e' la soppressione deliberata e sistematica da parte dell'NSA di tutte le tecnologie crittografiche commerciali di valore, per mezzo dell'intimidazione legale e della pressione economica. Parte di questa pressione e' esercitata applicando stringenti controlli alle esportazioni del software crittografico, il che, nell'economia di mercato, ha l'effetto diretto di sopprimere anche il mercato interno. Il terzo metodo di soppressione deriva dal concedere i diritti di utilizzo di tutti gli algoritmi di crittografia a chiave pubblica ad una sola azienda, dovendo cosi' controllare un solo punto critico per frenare la diffusione di questa tecnologia. L'effetto di tutto questo e' che prima della pubblicazione di PGP non c'era praticamente nessun software di crittografia di alta sicurezza per uso generale disponibile negli Stati Uniti.

Io non sono sicuro della sicurezza di PGP come lo ero del mio brillante software di crittografia del college. Se lo fossi sarebbe un cattivo segno. Sono pero' abbastanza sicuro che PGP non contenga vistose debolezze (sebbene possa contenere errori). L'algoritmo di crittografia e' stato sviluppato da persone di alto livello nel mondo accademico della crittografia civile, ed e' stato sottoposto a controlli intensivi da esperti loro pari. Il codice sorgente e' disponibile per facilitare questo tipo di verifica e per aiutare a dissolvere le paure di alcuni utenti. E' stato sottoposto ad indagini ragionevolmente accurate, ed ha richiesto anni di sviluppo. Inoltre io non lavoro per la NSA. Spero che per fidarvi di PGP non vi sia richiesto un "atto di fede" troppo impegnativo.

Ritorno all'Indice

Nota per gli utilizzatori di Macintosh

PGP e' stato sviluppato originalmente per macchine MSDOS e Unix. C'e' anche una versione per Apple Macintosh. Questo manuale e' scritto per la versione MSDOS/Unix, che usa un'interfaccia a linea di comando per richiamare tutte le funzioni di PGP. Sul Mac, tutte le funzioni sono richiamate da menu' a tendina e finestre di dialogo. C'e' un help on-line e dovrebbe esserci della documentazione aggiuntiva a questo manuale specifica per il Mac nel pacchetto dedicato.

Quasi tutti i buoni applicativi per Mac sono stati scritti da capo, e non semplicimente adattati partendo da altri sistemi operativi. Sfortunatamente questo non e' il caso dell'attuale versione di PGP per Mac. Essa e' stata portata su Mac da MSDOS/Unix da Zbigniew Fiedorwicz. Non essendo la versione MSDOS/Unix progettata per il GUI (Graphical User Interface), l'adattamento a Mac non e' stato un lavoro semplice, e ci sono ancora degli errori. E' in corso di sviluppo una versione completamente nuova, progettata per adattarsi facilmente al GUI. Da questo nuovo codice sorgente di PGP verra' sviluppata una nuova versione per Mac. Sara' piu' in "stile Mac" e piu' affidabile. Nonostante gli errori della versione attuale di MacPGP, e' importante notare che se Zbigniew avesse aspettato che questa versione di PGP completamente nuova fosse sviluppata, il mondo sarebbe stato privato di una versione Mac per veramente troppo tempo.

Ritorno all'Indice

Guida rapida di PGP

Ecco una guida rapida ai comandi di PGP.

Per cifrare un testo in chiaro con la chiave pubblica del destinatario:
pgp -e filetesto dest_ID

Per firmare un testo in chiaro con la vostra chiave segreta:
pgp -s filetesto [-u mio_ID]

Per firmare un testo in chiaro con la vostra chiave segreta, e produrre un messaggio in chiaro firmato adatto ad essere spedito via e-mail:
pgp -sta filetesto [-u mio_ID]

Per firmare un testo in chiaro con la vostra chiave segreta, e poi cifrarlo con la chiave pubblica del destinatario:
pgp -es filetesto dest_ID [-u mio_ID]

Per cifrare un testo in chiaro con la crittografia convenzionale:
pgp -c filetesto

Per decifrare un file, o per controllare l'integrita' di un file firmato:
pgp filecifrato [-o filechiaro]

Per cifrare un messaggio per un numero qualunque di destinatari:
pgp -e filetesto dest1_ID dest2_ID dest3_ID .......

--- Comandi di gestione delle chiavi:

Per generare la vostra coppia di chiavi pubblica/segreta:
pgp -kg

Per aggiungere il contenuto di un file di chiavi pubbliche/segrete al vostro portachiavi pubblico/segreto:
pgp -ka filechiavi [portachiavi]

Per estrarre (copiare) una chiave dal vostro portachiavi pubblico o segreto:
pgp -kx ID filechiavi [portachiavi]
o: pgp -kxa ID filechiavi [portachiavi]

Per vedere il contenuto del vostro portachiavi pubblico:
pgp -kv[v] [ID] [portachiavi]

Per vedere l'"impronta digitale" di una chiave pubblica, per verificarla al telefono con il suo proprietario:
pgp -kvc [ID] [portachiavi]

Per vedere il contenuto e verificare le firme del vostro portachiavi pubblico:
pgp -kc [ID] [portachiavi]

Per modificare l'ID o la frase chiave della vostra chiave segreta:
pgp -ke ID [portachiavi]

Per modificare i parametri di affidabilita' di una chiave pubblica:
pgp -ke ID [portachiavi]

Per rimuovere una chiave od un ID dal vostro portachiavi pubblico:
pgp -kr ID [portachiavi]

Per firmare e certificare una chiave altrui nel vostro portachiavi pubblico:
pgp -ks suo_ID [-u mio_ID] [portachiavi]

Per rimuovere delle firme da un ID in un portachiavi:
pgp -krs ID [portachiavi]

Per revocare permanentemente la vostra chiave, rilasciando un certificato di compromissione:
pgp -kd mio_ID

Per disabilitare o riabilitare una chiave pubblica nel vostro portachiavi pubblico:
pgp -kd ID

--- Comandi esoterici:

Per decifrare un messaggio e lasciarne la firma intatta:
pgp -d filecifrato

Per creare un certificato di firma separato dal documento:
pgp -sb filetesto [-u mio_ID]

Per staccare il certificato di firma da un messaggio firmato:
pgp -b filecifrato

--- Opzioni di comando da usare in combinazione con altre (formando a volte parole interessanti!)

Per produrre un file cifrato in formato ASCII radix-64, aggiungere l'opzione -a quando lo si cifra, lo si firma, o si estrae una chiave:
pgp -sea filetesto dest_ID
o: pgp -kxa ID filechiavi [portachiavi]

Per cancellare il testo in chiaro dopo averlo cifrato, aggiungere l'opzione -w (wipe) quando lo si cifra o lo si firma:
pgp -sew lettera.txt dest_ID

Per specificare che un testo in chiaro contiene solo testo ASCII, non binario, e che dovra' essere convertito in testo dal destinatario, aggiungere l'opzione -t (text) alle altre:
pgp -seat lettera.txt dest_ID

Per vedere il testo decifrato sullo schermo senza salvarlo in un file, come con il comando "more", usare l'opzione -m (more) quando si decifra:
pgp -m filecifrato

Per specificare che il destinatario potra' SOLO vedere il testo decifrato, e non salvarlo su disco, aggiungere l'opzione -m:
pgp -steam lettera.txt dest_ID

Per recuperare il nome originale del file di testo quando lo si decifra, aggiungere l'opzione -p:
pgp -p filecifrato

Per usare un filtro tipo Unix, leggendo da uno standard input e scrivendo in uno standard output, aggiungere l'opzione -f:
pgp -feast dest_ID <inputfile >outputfile

Ritorno all'Indice

Aspetti legali

Per informazioni dettagliate su licenza, distribuzione, diritti di copia, brevetti, marchio, limitazioni di responsabilita' e controlli sull'esportazione di PGP(tm), si veda la sezione "Aspetti legali" del "Volume II - Funzioni avanzate".

PGP impiega un algoritmo a chiave pubblica protetto dal brevetto U.S. #4,405,829. I diritti di licenza esclusiva di questo brevetto appartengono ad una societa' di nome Public Key Partners (PKP), e voi potreste violare questi diritti usando PGP in USA senza licenza. Queste questioni sono dettagliate nel Volume II, e nella licenza RSAREF allegata alla versione freeware di PGP. PKP ha concesso ad altri lo sfruttamento del brevetto. Tra essi la societa' ViaCrypt, di Phoenix, Arizona. ViaCrypt vende una versione con licenza piena di PGP, e puo' esser raggiunta per telefono al 602-944-0773.

PGP e' un freeware stile "guerriglia", e non mi dispiace se lo distribuite abbondantemente. Solo, non chiedetemi di mandarvene una copia. Piuttosto, potete cercarvela da soli in molte BBS, ed in molti siti FTP su Internet. Prima di distribuire il software, e' pero' essenziale che comprendiate bene le regole ed i controlli degli Stati Uniti sull' esportazione del software di crittografia.

Ritorno all'Indice

Riconoscimenti

Per fermare PGP sono stati schierati ostacoli formidabili e forze potenti. Alcune persone impegnate stanno aiutando a superare questi ostacoli. PGP e' diventato conosciuto come "software sommerso", e il portarlo "in superficie" come freeware provvisto di licenza ha richiesto pazienza e perseveranza. Vorrei specialmente ringraziare Hal Abelson, Jeff Schiller, Brian LaMacchia e Derek Atkins del MIT per la determinazione dei loro sforzi. Vorrei anche ringraziare Jim Bruce e David Litster dell'amministrazione del MIT, Bob Prior e Terry Ehling dell'ufficio stampa, sempre del MIT. E infine vorrei ringraziare l'intero gruppo dei miei difensori legali, il cui lavoro non e' ancora finito. Io raccontavo un mucchio di barzellette sugli avvocati, prima di incontrare tanti esempi positivi fra gli avvocati del mio collegio di difesa, molti dei quali lavorano gratis.

Lo sviluppo di PGP si e' trasformato in un fenomeno sociale di rilievo, la cui attrazione di carattere politico ha ispirato gli sforzi collettivi di un numero di programmatori volontari sempre crescente. Vi ricordate la storia infantile chiamata "la zuppa di pietre"?

Vorrei ringraziare le persone seguenti per il loro contributo alla creazione di PGP. Sebbene io sia l'autore della versione 1.0, la maggior parte del contenuto delle versioni seguenti e' stata sviluppata con uno sforzo di collaborazione internazionale che ha coinvolto un gran numero di persone, sotto la mia guida di progetto.

Branko Lankester, Hal Finney e Peter Gutmann hanno speso una quantita' enorme del loro tempo ad aggiungere funzioni a PGP 2.0, e lo hanno adattato a Unix.

Hugh Kennedy lo ha adattato al VAX/VMS, Lutz Frank all'Atari ST, Cor Bosman e Colin Plumb al Commodore Amiga.

La traduzione di PGP dall'Inglese e' stata fatta da Jean-Loup Gailly in Francia, Armando Ramos in Spagna, Felipe Rodriguez Svensson e Branko Lankester in Olanda, Miguel Angel Gallardo in Spagna, Hugh Kennedy e Lutz Frank in Germania, David Vincenzetti in Italia (per la versione 2.3; N.d.T.), Harry Bush e Maris Gabalins in Lettonia, Zygimantas Cepaitis in Lituania, Peter Suchkow e Andrew Chernov in Russia, e Alexander Smishlajev in Esperanto. Peter Gutman ha offerto di scrivere la traduzione in Inglese Neozelandese, ma si e' deciso che puo' andare bene in Inglese Americano.

Jean-Loup Gailly, Mark Adler e Richard B. Wales hanno pubblicato il codice di compressione ZIP, ed hanno permesso di includerlo in PGP. Le routines MD5 sono state sviluppate e rese di pubblico dominio da Ron Rivest. La cifratura IDEA(tm) e' stata sviluppata da Xuejia Lai e James L. Massey all'ETH di Zurigo, ed e' usata in PGP col permesso della Ascom-Tech AG.

Charlie Merrit e' stato il primo ad insegnarmi come sviluppare dell'aritmetica decente applicata alla crittografia a chiave pubblica, e Jimmy Upton ha contribuito con un suo algoritmo a modulo di moltiplicazione piu' veloce. Thad Smith ha implementato un algoritmo modmult ancora piu' veloce. Zhahai Stewart ha contribuito con molte idee utili sul formato dei files di PGP ed altro, compresa l'idea di avere piu' di un utente per chiave. L'idea dei presentatori l'ho avuta da Whit Diffie. Kelly Goen ha svolto la maggior parte del lavoro di pubblicazione elettronica di PGP 1.0.

Vari contributi al lavoro di programmazione sono stati dati da Colin Plumb, Derek Atkins e Castor Fu. Altri contributi in sforzi, programmazione o altro sono arrivati da Hugh Miller, Eric Hughes, Tim May, Stephan Neuhaus, e troppi altri per poterli ricordare tutti adesso. Zbigniew Fiedorwicz ha fatto il primo adattamento a Macintosh.

Fin dalla pubblicazione di PGP 2.0, molti altri programmatori hanno inviato rappezzi e soluzioni di errori, cosi' come soluzioni di problemi degli adattamenti per altri computers. Sono troppi per poterli ringraziare individualmente qui.

Proprio come nella storia della "zuppa di pietre", sta diventando difficile guardare attraverso la zuppa diventata spessa per vedere al fondo la pietra che io lanciai per iniziare tutto questo.

Ritorno all'Indice

Notizie sull'autore

Philip Zimmermanm e' un consulente tecnico software con 19 anni di esperienza, specializzato in sistemi "embedded real-time", crittografia, autenticazioni e trasmissione dati. La sua esperienza include il progetto e l'implementazione di sistemi di autenticazione per reti di informazioni finanziarie, sistemi di sicurezza per reti dati, protocolli di gestione di chiavi, sistemi embedded real-time multiprocesso, sistemi operativi e reti locali.

E' possibile ottenere da Zimmermann versioni dedicate di prodotti di autenticazione e crittografia come il NIST DSS, oltre a servizi di sviluppo di prodotti specifici. L'indirizzo della sua azienda di consulenza e':

Boulder Software Engineering
3021 Eleventh Street
Boulder, Colorado 80304 USA
Phone: 303-541-0140 (10:00am - 7:00pm Mountain Time)
Fax: Prendere accordi per telefono
Internet: [email protected]

Ritorno all'Indice

[Nota: questa e' la documentazione originale della versione 2.6.2 del MIT, inclusa qui senza modifiche. Per una spiegazione delle differenze tra PGP 2.6.3i e 2.6.2 si legga il file readme.1st. incluso nel pacchetto di distribuzione]

Phil's Pretty Good Software


Presenta

PGP(tm)

Pretty Good(tm) Privacy


Crittografia a chiave pubblica per tutti

Manuale d'uso del PGP(tm)
Volume II: funzioni avanzate

di Philip Zimmermann
Ultima revisione 11 Ottobre 94
Tradotto in Italiano da: Marco Giaiotto <[email protected]>
PGP Versione 2.6.2 - 11 Ott. 94
Software di
Philip Zimmermann, e molti altri.
Sinopsi:

PGP(tm) utilizza la crittografia a chiave pubblica per proteggere e-mail e file di dati. Comunicate in modo sicuro con persone che non avete mai visto, senza bisogno di canali sicuri per lo scambio delle chiavi. PGP ha molte funzioni ed e' veloce, con un sofisticato sistema di gestione delle chiavi, un sistema di firma digitale, comprime i dati ed ha un progetto ergonomica- mente valido.

Software e documentazione (c) Copyright 1990-1994 Philip Zimmermann. Tutti i diritti riservati. Per informazioni sulla licenza d'uso di PGP, la distribuzione, il copyright, i brevetti, i marchi, le limi- tazioni ed i controlli sulle esportazioni, vedere la sezione "Aspetti Legali". Distribuito dal Massachusetts Institute of Technology.

Indice

Vista d'insieme

Pretty Good(tm) Privacy (PGP), di Phil's Pretty Good Software, e' un applicativo software di crittografia ad alta sicurezza per MSDOS, Unix, VAX/VMS ed altri computer. PGP unisce la comodita' del sistema di crittografia a chiave pubblica Rivest-Shamir-Adleman (RSA) con la velocita' della crittografia convenzionale, con un buon progetto ergonomico ed un sofisticato sistema di gestione delle chiavi.

Questo secondo volume del Manuale d'uso copre le funzioni avanzate non spiegate nel "Volume I - Funzioni essenziali". Dovreste prima leggere il primo volume, o questo manuale non potra' avere molto senso per voi. La lettura di questo secondo volume e' opzionale, eccetto per la sezione dedicata agli aspetti legali, che dovrebbe essere letta da tutti.

Ritorno all'Indice

Funzioni avanzate

Ritorno all'Indice

In tutti i comandi in cui l'utilizzatore inserisce un ID o parte di esso, e' possibile sostituirlo con l'id di chiave esadecimale. Basta inserire l'id di chiave preceduto da "0x" al posto dell'ID. Ad esempio:

pgp -kv 0x67F7

Verranno mostrate tutte le chiavi che contengono 67F7 nell'id di chiave.

Questa funzione e' particolarmente utile se avete due chiavi della stessa persona con lo stesso ID. Potete scegliere univocamente la chiave specificando l'id di chiave

Ritorno all'Indice

Normalmente i certificati di firma sono attaccati fisicamente al testo che certificano. Questo rende comodo il controllo della firma nei casi semplici. In determinate circostanze e' pero' desiderabile poter tenere i certificati separati dai messaggi. E' possibile generare certificati di firma separati dai messaggi firmati aggiungendo l'opzione -b (break) all'opzione -s (sign). Ad esempio:

pgp -sb lettera.txt

Questo esempio genera un certificato di firma chiamato "lettera.sig". Il contenuto di "lettera.txt" non e' aggiunto al certificato di firma.

Dopo aver creato il certificato di firma (lettera.sig nell'esempio precedente), speditelo al destinatario assieme al file di testo originale. Il destinatario ha bisogno di entrambi i files per controllare l'integrita' della firma. PGP, durante il controllo della firma, rileva la mancanza di testo e richiede il nome del file che lo contiene. Solo a questo punto PGP potra' controllare l'integrita' della firma. Se il destinatario sa gia' che firma e testo sono separati, puo' specificarne il nome nella linea di comando:

pgp lettera.sig lettera.txt
o: pgp lettera lettera.txt

In questo caso PGP non avra' bisogno di richiedere il nome del file di testo.

Un certificato di firma separato e' utile se volete tenere un archivio separato di questi certificati. Il certificato di firma di un programma eseguibile puo' servire per rilevare una successiva infezione da virus. E' anche utile se un documento deve essere firmato da piu' persone senza subordinare le firme. Ogni firma e' indipendente.

Se ricevete un testo cifrato con il certificato di firma incollato ad esso, potete separarlo durante il processo di decrittaggio. Usate l'opzione -b:

pgp -b lettera

PGP decifra il file lettera.pgp e, se esso contiene una firma, controlla la firma e la stacca salvandola nel file lettera.sig.

Ritorno all'Indice

Normalmente si vuole che PGP sbrogli completamente un file cifrato, decifrandolo e controllando l'eventuale firma, togliendo strato dopo strato fino a rimanere con il solo testo in chiaro originale.

Qualche volta pero', potreste voler decifrare un file lasciandovi attaccata la firma in esso contenuta, ottenendo un file decifrato firmato. Questo puo' servire se volete spedire una copia firmata di un documento ad una terza persona, magari ricifrandolo. Per esempio, supponete di aver ricevuto un messaggio firmato da Charlie e cifrato per voi. Volete decifrarlo e, lasciandovi la firma di Charlie, inviarlo ad Alice, magari ricifrandolo con la chiave pubblica di Alice. Nessun problema. PGP e' in grado di fare questo per voi.

Per decifrare un messaggio lasciandovi la firma intatta, battere:

pgp -d lettera

Questo decifra lettera.pgp e, se esso contiene una firma, la lascia intatta assieme al testo in chiaro nel file di uscita.

Adesso potete archiviarlo o ricifrarlo per mandarlo ad altri.

Ritorno all'Indice

Potete usare PGP per cifrare qualunque tipo di testo in chiaro, dati binari ad 8 bits o testo ASCII. E' probabile che l'applicazione piu' comune di PGP sia l'e-mail, dove il testo in chiaro e' ASCII.

Il testo ASCII a volte e' rappresentato in modo diverso su macchine diverse. Per esempio sui sistemi MSDOS ogni linea ASCII e' terminata con CR + LF (Carriage Return + Line Feed). Sui sistemi Unix si usa solo LF. Su un Macintosh le linee terminano con il solo CR. E' un fatto triste della vita.

I messaggi di testo ASCII non cifrati sono spesso convertiti in qualche forma "canonica" comune nel momento in cui sono trasmessi da una macchina ad un altra. Il testo canonico ha le linee terminate con CR + LF. Per esempio, il diffuso protocollo di comunicazione KERMIT converte il testo in forma canonica mentre lo trasmette ad un altro sistema. Questo testo viene riconvertito nella forma locale dal ricevitore KERMIT. In questo modo e' facile trasmettere file di testo fra sistemi diversi.

Il testo cifrato non puo' pero' essere convertito automaticamente dal protocollo di comunicazione, perche' il testo in chiaro e' nascosto dalla cifratura. Per rimediare a questo inconveniente, PGP vi permette di specificare che il testo in chiaro deve essere trattato come un testo ASCII, non binario, e deve quindi essere convertito in forma canonica prima di essere cifrato. Una volta ricevuto, il testo decifrato viene convertito automaticamente nella forma appropriata all'ambiente locale.

Perche' PGP assuma che il testo in chiaro deve essere convertito in forma canonica prima di essere cifrato, aggiungete l'opzione -t quando cifrate o firmate un messaggio, cosi':

pgp -et lettera.txt dest_ID

Questo modo di funzionamento e' escluso automaticamente se PGP rileva che il testo in chiaro contiene apparentemente dati binari.

Se dovete utilizzare spesso l'opzione -t, potete attivare l'opzione TEXTMODE nel file di configurazione di PGP. E' quello che faccio io.

Per gli utilizzatori di PGP che usano serie di caratteri non Inglesi ad 8 bits, quando PGP converte il testo in forma canonica puo' convertire i dati dalla serie di caratteri locali nella serie LATIN1 (ISO 8859-1 Latin Alphabet 1), tenendo conto dell'impostazione del parametro CHARSET nel file di configurazione di PGP. Il LATIN1 e' una serie di caratteri ASCII estesa, con caratteri supplementari aggiunti per molte lingue Europee.

Ritorno all'Indice

Molti utenti del mondo Unix spediscono files di dati binari attraverso canali di e-mail utilizzando l'utility "uuencode" di Unix per convertire i files in caratteri ASCII compatibili con la posta elettronica. Non e' richesta nessuna cifratura, cosi' ne' il mittente ne' il destinatario hanno bisogno di chiavi particolari. Il formato uuencode e' stato progettato per uno scopo simile a quello del formato ASCII radix-64 dell'armatura di trasporto descritta nella sezione "Invio di testo cifrato via e-mail: il formato Radix-64", ma non e' cosi' efficiente. Utilizza una serie di caratteri radix-64 diversa. Uuencode ha i suoi problemi, tipo 1) diverse serie di caratteri incompatibili fra loro per le diverse versioni per Unix e MSDOS, e 2) i dati possono essere corrotti da qualche gateway di e-mail che saccheggia i caratteri vuoti di trasporto o modifica in altri modi la serie di caratteri usata da uuencode.

PGP puo' essere usato in modo da offrire le stesse funzioni generali di uuencode, piu' altre. Potete chiedere a PGP di limitarsi a convertire un file in formato ASCII radix-64, senza doverlo firmare o cifrare, sicche' non e' richiesta nessuna chiave. Basta usare l'opzione -a da sola:

pgp -a nomefile

Questo produce un file con armatura radix-64 chiamato "nomefile.asc".

Se leggete la sezione "Invio di testo cifrato via e-mail: il formato Radix-64", vedrete che l'approccio di PGP, rispetto a quello di uuencode, offre diversi vantaggi importanti:

* PGP dividera' automaticamente in blocchi i file troppo lunghi per i canali e-mail.
* PGP aggiungera' un codice CRC per il controllo degli errori alla fine di ogni blocco.
* PGP cerchera' di comprimere i dati prima di convertirli. * La serie di caratteri radix-64 usata da PGP e' piu' compatibile di quella usata da uuencode con la conversione dei caratteri operata dai canali e-mail.
* I files di testo possono essere convertiti dal mittente in forma canonica, come spiegato nella sezione "Inviare file di testo ASCII attraverso macchine e ambienti diversi".

Il destinatario puo' recuperare il nome originale del file riconvertendo il messaggio con l'opzione -p di PGP. Potete usare "PGP -a" in qualunque situazione in cui avreste usato uuencode, se il destinatario ha PGP. PGP e' un uuencode migliore di uuencode.

Ritorno all'Indice

Dopo aver prodotto un file cifrato, potete chiedere a PGP di sovrascrivere e cancellare il file in chiaro, togliendone ogni traccia dal disco, in modo che nessuno potra' ricuperarlo usando uno strumento di scansione a blocchi. Questo e' utile se il file in chiaro contiene informazioni riservate che non volete tenere in giro.

Per distruggere il file in chiaro dopo averne cifrato il contenuto, aggiungete l'opzione -w (wipe) quando cifrate o firmate un messaggio. Cosi':

pgp -esw lettera.txt dest_ID

Questo esempio produce il file cifrato "lettera.pgp", e cancella il file "lettera.txt" senza possibilita' di recupero.

Naturalmente e' necessario essere attenti nell'uso di questa opzione. Si noti anche che questa opzione non cancellera' gli eventuali frammenti di testo in chiaro che il vostro word processor puo' aver creato sul disco mentre preparavate il messaggio prima di lanciare PGP. Molti word processors creano files di backup, files temporanei o entrambi. Inoltre PGP sovrascrive il file una volta sola, abbastanza per rendere vani gli sforzi dei sistemi convenzionali di recupero, ma insufficiente ad affrontare uno sforzo sofisticato e determinato a recuperare le deboli tracce magnetiche lasciate dai dati per mezzo di attrezzi speciali di recupero dei dischi.

Ritorno all'Indice

Per vedere il testo decifrato sullo schermo (come con il comando Unix "more") senza scriverlo in un file, usate l'opzione -m (more) quando decifrate:

pgp -m file cifrato

Questo mostra il testo decifrato sullo schermo, pagina per pagina.

Ritorno all'Indice

Per specificare che il testo decifrato dal destinatario sara' SOLO presentato sullo schermo, e non salvato in un file, aggiungere l'opzione -m:

pgp -sem lettera.txt dest_ID

Quando il destinatario decifrera' il file con la propria chiave segreta, il testo in chiaro verra' presentato sullo schermo, ma non salvato su disco. Il testo verra' mostrato come se si stesse usando il comando "more" di Unix, una pagina per volta. Se il destinatario vorra' rileggere il messaggio dovra' decifrarlo di nuovo.

Questa funzione e' la via piu' sicura per evitare che i vostri messaggi piu' delicati possano essere lasciati inavvertitamente nel disco del destinatario. Ho aggiunto la funzione su richiesta di un utilizzatore che voleva inviare messaggi intimi alla sua amante, ma temeva che lei lasciasse accidentalmente i testi decifrati nel computer del marito.

Si noti che questa funzione non impedira' ad una persona intelligente e determinata di trovare un modo per salvare il testo in chiaro sul disco-- serve solo ad evitare che l'utente casuale faccia questo inavvertitamente.

Ritorno all'Indice

PGP assegna normalmente al file decifrato il nome del file cifrato senza estensione. Potete specificare voi stessi un nome diverso, specificandolo nella linea di comando con l'opzione -o. Per la maggior parte dei messaggi e-mail questo e' il modo migliore di procedere, perche' siete voi a dover decidere il nome del file quando lo decifrate, ed il messaggio e-mail tipico aveva in origine un nome inutile per voi, tipo "a_Phil.txt".

Quando pero' PGP cifra un file, salva sempre il nome originale allegandolo al testo in chiaro prima di comprimerlo e cifrarlo. Normalmente questo nome nascosto viene scartato da PGP quando decifra il file, ma voi potete decidere di utilizzarlo per nominare il file cifrato. Questo e' utile quando PGP viene usato per files il cui nome e' significativo.

Per ricuperare il nome originale del file in chiaro, aggiungere l'opzione -p, cosi':

pgp -p filecifrato

Normalmente io non uso questa opzione, perche' se lo facessi circa meta' della posta che ricevo sarebbe decifrata verso lo stesso file in chiaro chiamato "a_phil.txt" o "prz.txt".

Ritorno all'Indice

A volte potreste aver bisogno di cambiare la vostra frase chiave, ad esempio perche' qualcuno guardava da dietro le vostre spalle mentre la battevate.O potreste voler cambiare il vostro ID, per esempio perche' dopo il matrimonio avete cambiato il vostro nome, oppure avete cambiato il vostro indirizzo di e-mail. O ancora potreste voler aggiungere un secondo od un terzo ID alla vostra chiave, perche' siete conosciuti con piu' di un nome o indirizzo di e-mail o titolo. PGP vi permette di assegnare piu' di un ID alla vostra chiave, ognuno dei quali potra' essere usato per trovare la vostra chiave in un portachiavi.

Per modificare il vostro ID o la vostra frase chiave:

pgp -ke ID [portachiavi]

PGP vi richiede un nuovo ID o una nuova frase chiave.

Se voi inserite un nuovo ID, PGP effettivamente lo aggiunge, senza togliere quello vecchio. Se volete toglierlo, dovrete farlo con una operazione separata.

Il parametro opzionale [portachiavi], se specificato, deve essere un portachiavi pubblico, non segreto. Il campo ID deve essere il vostro proprio ID, che PGP riconosce perche' e' presente anche nel vostro portachiavi segreto. Entrambi i portachiavi verranno aggiornati, anche se voi avete specificato solo quello pubblico.

Il comando -ke si comporta in maniera diversa se lo usate per una chiave pubblica o segreta. Puo' anche essere usato per modificare i parametri di affidabilita' di una chiave pubblica.

Ritorno all'Indice

A volte vi puo' capitare di dover modificare i parametri di affidabilita' di una chiave pubblica nel vostro portachiavi. Per una discussione sul significato di questi parametri, si veda la sezione "Come fa PGP a tener traccia delle chiavi valide?" del "Volume I" del Manuale.

Per modificare i parametri di affidabilita' di una chiave pubblica:

pgp -ke ID [portachiavi]

Il parametro opzionale [portachiavi], se specificato, deve essere un portachiavi pubblico, non segreto.

Ritorno all'Indice

Normalmente PGP controlla automaticamente ogni nuova chiave o firma nel vostro portachiavi pubblico, e aggiorna tutti i parametri di affidabilita' ed i punti di validita'. In teoria tiene aggiornate tutte le informazioni sulla validita' di una chiave man mano che il materiale viene aggiunto o tolto dal vostro portachiavi pubblico. E' possibile pero' che voi vogliate forzare PGP ad effettuare un'analisi completa del portachiavi, controllando tutte le firme di certificazione ed i parametri di affidabilita', aggiornando tutti i punti di validita', e confrontando la vostra propria chiave assiomaticamente affidabile con una copia di backup conservata su un disco protetto da scrittura. Sarebbe una buona idea effettuare questa manutenzione "igienica" periodicamente, per essere sicuri che nel vostro portachiavi pubblico sia tutto in ordine. Per forzare PGP ad effettuare un'analisi completa del vostro portachiavi pubblico, usate il comando -kc (key ring check):

pgp -kc

Potete anche forzare PGP a controllare tutte le firme per una singola chiave pubblica:

pgp -kc ID [portachiavi]

Per ulteriori informazioni sul modo in cui viene controllata la vostra propria chiave, si veda la descrizione del parametro BAKRING nella sezione che si occupa del file di configurazione.

Ritorno all'Indice

Se ricevete una chiave pubblica non certificata da qualcuno di cui vi fidate, come potete dire se la chiave e' autentica ? Il modo migliore per verificare una chiave non certificata e' verificarla attraverso un canale indipendente da quello attraverso cui vi e' arrivata. Un modo comodo, se conoscete il proprietario della chiave e potete riconoscerlo al telefono, e' chiamarlo e verificare la chiave. Piuttosto che leggere l'intera chiave (con armatura ASCII) al telefono, potete leggerne la sola "impronta digitale". Per vedere questa impronta digitale, usate il comando -kvc:

pgp -kvc ID [portachiavi]

Questo mostrera' una selezione di 16 bytes dei componenti della chiave pubblica. Leggete questa impronta digitale di 16 bytes al proprietario, che fara' lo stesso con la sua copia, usando lo stesso comando -kvc.

Potete verificare reciprocamente le rispettive chiavi in questo modo, e poi firmarle tranquillamente. E' un modo sicuro e conveniente per iniziare la rete di fiducia tra i vostri amici.

Si noti che il modo migliore per verificare una chiave non e' inviarne l'impronta digitale per e-mail, perche' puo' essere intercettata e modificata. E' meglio usare un mezzo indipendente da quello che avete usato per inviare la chiave stessa. Una buona combinazione e' inviare la chiave per e-mail e verificarne l'impronta digitale attraverso una conversazione telefonica. Alcune persone distribuiscono l'impronta della propria chiave scrivendola sui biglietti da visita, cosa che sembra abbastanza sfacciata.

Nella versione corrente di PGP, l'impronta digitale della chiave e' ricavata usando la funzione di "mescolamento" MD5. Una futura versione di PGP permettera' di usare come opzione una funzione nuova, SHA, invece di MD5.

Se non mi conoscete, per favore non chiamatemi per verificare la mia chiave-- Ricevo troppe chiamate del genere. Siccome ogni utilizzatore di PGP possiede una copia della mia chiave, nessuno puo' manometterle tutte. Le differenze sarebbero presto notate da qualcuno che la controllasse usando piu' di una fonte, e la voce sarebbe presto sparsa su Internet.

Per coloro che volessero verificare la mia chiave pubblica (inclusa nel pacchetto standard di rilascio di PGP), eccone i particolari:

ID: "Philip R. Zimmermann "
Formato: 1024 bits; Data : 21 May 1993; id di chiave: C7A966DD
Impronta: 9E 94 45 13 39 83 5F 70 7B E7 D8 ED C4 BE 5A A6

Queste informazioni potrebbero ancora essere manomesse nell'edizione elettronica di questo manuale. Se pero' state leggendo la versione stampata, disponibile nelle librerie ed edita da MIT press, e' sicuro assumere che questa sia effettivamente l'impronta digitale della mia chiave.

Ritorno all'Indice

In origine PGP e' stato progettato per gestire piccoli portachiavi personali in cui conservare le chiavi dei vostri amici, come in un'agenda. Il contenuto ragionevole di un simile portachiavi e' di qualche centinaio di chiavi. Essendo pero' PGP diventato molto popolare, molte persone stanno tentando di aggiungere il contenuto di portachiavi molto grossi al proprio portachiavi pubblico. A volte questo significa aggiungere migliaia di chiavi. PGP, nella sua forma attuale, non e' in grado di eseguire questa operazione in un tempo ragionevole, mentre voi attendete davanti alla vostra tastiera. Almeno non per portachiavi enormi.

Potreste pero' voler aggiungere un portachiavi "enorme" al vostro portachiavi perche' siete interessati a poche dozzine di chiavi fra quelle contenute. Se questo e' tutto quello che volete, sarebbe piu' efficiente estrarre le poche chiavi che vi interessano dal portachiavi grosso, e poi aggiungere solo queste chiavi al vostro portachiavi. Usate il comando -kx per estrarle dal portachiavi grosso, specificando il nome di questo portachiavi nella linea di comando. Quindi aggiungetele al vostro portachiavi pubblico.

La soluzione vera consiste nel migliorare PGP per fargli usare tecniche avanzate di database. Stiamo lavorando su questo, e dovremmo essere pronti molto presto. Fino ad allora, dovrete usare portachiavi piu' piccoli, o essere pazienti.

Ritorno all'Indice

Gli amanti di Unix sono abituati ad usare i collegamenti Unix per far lavorare insieme due applicazioni. L'uscita di un'applicazione puo' essere inviata attraverso un collegamento per fungere da ingresso per un'altra. Perche' questo funzioni, l'applicazione deve essere in grado di leggere il materiale su cui deve lavorare dallo "standard input" e scrivere i risultati nello "standard output". PGP puo' funzionare in questo modo. Se non capite cosa questo significhi, probabilmente questa funzione non vi serve.

Per usare un modo di filtro stile Unix, leggendo dallo standard input e scrivendo nello standard output, aggiungere l'opzione -f, cosi':

pgp -feast dest_ID outputfile

Questa funzione rende piu' facile l'uso di PGP con applicazioni di posta elettronica.

Usando PGP nel modo filtro per decifrare un file, potreste trovare utile usare la variabile di ambiente PGPPASS per conservare la frase chiave, in modo che non vi venga richiesta. La funzione PGPPASS e' spiegata piu' avanti.

Ritorno all'Indice

Abilitando il flag BATCHMODE nella linea di comando, PGP non richiedera' informazioni non necessarie o nomi di files alternativi. Ecco un esempio di come abilitare questo flag: pgp +batchmode filecifrato

E' utile per avviare PGP in modo non interattivo da uno shell script di Unix o da un file batch di MSDOS. Alcuni comandi di gestione delle chiavi richiedono interazione anche quando BATCHMODE e' attivo, quindi gli shell scripts potrebbero doverli evitare.

BATCHMODE puo' anche essere abilitato per controllare la validita' di una firma in un file. Se non ci sono firme, il codice di uscita e' 1. Se c'e' una firma valida il codice di uscita e' 0.

Ritorno all'Indice

Questo flag impostato nella linea di comando obbliga PGP ad assumere come affermative le conferme per la sovrascrittura di files esistenti, o per la rimozione di chiavi dal portachiavi con il comando -kr. Ecco un esempio:

pgp +force filecifrato
o:
pgp -kr +force Smith

Questa funzione e' utile per lanciare PGP in modo non interattivo da uno shell script di Unix o da un file batch di MSDOS.

Ritorno all'Indice

Per semplificare la gestione di PGP in modo "batch", per esempio da un file ".bat" di MSDOS o da uno shell script di Unix, PGP restituisce uno stato allo shell. Uno stato 0 indica funzionamento normale, mentre un valore diverso indica il verificarsi di qualche tipo di errore. Errori diversi provocano il ritorno di valori diversi allo shell.

Ritorno all'Indice

Normalmente PGP richiede all'utilizzatore di inserire una frase chiave laddove sia richiesta per sbloccare una chiave segreta. E' pero' possibile inserire questa chiave in una variabile di sistema, operando dallo shell. La variabile PGPPASS puo' quindi contenere la frase chiave che PGP tentera' di usare per prima. Se la frase contenuta in PGPPASS non e' corretta, PGP la chiedera' all'utilizzatore.

Per esempio, in ambiente MSDOS, il comando shell:

SET PGPPASS=zaphod beeblebrox for president

eliminerebbe la richiesta della frase chiave, se questa effettivamente fosse "zaphod beeblebrox for president". (L'esempio non e' stato tradotto, perche' qualunque frase serve allo scopo. Inoltre, per chi conosce il riferimento e' proprio una bella frase. N.d.T.)

Questa pericolosa funzione vi rende la vita piu' comoda se dovete lavorare regolarmente con un gran numero di messaggi indirizzati alla vostra chiave segreta, eliminando la necessita' di inserire ripetutamente la vostra frase.

Ho aggiunto questa funzione dopo diffuse richieste. Comunque, si consideri che la funzione e' in qualche modo pericolosa, perche' immagazzina la vostra frase chiave in un posto diverso dal vostro cervello. Ancora peggio, se siete particolarmente imprudenti, potreste memorizzarla su un disco nello stesso computer in cui conservate la vostra chiave segreta. Sarebbe particolarmente pericoloso e stupido se installaste questo comando in un file batch o uno script, come il file "AUTOEXEC.BAT" di MSDOS. Qualcuno, durante la pausa del pranzo, potrebbe rubare sia il vostro portachiavi segreto che il file che contiene la frase chiave.

Non potro' mai dare abbastanza enfasi a questo rischio. Se state pensando di usare questa funzione, assicuratevi di aver letto le sezioni "Esposizioni nei sistemi multi-utente" e "Come proteggere il portachiavi segreto dall'apertura", in questo volume e nel "Volume I".

Se dovete usare questa funzione, il modo piu' sicuro di farlo sarebbe battere il comando shell per impostare PGPPASS ogni volta che iniziate ad usare PGP, e quindi cancellare la variabile o spegnere il computer appena avete finito. Inoltre non dovreste assolutamente fare questo in un ambiente in cui altre persone possono avere accesso alla vostra macchina. Qualcuno potrebbe semplicemente chiedere al vostro computer di visualizzare il contenuto di PGPPASS.

In alcuni casi potreste voler passare la frase chiave a PGP da un'altra applicazione, ad esempio un pacchetto e-mail. Non e' pero' sempre desiderabile utilizzare la variabile PGPPASS per questo scopo. Esiste un altro modo per fare questo. Usate l'opzione -z nella linea di comando. La frase chiave segue l'opzione -z. I rischi associati a questo approccio sono simili a quelli gia' descritti per l'uso della variabile PGPPASS.

Ritorno all'Indice

PGP riconosce un certo numero di parametri che possono essere definiti dall'utilizzatore all'interno di un file di configurazione chiamato "config.txt". Il file si deve trovare nella directory definita nella variabile di ambiente PGPPATH. Il fatto di avere un file di configurazione permette all'utente di definire diversi flag e parametri usati da PGP, senza il fastidio di doverli sempre definire nella linea di comando.

Il nome "config.txt" e' stato usato da PGP per lungo tempo, ma alcune persone hanno fatto notare come potrebbe non essere compatibile con le convenzioni usate per nominare i files di configurazione in diversi sistemi operativi. PGP, per evitare il problema, tentera' di aprire questo file solo dopo aver cercato il file ".pgprc" nelle piattaforme Unix, o "pgp.ini" in altri ambienti, nella stessa directory in cui cercherebbe "config.txt".

Ai parametri di configurazione possono essere assegnati valori numerici interi, stringhe o valori on/off, relativamente al tipo di parametro. Un file di configurazione standard e' fornito assieme a PGP, in modo che possiate vedere degli esempi.

Nel file di configurazione, le linee vuote sono ignorate, cosi' come qualunque cosa venga dopo il carattere di commento "#". Non importa che le parole chiave siano maiuscole o minuscole.

Ecco un esempio tipico di un pezzo di file di configurazione:

# TMP e' la directory per i file temporanei di PGP (tipo RAM disk)
TMP = "e:\" # Puo' essere scavalcato dalla variabile di ambiente TMP.
Armor = on # Usa il comando -a (armatura ASCII) ogni volta che e' applicabile.
# CERT_DEPTH indica la profondita' della catena di affidabilita',
# ovvero per quanti livelli un presentatore puo' presentarne un
# altro.
cert_depth = 3

Se alcuni parametri non sono definiti nel file di configurazione, se non esiste un file di configurazione, o se PGP non lo trova, i valori dei parametri sono impostati a dei default ragionevoli.

Si noti che e' possibile impostare questi parametri direttamente dalla linea di comando, facendo precedere l'impostazione del parametro da un carattere "+" . Per esempio i due comandi che seguono producono lo stesso effetto:

pgp -e +armor=on lettera.txt smith
o: pgp -ea lettera.txt smith

Di seguito e' riportato un sommario dei vari parametri definibili nel file di configurazione.

Ritorno all'Indice

Valore di default: TMP = ""

Il parametro TMP specifica la directory da usare per i files temporanei. Il posto migliore, se ne avete uno, e' un RAM disk. La velocita' aumenta leggermente, ed in qualche modo anche la sicurezza. Se TMP non e' definito, i files temporanei saranno salvati nella directory corrente. Se la variabile ambiente TMP e' definita, PGP usera' comunque la directory specificata in questa variabile.

Ritorno all'Indice

Valore di default: LANGUAGE = "en"

PGP visualizza diverse richieste, messaggi di avviso e consigli per l'utente sullo schermo. Ad esempio messaggi come "File non trovato" o "Inserire la frase chiave:". I messaggi sono normalmente visualizzati in Inglese. E' pero' possibile forzare PGP ad usare un'altra lingua, senza dover modificare il programma eseguibile.

Molte persone in diversi Paesi hanno tradotto tutti i messaggi presentati da PGP sullo schermo nella loro lingua madre. Queste centinaia di stringhe tradotte sono state piazzate in uno speciale file di testo chiamato "language.txt", distribuito assieme a PGP. I messaggi sono immagazzinati in questo file in Inglese, Spagnolo, Olandese, Tedesco, Francese, Italiano, Russo, Lettone e Lituano. Altre lingue possono essere aggiunte successivamente.

Il parametro LANGUAGE specifica quale lingua deve essere usata da PGP. Puo' essere impostato con il valore "en" per l'Inglese, "es" per lo Spagnolo, "de" per il Tedesco, "nl" per l'Olandese, "fr" per il Francese, "it" per l'Italiano, "ru" per il Russo, "lt3" per il Lituano, "lv" per il Lettone, "esp" per l'Esperanto. Per esempio, se nel file di configurazione appare questa linea:

LANGUAGE = "fr"

PGP utilizzera' il Francese per i suoi messaggi. La lingua di default e' l'Inglese.

Quando PGP deve visualizzare un messaggio, cerca nel file "language.txt" la stringa equivalente tradotta nella lingua richiesta e usa questa per la visualizzazione. Se PGP non trova il file, se la lingua richiesta non e' presente nel file, o se quella frase manca dal file, usa la lingua Inglese.

Per risparmiare spazio sui dischi, la maggior parte delle traduzioni non e' distribuita con il pacchetto standard di PGP, ma e' disponibile separatamente.

Ritorno all'Indice

Valore di default: MYNAME = ""

Il parametro MYNAME specifica l'ID di default che PGP usera' per selezionare la frase segreta e generare le firme. Se MYNAME non e' definito, PGP usera' la chiave che e' stata inserita piu' di recente nel vostro portachiavi segreto. L'utilizzatore puo' scavalcare questa impostazione specificando un ID nella linea di comando con l'opzione -u.

Ritorno all'Indice

Valore di default: TEXTMODE = off

Il parametro TEXTMODE e' equivalente al comando -t. Se e' abilitato, forza PGP a considerare il testo in chiaro come testo puro, non binario, e a convertirlo in forma canonica prima di cifrarlo. Il testo in forma canonica ha CR + LF al termine di ogni linea.

Questo modo di funzionamento verra' posto automaticamente nello stato "off" nel momento in cui cio' che sembra essere un insieme di dati binari verra' trovato nel file. Se intendete usare PGP principalmente per l'e-mail, dovreste impostare TEXTMODE=ON.

Per i sistemi VAX/VMS, la versione attuale di PGP ha default TEXTMODE=ON.

Per maggiori dettagli, si veda la sezione "Inviare file di testo ASCII attraverso macchine e ambienti diversi".

Ritorno all'Indice

Valore di default: CHARSET = NOCONV

Siccome PGP deve lavorare su messaggi scritti in molte lingue diverse dall'Inglese, con serie di caratteri non ASCII, potreste dovergli dire quale serie la vostra macchina usa. Questo specifica che conversione di caratteri dovra' essere effettuata durante la trasformazione da e verso la forma canonica. Avrete questo problema solo se lavorate in un ambiente non Inglese e non ASCII.

Il parametro CHARSET seleziona la serie di caratteri locali. le scelte possibili sono NOCONV (nessuna conversione), LATIN1 (ISO 8859-1 Latin Alphabet 1), KOI8 (usato dalla maggior parte dei sistemi Unix Russi), ALT_CODES (usato dai sistemi MSDOS Russi), ASCII e CP850 (usato dalla maggior parte delle lingue Europee occidentali sui PC MSDOS standard).

LATIN1 e' la rappresentazione interna usata da PGP per il testo canonico, quindi non viene effettuata nessuna conversione se lo selezionate. Si noti che anche KOI8 e' trattato come LATIN1, sebbene sia un carattere totalmente diverso (Russo), perche' il tentativo di convertire KOI8 sia in LATIN1 che CP850 sarebbe comunque futile. Tutto questo significa che impostare CHARSET a NOCONV, LATIN1 o KOI8 e' equivalente.

Se usate MSDOS e ritenete di dover inviare o ricevere messaggi scritti usando delle lingue Europee occidentali, impostate CHARSET= "CP850". PGP convertira' il testo canonico ricevuto da LATIN1 a CP850 dopo averlo decifrato. Se usate l'opzione -t (textmode) per convertire in testo canonico, PGP convertira' il vostro testo CP850 in LATIN1 prima di cifrarlo.

Per maggiori dettagli, si veda la sezione "Inviare file di testo ASCII attraverso macchine e ambienti diversi".

Ritorno all'Indice

Valore di default: ARMOR = off

Il Parametro ARMOR e' equivalente all'opzione -a della linea di comando. Se abilitato forza PGP a generare file cifrati o chiavi in formato ASCII radix-64, adatto a viaggiare attraverso canali di posta elettronica. I files prodotti avranno l'estensione ".asc".

Se intendete usare PGP principalmente per l'e-mail, dovreste impostare ARMOR=ON.

Per maggiori dettagli, si veda la sezione "Invio di testo cifrato via e-mail: il formato Radix-64" del "Volume I".

Ritorno all'Indice

Valore di default: ARMORLINES = 720

Quando PGP genera un file ".asc" in formato radix-64 molto grande, per spedire testo cifrato o chiavi attraverso i canali di e-mail, lo spezza in blocchi abbastanza piccoli da essere compatibili con le funzioni e-mail di Internet. Normalmente, i servizi di posta di Internet proibiscono l'invio di files piu' grandi di 50000 bytes, il che significa che se noi limitiamo il numero di linee a circa 720 siamo tranquillamente al di sotto dei limiti. I blocchi che costituiscono il file avranno estensioni ".as1", ".as2", ".as3", ...

Il parametro ARMORLINES specifica il numero massimo di linee contenute in ogni blocco costituente un file ".asc". Se lo impostate al valore zero, PGP non spezzera' il file in blocchi.

I files di e-mail di Fidonet hanno un limite di 32k bytes, quindi 450 linee costituiranno il valore adatto per quell'ambiente.

Per maggiori dettagli, si veda la sezione "Invio di testo cifrato via e-mail: il formato Radix-64" del "Volume I".

Ritorno all'Indice

Valore di default: KEEPBINARY = off

Quando PGP legge un file ".asc", riconosce il formato radix-64 e lo converte in formato binario prima di proseguire con il processo normale. Nel fare questo, PGP produce un file intermedio ".pgp" che contiene il file cifrato in formato binario. Dopo aver decifrato questo file, PGP produce un file finale contenente il testo in chiaro.

Voi potreste voler cancellare il file binario ".pgp". PGP puo' farlo automaticamente. Se doveste voler decifrare nuovamente il file, vi bastera' ripartire dal file originale ".asc".

Il parametro KEEPBINARY abilita o disabilita la conservazione del file intermedio ".pgp" dopo averlo decifrato.

Per maggiori dettagli, si veda la sezione "Invio di testo cifrato via e-mail: il formato Radix-64" del "Volume I".

Ritorno all'Indice

Valore di default: COMPRESS = on

Il parametro COMPRESS abilita o disabilita la compressione dei dati prima della cifratura. E' usato principalmente per effettuare il debug di PGP. Normalmente PGP comprime il testo in chiaro prima di cifrarlo. Dovreste generalmente lasciare stare questo parametro e permettere a PGP di comprimere.

Ritorno all'Indice

Valore di default: COMPLETES_NEEDED = 1

Il parametro COMPLETES_NEEDED specifica il numero minimo di presentatori completamente affidabili necessari per validare una chiave nel vostro portachiavi pubblico. Questo vi permette di regolare lo scetticismo di PGP.

Per maggiori dettagli, si veda la sezione "Come fa PGP a tener traccia delle chiavi valide?" nel "Volume I".

Ritorno all'Indice

Valore di default: MARGINALS_NEEDED = 2

Il parametro MARGINALS_NEEDED specifica il numero minimo di presentatori parzialmente affidabili necessari per validare una chiave nel vostro portachiavi pubblico. Questo vi permette di regolare lo scetticismo di PGP.

Per maggiori dettagli, si veda la sezione "Come fa PGP a tener traccia delle chiavi valide?" nel "Volume I".

Ritorno all'Indice

Valore di default: CERT_DEPTH = 4

Il parametro CERT_DEPTH specifica quanti livelli di presentazioni secondarie PGP dovra' accettare per certificare altri presentatori. Per esempio, se CERT_DEPTH vale 1, puo' esistere un solo livello di presentatori al di sotto della vostra chiave completamente affidabile. Se questo e' il caso, dovrete certificare personalmente le chiavi di tutti i presentatori da voi definiti affidabili. Se CERT_DEPTH vale 0, non potrete avere nessun presentatore, e dovrete certificare ogni chiave presente nel vostro portachiavi pubblico per poterla usare. Il valore minimo di CERT_DEPTH e' 0, il massimo 8.

Per maggiori dettagli, si veda la sezione "Come fa PGP a tener traccia delle chiavi valide?" nel "Volume I".

Ritorno all'Indice

Valore di default: BAKRING = ""

Tutte le certificazioni di chiavi effettuate da PGP nel vostro portachiavi pubblico, alla radice risalgono alla vostra(e) chiave(i) pubblica(he). Per scoprire una manomissione del vostro portachiavi pubblico, PGP deve controllare che non sia stata manomessa questa chiave. Per farlo, PGP deve confrontare la vostra chiave pubblica con una copia di backup della vostra chiave segreta conservata in un posto resistente alla manomissione, come per esempio un floppy disk protetto da scrittura. La chiave segreta contiene tutte le informazioni presenti anche nella vostra chiave pubblica, piu' alcune componenti segrete. Questo significa che PGP puo' verificare la vostra chiave pubblica usando come campione una copia di quella segreta.

Il parametro BAKRING specifica il percorso ed il nome del file di backup del vostro portachiavi segreto. In un sistema MSDOS, potete impostarlo come "a:\secring.pgp", per indicare una copia di backup del portachiavi segreto conservata su un floppy disk protetto da scrittura. Questo controllo viene effettuato solo quando eseguite l'opzione -kc di PGP per controllare il vostro intero portachiavi pubblico.

Se BAKRING non e' definito, PGP non effettuera' il controllo della vostra chiave.

Per maggiori dettagli, vedere le sezioni "Come proteggere il vostro portachiavi pubblico dalle manomissioni" e "Come fa PGP a tener traccia delle chiavi valide?" nel "Volume I".

Ritorno all'Indice

Valore di default: PUBRING = "$PGPPATH/pubring.pgp"

Se volete tenere il vostro portachiavi pubblico in una directory diversa da quella che contiene il file di configurazione potete specificarne il nome ed il percorso con il parametro PUBRING. Per esempio, in un sistema MSDOS, potreste tenere il portachiavi in un floppy disk specificando:

PUBRING = "a:pubring.pgp"

Questa funzione e' particolarmente pratica per evitarvi di specificare un portachiavi alternativo nella linea di comando.

Ritorno all'Indice

Valore di default: SECRING = "$PGPPATH/secring.pgp"

Se volete tenere il vostro portachiavi segreto in una directory diversa da quella che contiene il file di configurazione potete specificarne il nome ed il percorso con il parametro SECRING. Questo e' particolarmente pratico se volete tenere il portachiavi segreto in una directory o su un apparato piu' protetto di quello in cui tenete il portachiavi pubblico. Per esempio, in un sistema MSDOS, potreste tenere il portachiavi in un floppy disk specificando:

SECRING = "a:secring.pgp"

Ritorno all'Indice

Valore di default: RANDSEED = "$PGPPATH/randseed.bin"

Se volete tenere il vostro file di semi per la generazione di numeri casuali (per generare le chiavi temporanee) in una directory diversa da quella del file di configurazione, potete specificarne nome e percorso col parametro RANDSEED. Puo' essere utile se volete tenere il file su di un supporto piu' protetto di quello su cui tenete il vostro portachiavi pubblico. Ad esempio, in un sistema MSDOS, potreste voler tenere il file in un floppy disk:

RANDSEED = "a:randseed.bin"

Ritorno all'Indice

Valore di default: PAGER = ""

PGP vi permette di vedere il testo decifrato sullo schermo (come con il comando "more" di Unix) senza salvarlo in un file, usando l'opzione -m nella linea di comando per decifrare. Vedrete il testo decifrato una pagina alla volta.

Se preferite usare un'applicazione diversa da quella interna a PGP per vedere il vostro testo, potete specificarne il nome col parametro PAGER. PAGER specifica il comando che PGP dovra' eseguire per richiamare ,l'applicazione. Ad esempio, potreste voler usare il popolare programma shareware "list.com" per MSDOS. Dovrete specificare:

PAGER = "list"

Comunque, se il mittente ha specificato che il file deve solo essere presentato sullo schermo, PGP usera' sempre la propria funzione interna.

Per maggiori dettagli, si veda la sezione "Presentare il testo decifrato sullo schermo".

Ritorno all'Indice

Valore di default: SHOWPASS = off

PGP non vi permette normalmente di vedere la vostra frase chiave mentre la battete. Questo rende piu' difficile per qualcuno che potrebbe guardare da dietro le vostre spalle mentre la battete impararla. Purtroppo alcune persone con problemi di battitura trovano molto difficile battere correttamente la propria frase senza vederla, ed inoltre potrebbero usare PGP protetti dalla sicurezza delle proprie case. Cosi' e' stato richiesto che PGP potesse essere configurato per visualizzare la frase durante la battitura.

Il parametro SHOWPASS abilita PGP a darvi un riscontro a video di cio' che battete quando inserite la vostra frase chiave.

Ritorno all'Indice

Valore di default: TZFIX = 0

PGP aggiunge alle vostre chiavi ed alle vostre firme un'etichetta contenente l'ora della generazione in Greenwich Mean Time (GMT), o Coordinated Universal Time (UTC), che per questa applicazione significano la stessa cosa. Quando PGP interroga il sistema per ritrovare l'ora, assume che il sistema la fornisca in GMT.

A volte pero', a causa di un sistema MSDOS configurato in modo improprio, il tempo e' restituito in US Pacific Standard Time piu' 8 ore. Sembra bizzarro, vero ? Forse succede perche' a causa di qualche tipo di sciovinismo della costa occidentale degli Stati Uniti, MSDOS presume che l'ora locale sia comunque US Pacific Time, e la corregge per ricavarne l'ora GMT. Questo naturalmente influenza in maniera errata il comportamento della funzione interna a MSDOS che PGP richiama e che dovrebbe restituire il tempo GMT. Comunque, se la variabile di ambiente MSDOS TZ e' gia' definita correttamente, questo corregge la concezione errata di MSDOS che tutto il mondo viva sulla costa occidentale degli Stati Uniti.

Il parametro TZFIX specifica il numero di ore da aggiungere al tempo restituito dal sistema per ottenere il tempo GMT ed utilizzarlo per creare l'etichetta da aggiungere alle vostre chiavi ed alle vostre firme. Se la variabile di ambiente MSDOS TZ e' definita correttamente, potete lasciare TZFIX=0. I sistemi Unix normalmente non richiedono nessuna impostazione di TZFIX. Se state pero' usando qualche altro oscuro sistema operativo che non sa cosa sia il GMT, probabilmente dovrete impostare TZFIX in modo da correggere il tempo restituito dal sistema.

Sui sistemi MSDOS in cui TZ non e' definita all'interno dell'ambiente, dovreste definire TZFIX=0 per la California, -1 per il Colorado, -2 per Chicago, -3 per New York, -8 per Londra, -9 per Amsterdam. D'estate con l'ora legale, dovreste diminuire manualmente questi valori di 1. Che pasticcio.

Sarebbe molto piu' pulito definire la vostra variabile ambiente MSDOS TZ all'interno del file "AUTOEXEC.BAT", piuttosto che usare la correzione TZFIX. MSDOS vi fornira' delle etichette di tempo corrette, e terra' conto dell'ora legale per voi. Ecco alcuni esempi di linee da inserire in AUTOEXEC.BAT per le diverse zone:

Per Los Angeles:SET TZ=PST8PDT
Per Denver:SET TZ=MST7MDT
Per l' Arizona:SET TZ=MST7 (L'Arizona non usa mai l'ora legale)
Per Chicago:SET TZ=CST6CDT
Per New York:SET TZ=EST5EDT
Per Londra:SET TZ=GMT0BST
Per Amsterdam:SET TZ=MET-1DST
Per Mosca:SET TZ=MSK-3MSD
Per Aukland:SET TZ=NZT-13

Ritorno all'Indice

Valore di default: CLEARSIG = on

Normalmente, i messaggi firmati, ma non cifrati, da PGP hanno un certificato di firma allegato in formato binario. Il messaggio inoltre e' compresso, per cui e' illeggibile anche senza essere cifrato. Per inviare questi dati attraverso un canale e-mail a 7 bit, si applica l'armatura ASCII radix 64 (si veda il parametro ARMOR). Comunque, anche se PGP non comprime il messaggio, l'armatura ASCII lo rende sempre illeggibile. Il destinatario dovra' sempre usare PGP per togliere l'armatura, o decomprimere il messaggio, o entrambi, prima di poter leggere.

Se il messaggio originale e' composto da solo testo (non binario) e' possibile firmarlo, non comprimerlo ed applicare l'armatura ASCII solo alla firma, lasciando intatto e leggibile il messaggio. Il flag CLEARSIG abilita questa utile funzione, rendendo possibile produrre un testo firmato leggibile senza l'uso di PGP. Naturalmente PGP servira' a verificare la firma.

Il valore di default di CLEARSIG e' "on" a partire da PGP versione 2.5. Per abilitare pienamente CLEARSIG, bisogna porre ad "on" anche ARMOR e TEXTMODE. Si impostino ARMOR=ON (o si usi l'opzione -a) e TEXTMODE=ON (o opzione -t). Se nel vostro file di configurazione impostate CLEARSIG ad "off", potete ancora abilitarlo dalla linea di comando, cosi':

pgp -sta +clearsig=on lettera.txt

Questa rappresentazione del messaggio e' analoga a quella usata dal PEM (Internet Privacy Enhanced Mail) per i messaggi di tipo MIC-CLEAR. E' importante notare come siccome l'armatura ASCII e' applicata solo alla firma, e non al messaggio, ci siano dei rischi che quest'ultimo possa subire delle manomissioni accidentali strada facendo. Puo' capitare durante il passaggio dai gateway tra i diversi sistemi che effettuano una conversione della serie di caratteri, oppure possono aggiungere o togliere degli spazi al termine delle righe. Se avviene questo, la verifica della firma dara' esito negativo, dandovi una falsa indicazione di una manomissione intenzionale. Siccome pero' il PEM ha questa stessa vulnerabilita', apparentemente vale la pena di avere questa funzione nonostante i rischi.

A partire da PGP 2.2, gli spazi aggiuntivi su ogni linea sono ignorati durante la generazione della firma nel modo CLEARSIG.

Ritorno all'Indice

Valore di default: VERBOSE = 1

VERBOSE puo' valere 0, 1 o 2, e specifica quanto volete che siano dettagliati i messaggi diagnostici di PGP. In particolare:

0 - Visualizza i messaggi solo in caso di problemi. Gli appassionati di Unix hanno richiesto questo "modo silenzioso".

1 - Impostazione normale di default. Visualizza una quantita' ragionevole di dettagli nei messaggi diagnostici o di avviso.

2 - Visualizza tutte le informazioni disponibili, normalmente per diagnosticare dei problemi di PGP. Non e' consigliabile per l'uso normale. D'altra parte PGP non ha problemi, giusto ?

Ritorno all'Indice

Valore di default: INTERACTIVE = off

L'abilitazione di questo modo di funzionamento forzera' PGP a chiedere conferma prima di aggiungere al vostro portachiavi pubblico ognuna delle chiavi contenute in un file esterno.

Ritorno all'Indice

Valore di default: NOMANUAL = off

E' importante che la versione freeware di PGP non sia distribuita senza la documentazione che normalmente fa parte del pacchetto di rilascio standard. Questo manuale contiene informazioni importanti sull'uso di PGP e sugli aspetti legali del suo utilizzo. Alcune persone hanno pero' distribuito versioni precedenti di PGP senza manuali, causando molti problemi alle persone che le hanno ricevute. Per scoraggiare la distribuzione di PGP senza la documentazione richiesta, il software e' stato modificato in modo da verificare che i manuali d'uso si trovino da qualche parte nel vostro computer (per esempio nella directory di PGP), prima di permettervi di generare una coppia di chiavi. D'altra parte, alcuni utilizzatori usano PGP su di un piccolo palmtop con capacita' di registrazione limitate, sicche' vorrebbero poter evitare di occupare spazio con i manuali. Per soddisfare questa esigenza, PGP puo' essere indotto a soprassedere a questo controllo, abilitando il flag NOMANUAL durante la generazione delle chiavi, cosi':

pgp -kg +nomanual

Il flag NOMANUAL puo' essere impostato solo dalla linea di comando, non nel file di configurazione. Siccome voi dovete aver letto questo manuale per imparare ad abilitare questa funzione, spero che questa protezione sia ancora effettiva per scoraggiare la distribuzione di PGP senza manuali.

Alcune persone possono avere obiezioni al fatto che PGP pretenda di trovare i manuali da qualche parte nelle vicinanze per generare una chiave. Costoro si adirano per questo atteggiamento apparentemente autoritario. Alcune persone hanno persino modificato PGP per togliere questa funzione, ed hanno ridistribuito la loro versione ad altri. Questo mi crea dei problemi. Prima che aggiungessi questa funzione, circolavano delle versioni storpiate del pacchetto di distribuzione senza manuali. Una di esse e' stata caricata su Compuserve, e distribuita ad un numero enorme di utilizzatori che mi hanno chiamato al telefono per chiedermi come mai un programma cosi' complicato non avesse nessun manuale. Questo pacchetto e' poi finito su delle BBS in giro per tutto il Paese. Inoltre un distributore di freeware ha preso il pacchetto da Compuserve e lo ha inserito in un CD-ROM, distribuendo migliaia di copie senza manuale. Che confusione.

Ritorno all'Indice

Diamo un'occhiata ad alcune funzioni interne di PGP.

Ritorno all'Indice

PGP usa un generatore di numeri pseudocasuali crittograficamente forte per creare delle chiavi temporanee da utilizzare per la crittografia convenzionale. Il file di semi per questa funzione si chiama "randseed.bin". Puo' essere contenuto in qualunque directory abbiate inserito nella variabile di ambiente PGPPATH. Se questo file non esiste viene creato automaticamente e riempito con dei numeri effettivamente casuali derivati dal tempo che intercorre fra le vostre battute.

Il generatore rinnova il file ogni volta che viene usato mescolandogli nuovo materiale derivato in parte dall'ora del giorno ed in parte da altre fonti effettivamente casuali. Esso usa l'algoritmo di crittografia convenzionale come motore per generare numeri casuali. Il file di semi contiene sia semi casuali che chiavi casuali da usarsi per attivare il motore (la crittografia convenzionale) e generare nuovi numeri.

Questo file di semi dovrebbe come minimo essere un po' protetto dall'apertura, per ridurre il rischio che un intruso riesca a ricavare la vostra ultima o prossima chiave temporanea. L'intruso avrebbe delle serie difficolta' a trovare qualcosa di utile in questo file, perche' esso viene ripulito crittograficamente prima e dopo ogni utilizzo. Tuttavia, sembra come minimo prudente cercare di tenerlo lontano dalle mani sbagliate.

Se non vi sentite a vostro agio dovendovi fidare di una sorgente di numeri casuali derivante da un algoritmo, per quanto forte, ricordatevi che vi state gia' fidando dello stesso algoritmo per proteggere i vostri messaggi. Se e' abbastanza forte per questo, dovrebbe essere abbastanza forte da essere usato come sorgente di una chiave temporanea. Si noti che PGP usa dei numeri realmente casuali ricavati da sorgenti fisiche (principalmente gli intervalli fra le battute), per generare le coppie di chiavi pubblica/segreta da usarsi per lungo tempo.

Ritorno all'Indice

Come gia' descritto in precedenza, PGP sfrutta un algoritmo di crittografia convenzionale a chiave singola, usando un algoritmo a chiave pubblica per cifrare la chiave temporanea, e quindi sfruttando tale chiave per cifrare il messaggio in modo convenzionale piu' veloce. Parliamo quindi di questo algoritmo di cifratura convenzionale. Non e' il DES.

Il DES (Federal Data Encryption Standard) era un buon algoritmo per la maggior parte delle applicazioni commerciali. Il Governo non si e' pero' mai fidato del DES per proteggere i propri dati classificati, perche' la chiave del DES e' di soli 56 bits, abbastanza corta da soccombere ad un attacco condotto con la forza bruta. Anche il DES completo a 16 passaggi e' stato attaccato con qualche successo da Biham e Shamir con l'uso della crittoanalisi differnziale, e da Matsui con l'uso della crittoanalisi lineare.

Il piu' devastante attacco pratico portato al DES e' stato descritto alla conferenza Crypto '93, dove Michael Wiener del Bell Northern Research ha presentato un documento sull'apertura del codice DES con una macchina speciale. Egli aveva sviluppato e verificato un chip che provava 50 milioni di codici DES al secondo, fino a trovare quello giusto. Sebbene fino ad ora egli si sia astenuto dal produrre il componente in serie, puo' ottenerne la produzione per 10.50 $ al pezzo, e puo' inserirne 57000 in una macchina speciale con un costo di 1 milione di dollari. Questa macchina puo' provare tutte le chiavi DES in 7 ore, ottenendo la soluzione mediamente in 3,5 ore. Si puo' stornare e nascondere 1 milione di dollari dal budget di molte societa'. Spendendo 10 milioni di dollari la soluzione e' ottenuta in 21 minuti, e 100 milioni di dollari assicurano un tempo di 2 soli minuti. Avendo a disposizione il budget di un qualunque governo per esaminare il traffico DES, il codice puo' essere violato in alcuni secondi. Tutto questo significa che il DES a 56 bits ormai e' morto per cio' che riguarda le applicazioni serie di sicurezza dei dati.

Un possibile successore del DES potrebbe essere una variazione conosciuta come "triplo DES", che usa due chiavi DES per cifrare tre volte , raggiungendo una lunghezza effettiva della chiave di 112 bits. Questo sistema e' pero' tre volte piu' lento del DES normale. Una versione futura di PGP potrebbe supportare il triplo DES come opzione.

PGP non usa il DES come algoritmo a chiave singola, bensi' un algoritmo a chiave singola di cifratura a blocchi chiamato IDEA(tm).

Per le persone crittograficamente curiose, la cifratura IDEA utilizza blocchi di 64 bits per il testo sia in chiaro che cifrato. Essa utilizza una chiave di 128 bits. E' basata sulla filosofia della miscelazione di operazioni da diversi gruppi algebrici. E' molto piu' veloce del DES e, come il DES, puo' essere usata in modo CFB (cipher feedback) o CBC (cipher block chaining). PGP usa l'IDEA in modo CFB a 64 bits.

La cifratura a blocchi IPES/IDEA e' stata sviluppata all'ETH di Zurigo da James L. Massey e Xuejia Lai, e pubblicata nel 1990. Non e' un algoritmo "casalingo". I suoi progettisti hanno un'ottima reputazione nella comunita' dei crittografi. I primi documenti pubblicati chiamavano l'algoritmo IPES (Improved Proposed Encryption Standard), ma piu' tardi il nome e' stato cambiato in IDEA (International Data Encryption Algorithm). Fino ad ora, IDEA ha resistito agli attacchi molto meglio di altri algoritmi come FEAL, REDOC-II, LOKI, Snefru e Khafre. Prove recenti fanno ritenere che l'IDEA sia anche piu' resistente del DES agli attacchi portati da Biham e Shamir con la loro efficientissima crittoanalisi differenziale. Biham e Shamir hanno esaminato a fondo l'IDEA per trovare debolezze, senza successo. Gruppi accademici di crittoanalisti in Belgio, Inghilterra e Germania stanno cercando di attaccare l'IDEA, cosi' come i servizi militari di diversi Paesi Europei. Man mano che questo nuovo algoritmo attira le attenzioni e gli sforzi dei piu' formidabili gruppi del mondo della crittoanalisi, la fiducia in esso cresce col passare del tempo.

Ogni tanto ricevo una lettera da qualcuno che ha appena scoperto la terribile verita': PGP non usa la pura tecnica RSA per cifrare i dati. Costoro sono preoccupati dal fatto che l'intero pacchetto sia indebolito usando un sistema ibrido a chiave pubblica e convenzionale solo per rendere le cose piu' veloci. Dopo tutto, una catena e' forte come il suo anello piu' debole. Essi chiedono una spiegazione di questo apparente "compromesso" nella solidita' di PGP. Questo puo' succedere perche' sono stati presi dalla pubblica reverenza e dalla soggezione per la forza ed il misticismo dell'RSA, credendo in maniera erronea che l'RSA sia intrinsecamente piu' forte di ogni sistema di cifratura convenzionale. Bene, non lo e'.

Persone che lavorano nella ricerca industriale affermano che il carico di lavoro richiesto per esaurire tutte le chiavi possibili a 128 bits nel sistema di cifratura IDEA sarebbe grosso modo uguale a quello richiesto per violare una chiave RSA a 3100 bits, ovvero abbastanza piu' grande della chiave a 1024 che la maggior parte delle persone utilizza per le proprie applicazioni di elevata sicurezza. Data questa gamma di dimensioni delle chiavi, e supponendo che la cifratura convenzionale non contenga debolezze nascoste, l'anello debole di questa impostazione ibrida di PGP e' nell'algoritmo a chiave pubblica, e non in quello convenzionale.

Non e' ergonomicamente pratico utilizzare l'RSA puro con chiavi di elevate dimensioni per cifrare e decifrare messaggi lunghi. Una chiave RSA di 1024 bits decifrerebbe un messaggio in maniera circa 4000 volte piu' lenta della cifratura IDEA. Assolutamente nessuno fa questo nel mondo reale. Molte persone poco esperte di crittografia non capiscono che l'attrattiva di un sistema a chiave pubblica non e' la sua maggiore forza intrinseca, ma la semplicita' di gestione delle chiavi.

L'RSA non e' solo troppo lento nel maneggiare ammassi di dati, ma ha anche certe debolezze che possono essere sfruttate in casi speciali di messaggi particolari forniti in ingresso, anche con chiavi molto grosse. Questi casi speciali possono essere evitati con l'approccio ibrido che usa l'RSA per cifrare una chiave temporanea per una crittografia convenzionale, come fa PGP. Quindi la linea di fondo e' questa: usare l'RSA puro per ammassi di dati e' l'approccio sbagliato, punto. E' troppo lento, non e' piu' forte, e puo' perfino essere piu' debole. Se trovate un'applicazione software che usa l'RSA per ammassi di dati, probabilmente significa che chi l'ha sviluppata non ha capito questi punti, il che implica che probabilmente non ha capito nemmeno altri concetti importanti della crittografia.

Ritorno all'Indice

PGP normalmente comprime il testo in chiaro prima di cifrarlo. Sarebbe troppo tardi cercare di comprimerlo dopo la cifratura; il testo cifrato e' incomprimibile. La compressione dei dati fa risparmiare tempo nella trasmissione via modem, spazio sul disco, e soprattutto aumenta la sicurezza della cifratura. Molte tecniche di crittoanalisi sfruttano le ridondanze presenti nel testo in chiaro per violare la cifratura. La compressione dei dati riduce questa ridondanza nel testo in chiaro, migliorando molto la resistenza a questo tipo di analisi. Comprimere il testo richiede tempo, ma dal punto di vista della sicurezza sembra valga il disturbo, almeno secondo la mia cauta opinione.

I files troppo corti, o che semplicemente non si comprimono bene, non sono compressi da PGP.

Se preferite, potete usare PKZIP per comprimere il testo in chiaro prima di cifrarlo. PKZIP, di PKWare, Inc., e' un' applicazione di compressione shareware per MSDOS molto efficace e disponibile ovunque. Potete anche usare ZIP, un' applicazione freeware per Unix compatibile con PKZIP disponibile presso Jean-Loup Gailly. In alcuni casi avrete dei vantaggi usando PKZIP o ZIP perche', a differenza della funzione di compressione di PGP, PKZIP e ZIP danno la simpatica possibilita' di immagazzinare piu' di un file nello stesso file compresso. PGP non tentera' di comprimere un file gia' compresso. Dopo la decifrazione, il destinatario potra' decomprimere il testo in chiaro usando PKUNZIP. Se il file decifrato e' un file compresso con PKZIP, PGP lo riconosce automaticamente e lo segnala al destinatario.

Per i lettori tecnicamente curiosi, la versione corrente di PGP usa la routine freeware ZIP scritta da Jean-Loup Gailly, Mark Adler e Richard B. Wales. Questo software ZIP usa un algoritmo di compressione funzionalmente equivalente a quello usato da PKZIP 2.0 di PKWare. E' stato scelto ZIP principalmente per la disponibilita' del codice sorgente in C liberamente portabile, perche' ha un rapporto di compressione veramente buono, e perche' e' veloce.

Peter Gutmann ha scritto una bella applicazione di compressione chiamata HPACK disponibile liberamente presso molti siti FTP di Internet. Essa cifra gli archivi compressi usando il formato dei dati di PGP ed i portachiavi. Egli ha voluto che la menzionassi qui.

Ritorno all'Indice

Per creare una firma digitale, PGP effettua una cifratura con la vostra chiave segreta. PGP non cifra effettivamente tutto il messaggio con la chiave segreta-- ci vorrebbe troppo tempo. In effetti cifra una "selezione del messaggio".

La selezione del messaggio e' un "distillato" compatto (128 bits) del messaggio, simile come concetto ad un checksum. Potete anche pensare ad esso come ad un'"impronta digitale" del messaggio. La selezione di messaggio "rappresenta" il vostro messaggio, cosicche' qualunque alterazione del messaggio stesso fara' si' che esso produca una selezione differente. Questo rende possibile controllare se una simile alterazione e' effettivamente avvenuta ad opera di un falsario. La selezione di messaggio e' calcolata usando una funzione di complicazione a senso unico e crittograficamente forte. Sarebbe praticamente impossibile per un estraneo riuscire a realizzare un messaggio falso che produca la stessa selezione. Da questo punto di vista, una selezione di messaggio e' migliore di un semplice checksum, perche' e' abbastanza facile sviluppare un messaggio che produca un checksum uguale. Come per un checksum comunque, e' impossibile ricavare un messaggio partendo dalla sua selezione.

Una selezione da sola non e' sufficiente ad autenticare un messaggio. L'algoritmo di generazione e' conosciuto pubblicamente, e non richiede la conoscenza di nessuna chiave per essere applicato. Se tutto cio' che facciamo e' allegare una selezione al messaggio, un falsario puo' alterare il messaggio e semplicemente allegare una nuova selezione ricavata dal messaggio falso. Per effettuare una vera autenticazione, il mittente deve cifrare (firmare) la selezione del messaggio con la propria chiave segreta.

La selezione di messaggio e' calcolata dal mittente, che usa la propria chiave segreta per cifrarla assieme ad un'etichetta di tempo, creando cosi' una firma digitale, o certificato di firma. Questa firma e' poi spedita allegandola al messaggio. Il destinatario riceve il messaggio e la firma e ricupera la selezione originale decifrandola con la chiave pubblica del mittente. Se selezione e messaggio corrispondono, il messaggio non e' stato alterato, e proviene dal proprietario della chiave pubblica usata per controllare la firma.

Un potenziale falsario dovrebbe produrre un messaggio che crei la stessa selezione (e non e' praticabile), oppure creare una nuova firma partendo dal messaggio falso (e non e' praticabile senza possedere la chiave segreta del mittente).

Le firme digitali provano l'identita' del mittente, e la genuinita' del messaggio (il messaggio non e' stato alterato ne' per errore, ne' per dolo). Inoltre le firme impediscono di ripudiare il messaggio, perche' per il mittente non e' semplice rinnegare la propria firma apposta con la propria chiave segreta.

Oltre ad essere piu' veloce che firmare direttamente tutto il messaggio, l'uso delle selezioni presenta altri vantaggi. La firma puo' essere di un formato piccolo e standard, indipendente dal formato del messaggio. Il software puo' controllare automaticamente l'integrita' del messaggio, in modo simile all'uso del checksum. La firma puo' restare separata dal messaggio, forse addirittura in un archivio pubblico, senza rivelare informazioni importanti sul messaggio stesso, perche' nessuno puo' ricavare il contenuto del messaggio dalla sua selezione.

L'algoritmo di selezione del messaggio usato qui e' l'MD5 Message Digest Algorithm, reso di pubblico dominio dalla RSA Data Security, Inc. Il progettista, Ronald Rivest, ha scritto di MD5 quanto segue:

"Si suppone che la probabilita' di trovare due messaggi che producano la stessa selezione sia di 1 contro 2^64, mentre la probabilita' di riuscire a scrivere un messaggio che produca una selezione data e' dell'ordine di 1 contro 2^128. L'algoritmo MD5 e' stato verificato scrupolosamente per trovare delle debolezze. Comunque e' un algoritmo relativamente nuovo, ed ulteriori analisi sulla sua sicurezza sono ovviamente giustificate, come per ogni nuovo prodotto di questo tipo. Il livello di sicurezza fornito da MD5 dovrebbe essere sufficiente per sviluppare schemi ibridi di firma digitale altamente sicuri basati su di esso e sul sistema di cifratura a chiave pubblica RSA."

Ritorno all'Indice

PGP versione 2.6 puo' leggere qualunque cosa prodotta con le versioni da 2.3 a 2.7. A causa di un accordo negoziato tra il MIT e l'RSA pero'. PGP 2.6 e' stato programmato in modo da cambiare leggermente il suo comportamento a partire dal 1 settembre 1994. Da quella data, PGP comincera' ad utilizzare un formato nuovo e leggermente diverso per i messaggi, le firme e le chiavi. Sara' ancora in grado di leggere ed elaborare messaggi, firme e chiavi prodotti con il vecchio formato, ma generera' quello nuovo. Questo cambiamento e' teso a scoraggiare l'uso delle versioni vecchie (2.3a o piu' vecchie) di PGP, i cui contenuti Publc Key Partners possono violare il brevetto RSA (si veda la sezione dedicata agli aspetti legali). Il PGP di ViaCrypt (si veda la sezione "Come ottenere una versione commerciale di PGP"), versioni 2.4 e 2.7, evita i problemi di brevetti grazie agli accordi di licenza con Public Key Partners. PGP 2.5 e 2.6 evitano questi problemi usando RSAREF(tm) Cryptographic Toolkit, su licenza di RSA Data Security, Inc.

Al di fuori degli Stati Uniti, il brevetto RSA non e' valido, cosi' gli utilizzatori di PGP sono liberi di usare implementazioni non basate su RSAREF e sulle sue restrizioni. Si vedano le note sulle versioni internazionali nella sezione di questo manuale dedicata agli aspetti legali. Sembra probabile che qualunque versione di PGP preparata al di fuori degli Stati Uniti accettera' il nuovo formato, la cui descrizione dettagliata e' disponibile presso il MIT. Se tutti acquisiranno le versioni nuove prima di settembre 1994, o poco dopo, ci saranno pochi problemi di interoperabilita'.

Questo cambio di formato a partire dalla versione 2.6 e' simile al processo naturale per cui, quando si aggiungono nuove funzioni, le versioni vecchie di PGP non sono in grado di leggere il materiale prodotto dalle versioni nuove, mentre le versioni nuove conservano la capacita' di leggere quello prodotto dalle versioni vecchie. L'unica differenza in questo caso, e' che si tratta di un aggiornamento "legale" invece che tecnico. Vale la pena di effettuare questo cambiamento, se puo' portare la pace nei nostri giorni.

Secondo ViaCrypt, che vende la versione commerciale di PGP, il suo PGP si evolvera' per mantenere l'interoperabilita' con la versione freeware.

Un'altro cambiamento influenza l'interoperabilita' con le versioni precedenti di PGP. Sfortunatamente, a causa dei limiti sul formato dei dati imposti da RSAREF, PGP 2.5 e 2.6 non possono interpretare nessun messaggio o firma prodotti con le versioni 2.2 o precedenti. Siccome non abbiamo altra scelta se non usare il nuovo formato, a causa della necessita' di utilizzare RSAREF, non possiamo fare niente per risolvere questo problema.

A partire dalla versione 2.4 (ovvero la prima versione di ViaCrypt) fino almeno alla 2.6, PGP non vi permette di generare chiavi piu' lunghe di 1024 bits. Si e' sempre pensato al limite superiore di 1024 bits -- deve esserci un limite superiore, per ragioni di prestazioni ed interoperabilita'. A causa pero' di un difetto nelle versioni precedenti di PGP, era possibile generare chiavi piu' lunghe di 1024 bits. Queste chiavi piu' grandi causavano problemi di interoperabilita' fra le diverse versioni piu' vecchie di PGP, che usavano algoritmi aritmetici differenti con formati diversi delle parole. Su alcune piattaforme PGP si inchiodava sulle chiavi piu' grosse. Oltre a questi vecchi problemi di formato di chiavi, il limite di 1024 bits e' ora anche imposto da RSAREF. Una chiave di 1024 bits e' molto probabilmente al di la' delle possibilita' di attacco dei principali governi. Nelle versioni future, PGP potra' maneggiare chiavi piu' grosse.

In generale c'e' compatibilita' dalla versione 2.0 fino alla 2.4. A causa dell'aggiunta di nuove funzioni, le versioni piu' vecchie potrebbero non essere sempre in grado di maneggiare alcuni files creati con le versioni piu' nuove. A causa poi di importanti cambiamenti negli algoritmi e nella struttura dei dati, la versione 2.0 e quelle successive non sono minimamente compatibili con la versione 1.0, che comunque non e' piu' usata da nessuno.

Le versioni future di PGP potranno dover cambiare il formato dei dati nei messaggi, nelle firme, nelle chiavi e nei portachiavi, per poter sviluppare nuove importanti funzioni. Ci sforzeremo di sviluppare nuove versioni che maneggino chiavi, firme e messaggi prodotti dalla versione presente, ma non e' garantito che ci riusciremo. I futuri rilasci potranno contenere delle applicazioni per convertire le chiavi vecchie, ma potreste dover eliminare tutti i vecchi messaggi creati col vecchio PGP. Inoltre, la versione corrente potrebbe non essere in grado di leggere il materiale prodotto dalle versioni future.

Ritorno all'Indice

Vulnerabilita'

Nessun sistema per la sicurezza dei dati e' impenetrabile. PGP puo' essere raggirato in molti modi. A proposito di ogni sistema di sicurezza, dovete chiedervi se le informazioni che cercate di proteggere hanno per l'intruso un valore superiore al costo dell'intrusione. Questo dovrebbe guidarvi a proteggervi dagli attacchi piu' economici, senza preoccuparvi di quelli che comportano alti costi.

Alcuni dei punti che seguono possono sembrare indebitamente paranoici, ma questo tipo di atteggiamento e' appropriato per una discussione ragionevole sui temi della vulnerabilita'.

Ritorno all'Indice

E' probabile che l'attacco piu' semplice sia quello che puo' essere portato se scrivete da qualche parte la frase chiave che sblocca la vostra frase segreta. Se qualcuno la ottiene, assieme al vostro portachiavi segreto, puo' leggere i vostri messaggi e firmare a vostro nome.

Non usate parole chiave ovvie facilmente intuibili, come i nomi dei vostri figli o di vostra/o moglie/marito. Se come frase chiave usate una sola parola, essa puo' essere scoperta facilmente con un computer che provi tutte le parole del dizionario fino ad individuare quella giusta. E' per questo che una frase chiave e' molto meglio di una parola chiave. Un attaccante piu' sofisticato potrebbe utilizzare il suo computer per cercare in un libro di citazioni famose la vostra frase chiave. Una frase chiave facile da ricordare e difficile da indovinare puo' essere ricavata da certi modi di dire creativi e senza senso, oppure da citazioni letterarie veramente oscure.

Per maggiori dettagli si veda la sezione "Come proteggere il portachiavi segreto dall'apertura" nel "Volume I".

Ritorno all'Indice

Una vulnerabilita' maggiore puo' esistere se la vostra chiave pubblica e' stata manomessa. Questa puo' essere la vulnerabilita' piu' cruciale di un sistema di crittografia a chiave pubblica, in parte perche' alcuni nuovi utilizzatori potrebbero non riconoscerla immediatamente. L'importanza di questa vulnerabilita' e le appropriate contromisure sono dettagliate nella sezione "Come proteggere il vostro portachiavi pubblico dalle manomissioni" nel "Volume I".

Per riassumere: quando usate la chiave pubblica di qualcuno, siate certi che non sia stata manomessa. Vi dovete fidare di una nuova chiave pubblica che avete ricevuto solo se l'avete ricevuta direttamente dal proprietario, o se e' firmata da qualcuno di cui vi fidate. Siate sicuri che nessuno possa manomettere il vostro portachiavi pubblico. Mantenete il controllo fisico dei vostri portachiavi sia pubblico che segreto, preferibilmente sul vostro PC piuttosto che in un sistema remoto multiutente. Conservate una copia di backup di entrambi i portachiavi.

Ritorno all'Indice

Un altro potenziale problema per la sicurezza e' causato dal modo in cui la maggior parte dei sistemi operativi cancella i files. Quando voi cifrate un file e poi cancellate il testo in chiaro, il sistema operativo non cancella effettivamente e fisicamente i dati. Semplicemente etichetta il settore di disco come cancellato, permettendone un uso successivo. E' come eliminare dei documenti cartacei classificati mettendoli nel cestino della carta da riciclare, anziche' nel distruggi-documenti. Il settore di disco continua a contenere i dati classificati che volevate cancellare, e sara' probabilmente sovrascritto da dati nuovi nel futuro. Se un intruso legge questo settore di disco poco dopo il vostro utilizzo, puo' recuperare il vostro file.

In effetti questo puo' anche accadere accidentalmente, se per qualche ragione capita qualcosa di strano al disco e dei files vengono cancellati o corrotti. Qualcuno puo' utilizzare un programma di recupero del disco per ricostruire i files danneggiati, ma spesso questo significa che anche altri files cancellati in precedenza sono ripristinati insieme al resto. I vostri files classificati, da voi ritenuti distrutti per sempre, possono riapparire ed essere esaminati da chiunque stia cercando di recuperare il disco danneggiato. Anche quando state producendo il messaggio originale con un word processor, il programma potrebbe creare diverse copie temporanee del vostro testo sul disco, a causa del suo modo di funzionare. Queste copie temporanee sono cancellate dal word processor a fine lavoro, ma i dati sono ancora da qualche parte nel disco.

Lasciatemi raccontare una vera storia dell'orrore. Una mia amica, sposata e con figli piccoli, una volta ha avuto una breve relazione, niente di serio. Scrisse una lettera al suo amante usando un word processor, e la cancello' dopo averla spedita. Tempo dopo, a storia finita, il floppy disk fu danneggiato in qualche modo, e dovette recuperarlo, perche' conteneva altri documenti importanti. Chiese a suo marito di salvare il disco, cosa che le sembrava completamente sicura perche' sapeva di aver cancellato la lettera incriminante. Il marito utilizzo un pacchetto commerciale di recupero dei dischi, e recupero' tutti i files, compresa la lettera cancellata. La lesse, e questo diede luogo a tutta una tragica catena di eventi.

L'unico modo per prevenire la ricomparsa di un file cancellato e' sovrascriverlo in qualche modo. A meno che non siate sicuri che i settori di disco cancellati saranno presto riusati, dovete prendere le vostre misure per effettivamente sovrascrivere il testo in chiaro e tutti i frammenti sparsi sul disco dal vostro word processor. Potete sovrascrivere il testo in chiaro originale dopo averlo cifrato usando l'opzione -w (wipe) di PGP. Potete prendervi cura dei frammenti sparsi sul vostro disco usando qualunque programma di gestione dei dischi disponibile che possa sovrascrivere tutti i blocchi non usati. Ad esempio le Norton Utilities per MSDOS contengono questa funzione.

Anche se avete sovrascritto i dati sul vostro disco, un aggressore determinato e ricco di risorse potrebbe ancora recuperarli. Delle deboli tracce magnetiche dei dati originali rimangono sul disco dopo la sovrascrittura. Degli apparati sofisticati per il recupero dei dischi possono talvolta essere usati per il recupero di questo tipo di dati.

Ritorno all'Indice

Un'altro attacco puo' essere portato da qualche forma di virus o"verme" ostile e dedicato che potrebbe infestare PGP o il vostro sistema operativo. Questo virus ipotetico potrebbe essere progettato per catturare la vostra frase chiave, la vostra chiave segreta o i messaggi decifrati, e scrivere di nascosto le informazioni in un file, o inviarle attraverso una rete al suo padrone. Oppure potrebbe influenzare il comportamento di PGP per far si' che non controlli le firme in maniera completa. Questo tipo di attacco e' piu' economico di quello crittoanalitico.

La difesa da questo attacco rientra nella categoria generale della difesa dalle infezioni virali. Sono disponibili commercialmente alcuni anti-virus moderatamente efficaci, e ci sono delle procedure igieniche da seguire che riducono molto il rischio di queste infezioni. Una trattazione completa sulle contromisure anti-virus e anti-vermi e' al di la' degli scopi di questo documento. PGP non ha difese contro i virus, ed assume che il vostro personal computer sia un ambiente di esecuzione degno di fiducia. Se questo tipo di virus o di verme dovesse apparire, e' auspicabile che la notizia sarebbe diffusa presto, avvisando tutti.

Un'altro attacco simile potrebbe essere portato da qualcuno capace di creare un'intelligente imitazione di PGP che si comporti come PGP per la maggior parte degli aspetti, ma che non lavori nel modo atteso. Per esempio, potrebbe essere deliberatamente menomata per non controllare le firme nel modo necessario, permettendo l'accettazione di certificati di chiave fasulli. Questa versione "cavallo di Troia" di PGP non e' difficile da creare per un assalitore, perche' il codice sorgente di PGP e' largamente disponibile, quindi chiunque potrebbe modificarlo e produrre uno zombie lobotomizzato ad imitazione di PGP che sembri reale, ma esegua i voleri del suo diabolico padrone. Questa versione cavallo di Troia di PGP potrebbe quindi essere distribuita largamente ed attribuita a me. Molto insidioso.

Dovreste fare uno sforzo per procurarvi la vostra copia di PGP presso una fonte affidabile, qualunque cosa questo significhi. Oppure procuratevela presso piu' fonti indipendenti, e comparate le diverse copie con un'applicazione di confronto di files.

Ci sono altri modi per controllare che PGP non sia stato manomesso, con l'impiego delle firme digitali. Se qualcuno di cui vi fidate firma la versione eseguibile di PGP, garantendo il fatto che non e' stata infettata o manomessa, potete essere ragionevolmente sicuri di avere una copia genuina. Potete usare una versione precedente ed affidabile di PGP per controllare la firma sulla versione nuova e sospetta. Questo pero' non vi aiutera' per niente se il vostro sistema operativo e' infetto, e non scoprira' se la vostra copia originale di PGP.EXE e' stata maliziosamente alterata in modo da comprometterne la capacita' di controllare le firme. Questo tipo di controllo parte anche dall'assunzione che voi possediate una copia affidabile della chiave pubblica che usate per verificare la firma.

Vi raccomando di non fidarvi della vostra copia di PGP, a meno che non sia stata originariamente distribuita dal MIT o da ViaCrypt, oppure abbia un mio visto firmato. Ogni nuova versione e' distribuita assieme ad una o piu' firme digitali comprese nel pacchetto, firmate dall'autore del pacchetto stesso. Normalmente si tratta di qualcuno che rappresenta il MIT o ViaCrypt, o chiunque abbia rilasciato la versione. Controllate le firme della versione che prendete. Ho effettivamente visto delle versioni fasulle del pacchetto di distribuzione di PGP, anche presso canali di distribuzione di freeware apparentemente affidabili, come distributori di CD-ROM e Compuserve. Controllate sempre la firma quando prendete una nuova versione.

Ritorno all'Indice

Una breccia nella vostra sicurezza fisica puo' permettere a qualcuno di acquisire (fisicamente appunto) i vostri files in chiaro o i vostri messaggi stampati. Un avversario determinato puo' realizzare questa breccia con il furto, la raccolta dei rifiuti, sequestri e perquisizioni irragionevoli, la truffa, il ricatto o l'inserimento di infiltrati fra il vostro personale. Alcuni di questi attacchi sono particolarmente applicabili ai danni di organizzazioni politiche di base che dipendono da personale in larga parte volontario. E' stato ampiamente riportato dalla stampa che il programma COINTELPRO dell'FBI ha utilizzato il furto, l'infiltrazione e l'uso illegale di microfoni nascosti ai danni di gruppi contro la guerra e di difesa dei diritti umani. E guardate cosa e' successo all'hotel Watergate.

Non cullatevi in un falso senso di sicurezza solo perche' possedete un programma di crittografia. Le tecniche di crittografia proteggono i vostri dati solo finche' sono cifrati-- la violazione della sicurezza fisica puo' ancora compromettere i dati in chiaro o le informazioni scritte e dette.

Questo tipo di attacco e' piu' economico della crittoanalisi.

Ritorno all'Indice

Un altro tipo di attacco che e' stato condotto da oppositori ben equipaggiati comporta il rilevamento dei segnali elettromagnetici emessi dal vostro computer. Questo attacco, costoso in termini di denaro e di carico di lavoro, e' probabilmente ancora piu' economico di un attacco crittoanalitico diretto. Un furgone appropriatamente strumentato viene parcheggiato vicino al vostro ufficio, e rileva da lontano tutte le vostre battute sulla tastiera ed i messaggi visualizzati sullo schermo. Questo comprometterebbe tutto: parole chiave, messaggi, ecc. Questo attacco puo' essere reso vano schermando adeguatamente tutti i componenti del vostro computer ed i cavi di rete, in modo che non emettano nessun segnale. Questa tecnologia di schermatura e' conosciuta come "Tempest", ed e' utilizzata da alcune agenzie governative e dai fornitori della difesa. Esistono dei venditori di hardware che forniscono commercialmente la schermatura Tempest, sebbene essa potrebbe essere legata a qualche tipo di licenza rilasciata dal Governo. Ora, per quale motivo potete supporre che il Governo restringerebbe l'accesso alla schermatura Tempest ?

Ritorno all'Indice

PGP e' stato originariamente progettato per una macchina MSDOS a singolo utente e sotto il vostro diretto controllo fisico. Io uso PGP a casa sul mio PC e, a meno che qualcuno entri con la forza in casa mia o monitorizzi le emissioni elettromagnetiche, probabilmente nessuno potra' vedere i miei testi in chiaro o le mie chiavi segrete.

Adesso pero', PGP gira anche su sistemi multi-utente, come Unix e VAX/VMS. Su questi sistemi, il rischio che i vostri testi in chiaro o le vostre frasi chiave siano esposti e' piu' grande. L'amministratore del sistema Unix o un intruso intelligente possono leggere il vostro testo in chiaro, o forse anche usare programmi speciali per rilevare di nascosto le vostre battute sulla tastiera o cio' che si vede sul vostro schermo. In un sistema Unix, qualunque altro utente puo' leggere le informazioni sul vostro ambiente semplicemente usando il comando "ps". Esistono problemi simili per le macchine MSDOS connesse ad una rete locale. I rischi effettivi per la sicurezza dipendono dalla vostra particolare situazione. Alcuni sistemi multi-utente possono essere sicuri perche' tutti gli utilizzatori sono fidati, o perche' hanno misure di sicurezza di sistema in grado di fronteggiare gli attacchi possibili da parte degli intrusi, o ancora semplicemente perche' non ci sono sufficienti potenziali intrusi interessati. Alcuni sistemi Unix sono sicuri perche' hanno un solo utente-- Ci sono persino alcuni notebook con l'ambiente Unix. Sarebbe irragionevole decidere semplicemente di escludere PGP da tutti i sistemi Unix.

PGP non e' nato per proteggere i vostri dati mentre sono in chiaro o su di un sistema compromesso. Non puo' nemmeno impedire che un intruso utilizzi misure sofisticate per leggere la vostra chiave segreta mentre la usate. Voi dovrete semplicemente riconoscere questi rischi in un sistema multi-utente, e regolare di conseguenza le vostre aspettative ed il vostro comportamento. Forse la vostra situazione e' tale da consigliarvi di usare PGP solo su di un sistema isolato a singolo utente e sotto il vostro diretto controllo fisico. E' cio' che faccio io, ed e' cio' che raccomando.

Ritorno all'Indice

Anche se un assalitore non puo' leggere il contenuto dei vostri messaggi cifrati, egli potrebbe essere capace di dedurre come minimo alcune informazioni utili osservando da dove arrivano i messaggi e dove sono diretti, le dimensioni dei messaggi e l'ora del giorno in cui sono stati spediti. E' equivalente alla sorveglianza che puo' essere effettuata controllando la vostra bolletta del telefono per vedere chi avete chiamato, quando e quanto e' durata la conversazione anche senza conoscere l'effettivo contenuto di quest'ultima. Si chiama analisi del traffico. PGP da solo non puo' proteggervi dall'analisi del traffico. La soluzione di questo problema richiederebbe l'uso di protocolli di comunicazione specializzati nel ridurre l'esposizione del vostro ambiente operativo, possibilmente con l'assistenza di un po' di crittografia.

Ritorno all'Indice

Una vulnerabilita' di PGP in qualche modo oscura e' causata da utenti disonesti che possono creare delle etichette temporali fasulle sui propri certificati di chiave o sulle proprie firme. Potete tralasciare la lettura di questa sezione se siete utilizzatori casuali, e non siete coinvolti profondamente nei protocolli oscuri delle chiavi pubbliche.

Non c'e' niente che possa impedire ad un utilizzatore disonesto di alterare l'orologio interno del suo sistema, creando un certificato di chiave od una firma che sembrino creati in un momento diverso. Egli puo' simulare di aver firmato qualcosa prima o dopo rispetto a quando l'ha effettivamente fatto, oppure di aver generato una coppia di chiavi prima o dopo. Questo puo' portargli dei benefici legali o finanziari, per esempio creando qualche tipo di scappatoia che potrebbe permettergli di ripudiare una firma.

A mio giudizio, il problema delle etichette temporali fasulle nelle firme digitali non e' peggiore di quello gia' esistente per le firme scritte. Chiunque puo' scrivere vicino alla propria firma su di un contratto la data che preferisce, eppure nessuno sembra preoccuparsi piu' di tanto per questo stato di cose. In alcuni casi, una data "inesatta" vicino ad una firma puo' anche non essere associata con una truffa effettiva. La data vicino alla firma puo' indicare il momento in cui il documento e' stato firmato, oppure il momento in cui si vuole che acquisti validita'.

In situazioni in cui si ritiene essenziale avere la certezza che la data sia veritiera, le persone si rivolgono ai notai, che presenziano durante la scrittura della firma e appongono la data. La situazione corrispondente nel campo delle firme digitali consiste nell'avere una terza persona fidata che firmi il certificato di firma stesso, applicando un'etichetta di tempo valida. Non serve nessun protocollo esotico od eccessivamente formale per fare questo. Le firme dei testimoni sono da lungo tempo considerate come una maniera legittima di determinare quando un documento e' stato firmato.

Un'autorita' di certificazione degna di fiducia od un notaio possono generare firme notarili con un'etichetta di tempo affidabile. Questo non richiederebbe necessariamente un'autorita' centralizzata. Forse qualunque presentatore affidabile o qualunque parte disinteressata potrebbe assolvere questa funzione, nello stesso modo in cui e' svolta dai notai pubblici. Quando un notaio sottoscrive le firme di altre persone, crea un certificato di firma di un certificato di firma. Questo serve come testimonianza nello stesso modo in cui i veri notai ora testimoniano per le firme scritte. Il notaio potrebbe inserire il certificato di firma separato dal documento (e senza l'intero documento) in uno speciale registro da lui gestito e leggibile da tutti. La firma del notaio avrebbe un'etichetta di tempo fidata, che potrebbe avere una credibilita' piu' grande o piu' valore legale dell'etichetta allegata alla firma originale.

Un'ottima trattazione di questo argomento e' contenuta in un articolo di Denning del 1983 apparso su IEEE Computer (si vedano i riferimenti). Futuri miglioramenti di PGP potranno contenere delle funzioni per maneggiare facilmente le firme notarili con etichette di tempo affidabili.

Ritorno all'Indice

Un attacco crittoanalitico formidabile e costoso potrebbe essere organizzato da qualcuno che abbia accesso a vaste risorse di supercomputer, come un'agenzia di informazioni governativa. Costoro potrebbero aprire la vostra chiave RSA usando qualche nuova scappatoia segreta. Forse puo' succedere, ma e' utile notare che il Governo degli Stati Uniti si fida dell'algoritmo RSA abbastanza da usarlo in certi casi per proteggere le proprie armi nucleari, secondo Ron Rivest. Inoltre le accademie civili attaccano intensivamente e senza successo questo codice sin dal 1978.

E' possibile che il Governo abbia qualche metodo classificato per violare l'algoritmo di crittografia convenzionale IDEA(tm) usato da PGP. Questo e' il peggiore incubo di ogni crittografo. Nelle applicazioni pratiche della crittografia la sicurezza assoluta e garantita non esiste.

Eppure, un po' di ottimismo sembra giustificato. I progettisti di IDEA sono fra i migliori crittografi Europei. Ci sono state profonde ed intensive analisi di sicurezza da parte di alcuni dei migliori crittografi del mondo non classificato. IDEA sembra avere alcuni vantaggi di progetto rispetto al DES per affrontare la crittoanalisi lineare e differenziale, usata per violare il DES.

D'altra parte, anche se questo algoritmo avesse qualche sottile debolezza sconosciuta, PGP comprime il testo in chiaro prima di cifrarlo, cosa che dovrebbe ridurre fortemente i rischi. E' probabile che il carico di lavoro necessario per rompere questo codice sia di gran lunga piu' costoso di quello che e' il valore del messaggio.

Se la vostra situazione giustifica le preoccupazioni per un attacco di questo calibro, forse dovreste rivolgervi a qualche consulente per la sicurezza dei dati per sviluppare un sistema di sicurezza dedicato alle vostre specifiche necessita'. La Boulder Software Engineering (indirizzo e telefono sono riportati alla fine di questo documento) puo' fornire questo tipo di servizio.

Riassumendo, senza una protezione crittografica adeguata delle vostre trasmissioni di dati, puo' essere praticamente un lavoro privo di sforzi, o addirittura di routine intercettare i vostri messaggi, specialmente se inviati con un modem o attraverso i canali e-mail. Se usate PGP ed adottate delle precauzioni ragionevoli, gli aggressori dovranno impiegare molti piu' sforzi ed affrontare molte spese per violare la vostra riservatezza.

Se vi proteggete contro gli attacchi piu' semplici, e vi sentite sicuri del fatto che la vostra riservatezza non sara' violata da aggressori determinati e ricchi di risorse, probabilmente sarete al sicuro usando PGP. PGP vi dara' una riservatezza abbastanza buona (Pretty Good Privacy).

Ritorno all'Indice

Aspetti legali

Ritorno all'Indice

"PGP", "Pretty Good Privacy", "Phil's Pretty Good Software", e l'etichetta "Pretty Good" per i prodotti hardware e software per i computer sono marchi registrati di Philip R. Zimmermann.

PGP e' (c) Copyright Philip R. Zimmermann, 1990-1994. Tutti i diritti sono riservati. Anche questo manuale d'uso di PGP e' Copyright Philip R. Zimmermann 1990-1994. Tutti i diritti sono riservati. Questi diritti includono, ma non sono limitati a questo, anche tutte le traduzioni in qualunque lingua del manuale o del software, e tutto il lavoro che da essi puo' derivare.

Il MIT puo' avere diritto di copia sul particolare pacchetto di distribuzione disponibile nel suo sito FTP. Questo Copyright sulla compilazione del pacchetto di distribuzione non implica in nessun modo che il MIT abbia dei diritti di copia sul PGP stesso, o sulla documentazione d'uso.

L'autore non assume nessuna responsabilita' per i danni che possano derivare dall'uso di questo software, anche se dovessero essere causati da difetti del software stesso, e non da' alcuna indicazione a proposito del valore di mercato di questo software o della sua applicabilita' a specifiche situazioni. Il software e' fornito "cosi' come e'", senza garanzie esplicite o implicite di qualsiasi tipo. Siccome determinate azioni possono portare alla cancellazione di files o alla loro irrecuperabilita', l'autore non assume nessuna responsabilita' per la perdita o modifica di qualunque dato.

Ritorno all'Indice

Il sistema di crittografia a chiave pubblica e' stato sviluppato dal MIT, che detiene un brevetto su di esso (U.S. patent #4,405,829, del 20 settembre 1983). Una societa' californiana, la Public Key Partners, detiene una licenza commerciale esclusiva per vendere il sistema o autorizzarne l'impiego. Il MIT distribuisce una versione freeware di PGP secondo i termini della licenza RSAREF rilasciata da RSA Data Security, Inc. (RSADSI).

Al momento della stesura di questo documento (settembre 1994), sembra che PKP potrebbe presto cessare di esistere, nel qual caso il brevetto che detiene potrebbe cadere in altre mani. Il brevetto RSA potrebbe finire con RSADSI.

Gli utilizzatori di PGP al di fuori degli USA dovrebbero tener conto che il brevetto RSA non e' applicabile fuori dai confini e, almeno al momento della stesura del documento, l'autore non e' al corrente di nessun brevetto RSA in altri Paesi. Alcune agenzie federali potrebbero usare l'algoritmo RSA, poiche' il suo sviluppo e' stato finanziato dal Governo con sovvenzioni dalla National Science Foundation e dalla Marina. Nonostante il fatto che gli utilizzatori governativi abbiano accesso libero all'algoritmo RSA, l'uso di PGP da parte del Governo ha delle restrizioni addizionali imposte dall'accordo esistente tra me e ViaCrypt, come spiegato piu' avanti.

Io ho scritto il mio software PGP da zero, con una mia implementazione sviluppata indipendentemente dell'algoritmo RSA. Prima di pubblicare PGP nel 1991, ho ottenuto un'opinione legale scritta e formale da un avvocato specializzato in brevetti con una grande esperienza in brevetti sul software. Sono convinto che la pubblicazione di PGP cosi' come e' stata fatta non viola le leggi sui brevetti.

PKP non si e' limitata ad acquisire i diritti esclusivi di brevetto per il sistema di crittografia RSA, ma ha anche acquisito quelli relativi a tre altri schemi a chiave pubblica inventati da altri alla Stanford University, e finanziati sempre da fondi federali. Questa singola societa' pretende di avere negli Stati Uniti un diritto legale su quasi tutti i sistemi di crittografia a chiave pubblica praticamente applicabili. Sembra anche che affermino di avere diritti di brevetto sul concetto stesso di crittografia a chiave pubblica, senza tener conto di quali algoritmi originali ed intelligenti possano essere inventati indipendentemente da altri. Io trovo questo tipo di monopolio problematico, perche' penso che la crittografia a chiave pubblica sia destinata a diventare una tecnologia cruciale per la protezione della nostra riservatezza e delle nostre liberta' civili nella nostra societa' sempre piu' collegata. Come minimo questo attrezzo vitale viene messo a rischio se si permette al Governo di creare un singolo punto di pressione sotto la sua influenza.

A partire da PGP 2.5 (distribuito dal MIT, detentore del brevetto originale), la versione freeware utilizza le librerie di subroutines RSAREF per effettuare le elaborazioni RSA, dietro licenza RSAREF, che ne permette l'uso non commerciale negli USA. RSAREF e' un pacchetto di subroutines sviluppato da RSA Data Security, Inc, che implementa l'algoritmo RSA. Le soubroutines RSAREF sono utilizzate al posto delle subroutines originali di PGP per implementare le funzioni RSA all'interno del programma. Si veda la licenza RSAREF per i termini e le condizioni d'uso di questa applicazione.

PGP 2.5 e' stato rilasciato dal MIT per un breve periodo di prova nel maggio 1994, prima di rilasciare la versione 2.6. PGP 2.5 e' stato rilasciato sotto la licenza RSAREF del 16 marzo 1994, che e' una licenza a tempo indeterminato, per cui questa versione potrebbe essere usata negli USA per sempre. Sarebbe meglio pero' per il futuro legale e politico di PGP che gli utilizzatori negli Stati Uniti si aggiornassero alla versione 2.6 o successive per favorire la scomparsa di PGP 2.3a o di quelle precedenti. Inoltre, PGP 2.5 contiene degli errori corretti in PGP 2.6, e PGP 2.5 non sara' in grado di leggere il formato nuovo generato a partire dal 1 settembre 1994. (si veda la sezione "Compatibilita' con le versioni precedenti e future di PGP").

La versione 2.0 di PGP e' stata il risultato degli sforzi comuni compiuti da un gruppo internazionale di tecnici software, che hanno implementato molti miglioramenti al PGP originale sotto la mia guida di progetto. La versione e' stata rilasciata da Branko Lankester in Olanda e da Peter Gutmann in Nuova Zelanda, fuori portata delle leggi statunitensi sui brevetti. Sebbene sia stata rilasciata solo in Europa ed in Nuova Zelanda, si e' spontaneamente diffusa negli Stati Uniti senza nessun intervento mio o del gruppo di sviluppo.

La cifratura convenzionale a blocchi IDEA(tm) usata da PGP e' coperta da brevetto in Europa. Il brevetto e' detenuto dall'ETH e da una societa' svizzera chiamata Ascom-Tech AG. Il brevetto USA e' il numero 5,214,703, mentre quello Europeo si chiama EP 0 482 154 B1. IDEA(tm) e' marchio registrato da Ascom-Tech AG. Non e' richiesto il pagamento di nessuna licenza per l'uso non commerciale di IDEA. Gli utilizzatori commerciali possono ottenere i dettagli sulle licenze da Dieter Profos, Ascom-Tech AG, Teleservices Section, Postfach 151, 4502 Solothurn, Svizzera, Tel. +41 65 242885, Fax +41 65 235761.

Ascom-Tech ha reso disponibile il permesso relativo alla versione freeware di PGP, che quindi puo' usare IDEA per usi non commerciali ovunque. Negli Stati Uniti ed in Canada, tutti gli utilizzatori governativi e commerciali devono ottenere una versione con licenza da ViaCrypt, che possiede una licenza di Ascom-Tech per l'uso di IDEA.

Ascom-Tech ha recentemente cambiato la sua politica sull'uso di IDEA all'interno di PGP per scopi commerciali al di fuori degli Stati Uniti, e sembra che questa nuova linea politica sia ancora in evoluzione. Mi hanno detto che la loro posizione attuale e' la seguente: permetteranno agli utilizzatori commerciali di PGP al di fuori di USA e Canada di utilizzare IDEA all'interno di PGP senza pagarne i diritti, perche' attualmente non e' possibile ottenere una versione licenziata di PGP al di fuori di quelle nazioni. Se la situazione legale negli Stati Uniti cambiera', in modo che gli utilizzatori esteri possano acquistare una versione commerciale di PGP (da ViaCrypt, da me, o da una societa' estera che possieda una mia licenza), allora Ascom-Tech fara' valere i suoi diritti di brevetto sugli utilizzatori commerciali. Per ottenere notizie piu' aggiornate su questo, contattate direttamente la Ascom-Tech AG.

Le routines di compressione ZIP di PGP provengono da codici sorgenti freeware con il permesso dell'autore. Non sono al corrente di alcun brevetto sugli algoritmi di compressione usati in queste routines.

Ritorno all'Indice

PGP non e' shareware, ma freeware. Pubblicato come un servizio per la comunita'. Distribuire PGP gratis incoraggera' molte piu' persone ad usarlo, con un impatto sociale piu' grande. Sentitevi liberi di distribuire il pacchetto di rilascio di PGP completo e senza modifiche a quante piu' persone potete, ma siate attenti a non violare le leggi sul controllo delle esportazioni se vivete negli USA. Datelo a tutti i vostri amici. Se avete accesso a delle BBS, caricatevi il pacchetto eseguibile completo.

Potete anche distribuire il pacchetto di rilascio con i codici sorgenti. Il codice sorgente di PGP e' pubblicato per permettere il controllo da parte di chiunque per trovare debolezze nascoste o porte di servizio, e per aiutare le persone a trovare eventuali errori e riportarli. Ricompilatelo, e portatelo su nuove macchine. Fate esperimenti con il codice ed imparate da esso.

Io non pongo nessun limite alle modifiche che potreste fare al codice sorgente per adattarlo alle vostre esigenze. Comunque, non distribuite una versione modificata con il nome "PGP" senza prima aver ottenuto il mio permesso. Vi prego di rispettare questa restrizione. La reputazione di PGP per l'integrita' della crittografia dipende dallo stretto controllo di qualita' sugli algoritmi e sui protocolli. Oltre a questo, i "miglioramenti" di PGP possono influenzare l'interoperabilita', creando confusione per gli utilizzatori e problemi di compatibilita' che potrebbero danneggiarne la reputazione (oltre a danneggiare la mia), e minare l'affidabilita' guadagnata dal marchio registrato PGP.

Questo e' gia' successo, ed e' il motivo per cui lo sottolineo qui. E' una cosa che crea mal di testa per l'assistenza tecnica, e ricevo telefonate da utenti confusi che hanno dei problemi o perche' possiedono loro stessi una versione mutante di PGP, o perche' stanno cercando di lavorare con una chiave, una firma o un messaggio prodotti da una versione mutante ed incompatibile. Il codice sorgente non e' stato reso pubblico per aiutare a generare questi mutanti.

Se volete distribuire una versione modificata di PGP, od usare una versione modificata per inviare messaggi, dovreste rinominare il programma in modo che nessuno possa scambiarlo per PGP. I messaggi, le firme e le chiavi prodotti da questa versione dovrebbero essere etichettati in modo che nessuno possa scambiarli per materiale prodotto da PGP. Se sentite di dover modificare la vostra copia di PGP, e ci sono possibilita' che questa copia possa venir distribuita, per favore contattatemi prima. Potremo discutere di alcuni semplici metodi per evitare che la gente scambi la vostra versione per il PGP originale. Potremmo anche decidere che le vostre modifiche sono adatte ad essere incorporate nella versione standard rilasciata.

Dovreste anche notare che la versione eseguibile ufficiale di PGP e' sempre rilasciata con le firme degli sviluppatori, in modo che possiate controllare l'integrita' del pacchetto. Se trovate una copia corrotta di PGP, o avete notizia della sua distribuzione, per favore contattate chi la sta distribuendo e suggeritegli di sostituirla con una versione autentica.

Alcune versioni vecchie di PGP sono state pubblicate secondo i termini della General Public License (GPL), una licenza pensata dalla Free Software Foundation per proteggere lo stato di freeware. Le versioni freeware piu' nuove di PGP non sono piu' pubblicate sotto GPL. I termini della licenza RSAREF sono piu' restrittivi di quelli della GPL. Pero', anche se una versione di PGP e' pubblicata senza RSAREF, in una situazione od in un posto dove il brevetto RSA non e' applicabile, non voglio che la GPL sia applicata a PGP, per una quantita' di motivi, non ultimo il fatto che la GPL non e' ottimale per proteggere PGP dall'essere ripubblicato con dei "miglioramenti" ad-hoc.

Fuori dagli Stati Uniti, il brevetto RSA non e' valido, sicche' gli utilizzatori di PGP sono liberi di usarne implementazioni non basate su RSAREF e sulle sue restrizioni. I Canadesi possono usare PGP senza usare RSAREF, ed esistono modi legali per esportare PGP in Canada. In Canada, dove RSAREF non e' necessario, e' facile modificare e ricompilare il codice di PGP in modo che esegua i calcoli RSA senza usare la libreria RSAREF, come e' stato fatto per PGP 2.3a. In casi del genere, questo PGP modificato puo' essere ri-rilasciato sotto gli stessi termini di licenza della versione ufficiale freeware corrispondente, ma senza le restrizioni specifiche RSAREF. Non puo' essere rilasciato sotto GPL, come alcune versioni piu' vecchie. Inoltre questo manuale deve comunque essere allegato. La versione modificata di PGP non puo' essere usata in ambienti dove RSAREF e' richiesto.

Ritorno all'Indice

La versione freeware di PGP e' per l'uso personale, non commerciale. Per un uso commerciale in USA o Canada, contattate ViaCrypt a Phoenix, Arizona (Tel. +1 602 944-0773, email [email protected]).

Ho raggiunto un accordo con ViaCrypt nell'estate 1993 per licenziare in esclusiva i diritti commerciali su PGP, sicche' c'e' per le societa' un modo di utilizzare PGP senza rischi di persecuzioni legali da parte di PKP per aver infranto i diritti di brevetto. Perche' PGP possa a lungo termine diventare uno standard industriale, questo marchio d'infamia legale associato ai diritti di brevetto RSA deve essere risolto. ViaCrypt ha gia' ottenuto una licenza da PKP per produrre, usare e vendere prodotti che utilizzino RSA. ViaCrypt offre una via di uscita dal pantano dei brevetti perche' PGP possa penetrare nell'ambiente delle societa'. Essi possono vendere una versione pienamente licenziata di PGP, ma solo se io do loro la mia licenza in questi termini. Quindi abbiamo raggiunto un accordo, aprendo la porta al futuro di PGP nel settore commerciale, cosa necessaria per il suo futuro politico a lungo termine.

Quindi, senza tener conto delle restrizioni complesse e parzialmente sovrapposte generate da tutti i termini e condizioni imposti dai vari brevetti e diritti di copia (RSA, RSAREF e IDEA), una restrizione addizionale sull'uso di PGP che sovrasta tutte le altre e' imposta dal mio accordo con ViaCrypt: la versione freeware di PGP e' solo per uso personale, non commerciale-- tutti gli altri utilizzatori in USA e Canada devono ottenerne una copia licenziata da ViaCrypt. Le restrizioni imposte dal mio accordo con ViaCrypt non sono applicabili al di fuori di USA e Canada.

Infine, se volete trasformare PGP in un prodotto commerciale e guadagnare denaro vendendolo, in questo caso dobbiamo accordarci su un modo in cui parte del guadagno venga a me. Se usate PGP in un modo per cui dobbiate pagare dei diritti sui brevetti o ogni altro tipo di licenza sul software ai detentori dei brevetti stessi, allora dobbiamo trovare un modo per cui sia pagato anch'io. Acquistare PGP da ViaCrypt e' un modo che soddisfa questo requisito.

Ritorno all'Indice

PGP non puo', in nessuna circostanza, essere distribuito senza documentazione, compreso questo manuale d'uso. Inoltre, assumendo che questa sia la versione RSAREF di PGP, l'accordo di licenza deve essere tenuto allegato. Dovete anche conservare le informazioni sui diritti di copia, i brevetti ed i marchi registrati di PGP e della sua documentazione.

Il rilascio standard freeware di PGP e' principalmente distribuito in forma elettronica, come un singolo file di archivio compresso contenente una collezione di files in un pacchetto a sua volta compresso. Questo pacchetto non dovrebbe essere aperto per distribuirne i componenti in modo separato-- Nell'interesse del controllo di qualita' vogliamo rendere difficile per gli utenti ottenere PGP senza prendere il pacchetto completo di rilascio.

Ritorno all'Indice

Negli Stati Uniti, PGP e' disponibile gratuitamente presso il Massachusetts Institute of Technology, con le restrizioni gia' descritte.

Il sito primario di rilascio di PGP e' il MIT, presso il suo sito FTP "net-dist.mit.edu", nella directory /pub/PGP. Potete ottenere da questo sito o da tutti i siti o le BBS in cui PGP si e' diffuso, copie gratuite di PGP o aggiornamenti. Non chiedetemi di inviarvene una copia, specialmente se vivete fuori dagli USA e dal Canada. Vi raccomando di non usare nessuna copia che non provenga dal MIT, da ViaCrypt o da me, a meno che non sia accompagnata da una mia autorizzazione firmata. Potete trovare il software rilasciato ufficiale presso molti altri siti di distribuzione "a valle" del MIT.(N.d.T. - ad esempio presso idea.sec.dsi.unimi.it nella dyrectory /.1/security/crypt/PGP). E' sperabile che anche questi siti rispettino i controlli degli Stati Uniti sulle esportazioni.

Il pacchetto di rilascio dell'eseguibile 2.6.2 per MSDOS contiene il programma eseguibile, la documentazione, la licenza RSAREF, un portachiavi di esempio contenente la mia chiave pubblica, e le firme del software e di questo manuale, tutto in un unico file compresso PKZIP chiamato pgp262.zip. Il pacchetto di rilascio dei sorgenti contiene tutti i files sorgenti in C in un file compresso PKZIP chiamato pgp262s.zip. I nomi dei files sono ricavati dal numero della versione.

Ritorno all'Indice

Il Governo degli Stati Uniti ha reso illegale nella maggior parte dei casi l'esportazione di tecnologia crittografica, e questo puo' includere PGP. Considerano questo tipo di software esattamente come considerano le munizioni. Questo non e' determinato dalla legislazione, ma dalle politiche amministrative del Dipartimento di Stato, del Dipartimento della Difesa e del Dipartimento del Commercio.

Il Governo sta usando le restrizioni sulle esportazioni come un mezzo per sopprimere la disponibilita' di tecnologie crittografiche sia all'interno del Paese, sia all'estero. In particolare, sta cercando di sopprimere l'emergenza di uno standard internazionale per i protocolli di crittografia, finche' non potranno imporre come standard dominante l'Escrowed Encryption Standard (il chip Clipper).

Tutte le restrizioni sull'esportazione di PGP sono imposte dal Governo degli Stati Uniti. Questo non implica che il MIT o io siamo d'accordo con queste restrizioni. Semplicemente ci adeguiamo. Non imponiamo ulteriori restrizioni di licenza sull'uso di PGP fuori dagli Stati Uniti oltre a quelle gia' esistenti all'interno. PGP puo' essere soggetto a controlli sulle esportazioni. Chiunque desideri esportarlo dovrebbe prima consultare l'ufficio di controllo sul commercio della difesa del Dipartimento di Stato.

Io non esportero' questo software fuori dagli Stati Uniti o dal Canada se e' illegale fare questo sotto il controllo degli USA, e raccomando alle altre persone di non farlo. Se vivete fuori dagli USA e dal Canada, vi raccomando di non violare le leggi degli USA sulle esportazioni prendendo una versione di PGP in un modo non legale. Siccome migliaia di utilizzatori all'interno del Paese si sono procurati PGP dopo la sua pubblicazione, in qualche modo il software e' uscito dagli USA e si e' sparso largamente all'estero, come i semi di dente di leone portati dal vento.

A partire dalla versione 2.0 e poi fino alla 2.3a, il punto di rilascio del software e' stato al di fuori degli USA, su computers pubblicamente accessibili in Europa. Ogni rilascio e' stato inviato negli USA e posto su computers accessibili pubblicamente da attivisti della riservatezza PGP di Paesi stranieri. Negli USA esistono delle restrizioni sull'importazione di munizioni, ma non mi risulta nessun caso in cui siano state applicate all'importazione di software crittografico. Immagino che un'azione legale di questo tipo creerebbe un bello spettacolo di polemica.

Il PGP ViaCrypt e' venduto in USA e Canada e non e' per l'esportazione. La frase seguente e' stata fornita dal Governo USA perche' fosse inclusa nella documentazione di ViaCrypt: "L'esportazione di PGP e' limitata dall'Ufficio dell'Amministrazione delle Esportazioni del Dipartimento del Commercio e dall'Ufficio di Controllo del Commercio della Difesa e delle Munizioni del Dipartimento di Stato. PGP non puo' essere esportato o riesportato direttamente o indirettamente, (a) senza tutte le licenze di esportazione o riesportazione e le approvazioni del Governo richieste da ogni legge applcabile, o (b) in violazione di qualunque proibizione contro l'esportazione di qualsiasi parte di PGP." Il Governo potrebbe assumere le stesse posizioni nei confronti delle versioni freeware di PGP.

Le versioni freeware 2.5 e 2.6 di PGP sono state rilasciate caricandole su di un sito FTP controllato gestito dal MIT. Questo sito ha delle restrizioni e limitazioni che sono state gia' usate da altri FTP per adeguarli ai requisiti per il controllo delle esportazioni di altri software di crittografia come Kerberos e altri provenienti da RSA Data Security, Inc. Vi raccomando di non fare niente che possa indebolire questi controlli o facilitare l'esportazione impropria di PGP.

Sebbene PGP sia diventato di fatto uno standard mondiale per la cifratura dell'e-mail, e sia largamente disponibile all'estero, continuo a ricevere telefonate da persone residenti fuori dagli USA che mi chiedono se sia legale usarlo nei loro Paesi, nelle versioni gia' disponibili. Per favore non contattatemi per chiedermi se sia legale usare PGP nel vostro Paese, se vivete fuori dagli USA. La domanda non riguarda me. Ho gia' abbastanza problemi giudiziari per questioni di controllo sulle esportazioni, senza essere coinvolto dandovi consigli legali attraverso il mio telefono. Potrebbe persino farmi correre dei rischi con la legge il semplice fatto di rispondere ad una domanda del genere posta da uno straniero. Se questa questione vi preoccupa, chiedete a qualcun altro, per esempio ad un avvocato.

Potreste dover usare PGP per applicazioni commerciali al di fuori di USA e Canada. Sfortunatamente, al momento della stesura di questo documento, non c'e' nessun modo di ottenere una versione commerciale al di fuori di questi Paesi. Sto cercando un modo legale per rendere disponibile anche all'estero una versione licenziata, ma fino ad ora le restrizioni USA sulle esportazioni lo rendono difficile senza espormi a rischi legali. Questa situazione potrebbe cambiare.

Alcuni governi stranieri impongono pesanti punizioni a chiunque all'interno del loro Paese usi delle comunicazioni cifrate. In alcuni Paesi potrebbero perfino uccidervi per questo. Se pero' vivete in Paesi cosi', forse PGP vi serve ancora di piu'.

Ritorno all'Indice

Al momento della scrittura di questo documento, sono oggetto di indagine criminale da parte della Dogana USA nel Distretto Settentrionale della California. Un'indagine criminale non e' una prosecuzione civile. La prosecuzione civile non comporta pene carcerarie. Il mio avvocato difensore ha saputo dall'avvocato d'ufficio che l'area legale di cui si interessa l'indagine riguarda i controlli sulle esportazioni del software crittografico. Le indicazioni federali sulle sentenze obbligatorie per questo reato raccomandano un periodo da 41 a 51 mesi in una prigione federale. Sembra che la Dogana USA abbia deciso di assumere la posizione per cui la pubblicazione elettronica di software crittografico all'interno del Paese sia equivalente alla sua esportazione. La pubblica accusa ha presentato molte citazioni di grand jury federali. Possono passare mesi prima che venga raggiunta una decisione sulla mia incriminazione. Questa situazione puo' cambiare in ogni momento, sicche' questa descrizione potra' essere sorpassata quando la leggerete. Leggete i giornali per conoscere gli sviluppi. Se saro' incriminato e si arrivera' ad un processo, sara' un caso destinato a creare dei precedenti importanti.

Per questo caso, e' stato creato un fondo per la mia difesa legale. Fino ad ora, non ci sono altre organizzazioni che raccolgano fondi per me, quindi dipendo da persone come voi, che contribuiscono direttamente a questa causa. Se voi vi preoccupate per il futuro delle vostre liberta' civili nella societa' dell'informazione, forse potete anche preoccuparvi di questo caso. Le tariffe legali sono elevate, il tassametro gira ed io ho bisogno del vostro aiuto. Il fondo e' gestito dal mio avvocato difensore, Phil Dubois, a Boulder. Se volete, inviate i vostri contributi a:

Philip L. Dubois, Lawyer
2305 Broadway
Boulder, Colorado 80304 USA
Phone (303) 444-3885
E-mail: [email protected]

(Esiste un punto di raccolta in Europa per evitare le spese del trasferimento di fondi negli USA. Contattare Phil Dubois per i dettagli. N.d.T.).

Potete anche effettuare la vostra donazione per telefono caricandola sulla vostra Visa o Mastercard. Se volete essere veramente impudenti, potete mandare il vostro contributo via e-mail, cifrando il messaggio con PGP perche' nessuno possa intercettare il vostro numero di carta di credito. Nell'e-mail includete il numero di carta, la data di scadenza, l'intestatario della carta e l'ammontare della donazione. Firmate quindi il messaggio con la vostra chiave e cifratelo con la chiave pubblica di Phil Dubois (questa chiave e' inclusa nel pacchetto di distribuzione standard di PGP, nel file "key.asc"). Scrivete nella linea del soggetto che il messaggio contiene una donazione per il mio fondo di difesa legale, in modo che il Sig. Dubois lo decifri subito. Per favore, non inviategli un mucchio di posta varia cifrata-- Preferirei che usasse il suo prezioso tempo a lavorare sul mio caso.

Se volete leggere alcune storie riportate dalla stampa, per capire perche' questo caso e' importante, ecco dei riferimenti:

  1. William Bulkeley, "Cipher Probe", Wall Street Journal, giovedi' 28 aprile 1994, prima pagina.
  2. John Cary, "Spy vs. Computer Nerd: The Fight Over Data Security", Business Week, 4 ottobre 1993, pagina 43.
  3. Jon Erickson, "Cryptography Fires Up the Feds", Dr. Dobb's Journal, dicembre 1993, pagina 6.
  4. John Markoff, "Federal Inquiry on Software Examines Privacy Programs", New York Times, martedi' 21
  5. settembre 1993, pagina C1.
  6. Kurt Kleiner, "Punks and Privacy", Mother Jones Magazine, gennaio/febbraio 1994, pagina 17.
  7. Steven Levy, "Battle of the Clipper Chip", New York Times Magazine, domenica 12 giugno 1994, pagina 44.
  8. Steven Levy, "Crypto Rebels", WIRED, maggio/giugno 1993, pagina 54.
  9. John Markoff, "Cyberspace Under Lock and Key", New York Times,domenica 13 febbraio 1994.
  10. Philip Elmer-DeWitt, "Who Should Keep the Keys", Time, 14 Marzo 1994, pagina 90.
Ci sono molti altri articoli su PGP pubblicati in tutto il mondo.
Terro' un album di ritagli.

Ritorno all'Indice

Altre fonti di informazioni su PGP

Ritorno all'Indice

Per avere una versione con licenza per l'uso di PGP in USA e Canada, contattare:

ViaCrypt
9033 North 24th Avenue, Suite 7
Phoenix, Arizona 85021 USA
Tel.: +1 602 944-0773, o +1 800 536-2664
Fax: +1 602 943-2601
E-mail: [email protected]

Via Crypt puo' fornire una versione di PGP per MSDOS, e diverse piattaforme Unix, oltre ad uno shell per Windows. Altre versioni sono in corso di sviluppo, compresa una versione per Macintosh. Se avete la necessita' di utilizzare PGP in un ambiente commerciale o governativo e ViaCrypt ha la versione per la vostra piattaforma, dovreste usare questa.

ViaCrypt ha ottenuto tutte le licenze necessarie da PKP, AscomTech AG e Philip Zimmermann per vendere PGP per l'uso in ambienti commerciali e governativi. Il PGP ViaCrypt e' sicuro come la versione freeware, ed e' interamente compatibile. Il PGP ViaCrypt e' il modo perfetto per portare nel vostro ambiente aziendale una versione provvista di licenza di PGP.

Se lavorate in una grande azienda e siete un sostenitore di PGP, vi raccomando di cercare di convincere la vostra societa' ad acquistare molte copie di PGP da ViaCrypt. Non solo perche' questo mi farebbe guadagnare le royalties. Se ViaCrypt potra' fare di PGP un successo commerciale, sara' un buon passo per cementarne il futuro politico come uno standard ormai non arrestabile per la cifratura nel mondo delle aziende. Il mondo delle aziende va dove e' il denaro, e non c'e' niente altro che influenzi di piu' la politica pubblica. Questo comprende la politica del Governo per la soppressione della crittografia forte.

Ritorno all'Indice

Eventuali errori di PGP dovrebbero essere riportati via e-mail al MIT, il sito di distribuzione ufficiale. L'indirizzo per riferire errori e': [email protected]. Il MIT mi fara' avere copia della vostra segnalazione. Quando riportate degli errori, assicuratevi di specificare la macchina ed il sistema operativo che usate e la versione di PGP che possedete, oltre a dettagli sufficienti a riprodurre il problema. Sarebbe anche una buona idea informarvi prima per sapere se la vostra versione di PGP e' l'ultima, perche' e' possibile che l'errore sia gia' stato corretto. Sarebbe meglio anche accertarsi di aver effettivamente trovato un errore prima di riferirlo. RTFM.

Ritorno all'Indice

Dopo tutto questo lavoro devo ammettere che non mi dispiacerebbe ricevere un po' di posta dai sostenitori di PGP, per misurarne la popolarita'. Fatemi sapere cosa ne pensate, e quanti vostri amici ne fanno uso. Mi fa piacere anche ricevere segnalazioni di errori e suggerimenti per futuri miglioramenti. E' possibile che una prossima versione di PGP rifletta i vostri suggerimenti.

Questo progetto non e' stato finanziato, e mi ha quasi mangiato vivo. Questo significa che normalmente non rispondero' alla vostra posta, a meno che vi serva solo una risposta breve ed includiate una busta indirizzata e affrancata. Pero' rispondo spesso all'e-mail. Per favore scrivete in Inglese, siccome le mie capacita' con le lingue straniere sono deboli. Se mi telefonate e non mi trovate, la cosa migliore e' riprovare piu' tardi. Normalmente non restituisco le chiamate provenienti da lontano, a meno che non lasciate un messaggio in cui mi autorizziate a chiamarvi a vostro carico, ed anche in questo caso non e' detto che vi richiami. Se vi serve una quantita' significativa del mio tempo, sono disponibile a fornire consulenze pagate, e rispondo sempre a queste chiamate.

La posta piu' scomoda che ricevo, proviene da alcune persone benintenzionate che mi mandano un po' di dollari chiedendomi una copia di PGP. Io non gliela mando, perche' preferisco evitare qualunque problema legale con PKP. Peggio ancora, a volte queste richieste arrivano dall'estero, e rischierei di violare le leggi USA sull'esportazione di software crittografico. Comunque, anche quando non ci sono complicazioni legali normalmente non mi mandano una somma sufficiente a coprire l'uso del mio tempo. Semplicemente io non sono organizzato per gestire un'attivita' di vendita per corrispondenza di quantita' limitate di merci a basso costo. Inoltre non posso ignorare la richiesta e tenermi il denaro, perche' il mittente probabilmente lo considera come un pagamento perche' io soddisfi le sue richieste. Se restituisco il denaro, devo prendere la mia auto, guidare fino all'ufficio postale e comprare dei francobolli, perche' raramente mi allegano una busta indirizzata ed affrancata. Inoltre devo impiegare tempo per scrivere una cortese risposta spiegando che non posso fare cio' che mi si chiede. Se rimando queste operazioni ed appoggio la lettera sulla mia scrivania, in pochi minuti puo' essere sepolta, e non vedra' di nuovo la luce del giorno per mesi. Moltiplicate questi piccoli inconvenienti per il numero di richieste che ricevo, e capirete il problema. Non basta che il software sia gratuito ? Sarebbe piu' bello se le persone potessero cercare di prenderne una copia dalle miriadi di fonti disponibili. Se non avete un modem, chiedete ad un amico di prendere una copia di PGP per voi. Se non riuscite comunque a trovarlo, non mi dispiacera' rispondere ad una breve chiamata telefonica.

Chiunque abbia la volonta' di migliorare PGP, me lo faccia sapere. Un po' di lavoro in piu' sara' certamente utile. L'inserimento di alcune funzioni e' stato rimandato in attesa del tempo necessario. Molti utilizzatori di PGP hanno gia' offerto il loro tempo per portare il software su Unix sulle Sun SPARCstations, su Ultrix, su VAX/VMS, su OS/2, su Amiga e sull'Atari ST. Forse voi potete dare il vostro contributo per portarlo su altri ambienti. Solo, per favore parlatemi dei vostri progetti per portare PGP su altri ambienti o per migliorarlo prima di iniziare il lavoro, per evitare di duplicare gli sforzi e di partire magari con una versione obsoleta del codice sorgente.

Siccome sono state prodotte molte traduzioni in lingua straniera di PGP, la maggior parte di esse non e' distribuita col pacchetto standard, perche' questo richiederebbe troppo spazio sui dischi. Dei "kits" separati di traduzione sono disponibili presso numerose fonti indipendenti, e talvolta sono disponibili presso gli stessi centri di distribuzione dove avete trovato il pacchetto standard. Questi kits comprendono le versioni tradotte dei files LANGUAGE.TXT, PGP.HLP e dei manuali d'uso. Se volete scrivere una traduzione nella vostra lingua, prima contattatemi per avere le ultime informazioni ed alcune direttive standard, ed anche per verificare che il lavoro non sia gia' stato fatto. Per sapere dove trovare un kit per la vostra lingua, potete controllare i newsgroups di Internet, oppure chiedere a Mike Johnson ([email protected]).

Se avete accesso ad Internet, cercate gli annunci di rilascio di una nuova versione di PGP sul newsgroup "sci.crypt" e sul newsgroup di PGP, "alt.security.pgp". Se volete sapere dove prendere PGP, il MIT e' il sito primario di distribuzione (net-dist.mit.edu). Potete chiedere a Mike Johnson ([email protected]) una lista di siti FTP su internet e di numeri telefonici di BBS.

Ritorno all'Indice

PGP e' un software fortemente politico. Sembra dunque appropriato menzionare qui alcuni gruppi di attivisti collegati al mondo del computer. Tutti i dettagli su questi gruppi, ed il modo di aderirvi, sono forniti in un file separato del pacchetto di rilascio di PGP.

L'Electronic Privacy Information Center (EPIC) e' un centro ricerche di pubblico interesse di Washington, DC. E' stato fondato nel 1994 per focalizzare la pubblica attenzione sulle questioni emergenti relative alla National Information Infrastructure, come il chip Clipper, il progetto di legge sulla telefonia digitale, la riservetezza degli archivi medici e la vendita di dati sui consumatori. EPIC e' sponsorizzato dal Fund for Constitutional Government e da Computer Professionals for Social Responsibility. EPIC pubblica l'EPIC Alert e gli EPIC Reports, segue la vertenza sul Freedom of Information Act, e conduce ricerche politiche sulle questioni di riservatezza emergenti. Per maggiori informazioni:
EPIC, 666 Pennsylvania Ave., SE, Suite 301, Washington, DC 20003.
Tel.:+1 202 544 9240
Fax:+1 202 547 5482
e-mail [email protected]

La Electronic Frontier Foundation (EFF) e' nata nel 1994 per assicurare la liberta' di espressione attraverso i mezzi digitali, con particolare enfasi per cio' che riguarda l'applicazione dei principi contenuti nella Costituzione degli Stati Uniti e nella Carta dei Diritti alle comunicazioni basate sui computer. Puo' essere raggiunta a Washington DC, tel. +1 202 347-5400.
Internet e-mail: [email protected].

Computer Professionals For Social Responsibility (CPSR) da' la possibilita' ai professionisti ed agli utilizzatori di computer di sostenere l'uso responsabile delle tecnologie dell'informazione, e permette a tutti coloro che usano la tecnologia dei computers di partecipare a dibattiti politici pubblici sugli impatti dei computers stessi sulla societa'. Possono essere raggiunti a Palo Alto, tel.: +1 415 322-3778.
e-mail: [email protected].

La League for Programming Freedom (LPF) e' un'organizzazione di base di insegnanti, studenti, uomini di affari, programmatori ed utilizzatori dedicata a ripristinare la liberta' nella scrittura dei programmi. Essi considerano i brevetti sugli algoritmi dei computers dannosi per l'industria del software Statunitense (e' esattamente cio' che penso io !). Possono essere raggiunti al numero +1 617 433-7071.
e-mail: [email protected].

Per maggiori dettagli su questi gruppi, si veda il documento allegato al pacchetto di rilascio di PGP.

Ritorno all'Indice

Letture introduttive

  1. Bruce Schneier, "Applied Cryptography: Protocols, Algorithms, and Source Code in C", John Wiley & Sons, 1993 (Questo libro e' uno spartiacque sull'argomento.)
  2. Dorothy Denning, "Cryptography and Data Security", Addison-Wesley, Reading, MA 1982
  3. Dorothy Denning, "Protecting Public Keys and Signature Keys", IEEE Computer, febbraio 1983
  4. Martin E. Hellman, "The Mathematics of Public-Key Cryptography," Scientific American, agosto 1979
  5. Steven Levy, "Crypto Rebels", WIRED, maggio/giugno 1993, pagina 54. (Un articolo fondamentale su PGP ed altre questioni collegate.)
  6. Steven Levy, "Battle of the Clipper Chip", New York Times Magazine, domenica 12 giugno 1994, pagina 44. (Grande articolo e grandi foto.)
  7. William Bulkeley, "Cipher Probe", Wall Street Journal, 28 aprile 1994, prima pagina. (Un articolo su PGP e Zimmermann.)
Altre letture

  1. Ronald Rivest, "The MD5 Message Digest Algorithm", MIT Laboratory for Computer Science, 1991
  2. Xuejia Lai, "On the Design and Security of Block Ciphers", ETH Series on Information Processing (Ed. J. L. Massey), Vol. 1, Hartung-Gorre Verlag, Costanza, Svizzera, 1992
  3. Philip Zimmermann, "A Proposed Standard Format for RSA Cryptosystems", Advances in Computer Security, Vol III, Pubblicato da Rein Turn, Artech House, 1988
  4. Paul Wallich, "Electronic Envelopes", Scientific American, febbraio 1993, pagina 30. (Un articolo su PGP)
  5. William Stallings, "Pretty Good Privacy", BYTE, luglio 1994, pagina 193
  6. Philip Zimmermann, "The Official PGP User's Guide", MIT Press, 1994 (in corso di stampa)
  7. Philip Zimmermann, "PGP Source Code and Internals", MIT Press, 1994 (in corso di stampa)
Ritorno all'Indice

Philip Zimmermann Puo' essere raggiunto a:

Boulder Software Engineering
3021 Eleventh Street
Boulder, Colorado 80304 USA
Internet: [email protected]
Tel.: +1 303 541-0140 (voce) (10:00am - 7:00pm Mountain Time)
E' disponibile un fax, accordandosi prima per telefono.

Ritorno all'Indice

Appendice A: Dove procurarsi PGP

Questa appendice descrive come procurarsi il programma freeware di crittografia a chiave pubblica PGP (Pretty Good Privacy) da un sito FTP anonimo su Internet, o da altre fonti.

Di fatto PGP e' diventato uno standard mondiale per la cifratura di e-mail. PGP ha una gestione sofisticata delle chiavi, uno schema di cifratura ibrido RSA/convenzionale, la generazione di una selezione del messaggio per la firma digitale ed un buon progetto ergonomico. PGP e' funzionale e veloce, ed ha un'eccellente documentazione d'uso. Il codice sorgente e' liberamente disponibile.

Il Massachusetts Institute of Technology e' il distributore di PGP 2.6. La distribuzione e' limitata agli Stati Uniti. PGP e' disponibile presso "net-dist.mit.edu", un sito FTP controllato con restrizioni e limitazioni simili a quelle gia' usate da RSA Data Security, Inc., per rispettare i requisiti del controllo sulle esportazioni. Il software risiede nella directory /pub/PGP.

Un richiamo: impostate il modo come binario o immagini prima di effettuare il trasferimento FTP. Se effettuate un trasferimento kermit verso il vostro PC, specificate il modo binaro ad 8 bits su entrambi i terminali.

Ci sono due files di archivio compressi nel rilascio standard. Il nome dei files deriva dalla versione del rilascio. Per avere PGP 2.6.2, dovete prendere il file pgp262.zip che contiene l'eseguibile MSDOS e i manuali d'uso. Opzionalmente potete anche prendere il file pgp262s.zip che contiene tutto il codice sorgente. Questi files possono essere decompressi con il programma di decompressione shareware per MSDOS PKUNZIP.EXE, versione 1.10 o successive. Per gli utilizzatori Unix che non dispongono della funzione UNZIP, il codice sorgente puo' anche essere trovato nel file compresso tar pgp262s.tar.Z.

Se non avete nessun numero telefonico di BBS comodo, ecco una BBS che potreste provare. La Catacombs BBS, gestita da Mike Johnson a Longmont, Colorado, distribuisce il PGP solo in USA e Canada. Il numero di telefono (modem) e' +1 303-772-1062. Il numero di telefono di Mike Johnson e' +1 303-772-1773, e l'indirizzo e-mail e' [email protected]. Mike distribuisce PGP solo in USA e Canada anche tramite un sito FTP di Internet. Il nome del sito e' csn.org, la directory e' /mpj/ e dovete leggere il file README.MPJ per prendere PGP.

Per ottenere una versione con licenza di PGP per l'uso in USA e Canada, contattate ViaCrypt a Phoenix, Arizona. Il telefono e' +1 602-944-0773. ViaCrypt ha ottenuto tutte le licenze necessarie da PKP, AscomTech AG e Philip Zimmermann per vendere PGP per l'uso in ambienti commerciali e governativi. Il PGP ViaCrypt e' sicuro come la versione freeware, ed e' interamente compatibile. Il PGP ViaCrypt e' il modo perfetto per portare nel vostro ambiente aziendale una versione provvista di licenza di PGP.

Di seguito trovate un elenco di alcune persone di diversi Paesi e dei loro indirizzi e-mail o numeri di telefono. Potete contattare queste persone per chiedere informazioni sulla disponibilita' locale delle versioni di PGP precedenti la 2.5:

Peter Gutmann?Hugh Kennedy
[email protected]?[email protected]
Nuova Zelanda?Germania
?
Branko Lankester?Miguel Angel Gallardo
[email protected]?[email protected]
+31 2159 42242?+341 474 38 09
Olanda?Spagna
?
Hugh Miller?Colin Plumb
[email protected]?[email protected]
+1 312 508-2727?Toronto, Ontario, Canada
USA?
?
Jean-loup Gailly?
[email protected]?
Francia?

Ritorno all'Indice

Questo documento e' stato portato in formato HTML da Marco Giaiotto <[email protected]>

Ultima revisione: 7 gennaio 1996






Ai sensi della legge n.62 del 7 marzo 2001 il presente sito non costituisce testata giornalistica.
Eleaml viene aggiornato secondo la disponibilità del materiale e del web@master.