Ritorno all'Indice
pgp -kv 0x67F7
Verranno mostrate tutte le chiavi che contengono 67F7 nell'id di chiave.
Questa funzione è 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
pgp -sb lettera.txt
Questo esempio genera un certificato di firma chiamato "lettera.sig". Il contenuto di "lettera.txt" non è 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'integrità 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 potrà controllare l'integrità della firma. Se il destinatario sa già che firma e testo sono separati, può specificarne il nome nella linea di comando:
pgp lettera.sig lettera.txt
o: pgp lettera lettera.txt
In questo caso PGP non avrà bisogno di richiedere il nome del file di testo.
Un certificato di firma separato è utile se volete tenere un archivio separato di questi certificati. Il certificato di firma di un programma eseguibile può servire per rilevare una successiva infezione da virus. È anche utile se un documento deve essere firmato da più persone senza subordinare le firme. Ogni firma è 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
Qualche volta però, potreste voler decifrare un file lasciandovi attaccata la firma in esso contenuta, ottenendo un file decifrato firmato. Questo può 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 è 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
Il testo ASCII a volte è rappresentato in modo diverso su macchine diverse. Per esempio sui sistemi MSDOS ogni linea ASCII è 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. È 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 è facile trasmettere file di testo fra sistemi diversi.
Il testo cifrato non può però essere convertito automaticamente dal protocollo di comunicazione, perchè il testo in chiaro è 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.
Perchè 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, così:
pgp -et lettera.txt dest_ID
Questo modo di funzionamento è 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. È 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 può 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 è una serie di caratteri ASCII estesa, con caratteri supplementari aggiunti per molte lingue Europee.
Ritorno all'Indice
PGP può essere usato in modo da offrire le stesse funzioni generali di uuencode, più altre. Potete chiedere a PGP di limitarsi a convertire un file in formato ASCII radix-64, senza doverlo firmare o cifrare, sicchè non è 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 dividerà automaticamente in blocchi i file troppo lunghi per i
canali e-mail.
* PGP aggiungerà un codice CRC per il controllo degli errori alla
fine di ogni blocco.
* PGP cercherà di comprimere i dati prima di convertirli.
* La serie di caratteri radix-64 usata da PGP è più 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 può 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 è un uuencode migliore di uuencode.
Ritorno all'Indice
Per distruggere il file in chiaro dopo averne cifrato il contenuto, aggiungete l'opzione -w (wipe) quando cifrate o firmate un messaggio. Così:
pgp -esw lettera.txt dest_ID
Questo esempio produce il file cifrato "lettera.pgp", e cancella il file "lettera.txt" senza possibilità di recupero.
Naturalmente è necessario essere attenti nell'uso di questa opzione. Si noti anche che questa opzione non cancellerà gli eventuali frammenti di testo in chiaro che il vostro word processor può 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
pgp -m file cifrato
Questo mostra il testo decifrato sullo schermo, pagina per pagina.
Ritorno all'Indice
pgp -sem lettera.txt dest_ID
Quando il destinatario decifrerà il file con la propria chiave segreta, il testo in chiaro verrà presentato sullo schermo, ma non salvato su disco. Il testo verrà mostrato come se si stesse usando il comando "more" di Unix, una pagina per volta. Se il destinatario vorrà rileggere il messaggio dovrà decifrarlo di nuovo.
Questa funzione è la via più sicura per evitare che i vostri messaggi più 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 impedirà 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
Quando però 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 è utile quando PGP viene usato per files il cui nome è significativo.
Per ricuperare il nome originale del file in chiaro, aggiungere l'opzione -p, così:
pgp -p filecifrato
Normalmente io non uso questa opzione, perchè se lo facessi circa metà della posta che ricevo sarebbe decifrata verso lo stesso file in chiaro chiamato "a_phil.txt" o "prz.txt".
Ritorno all'Indice
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 perchè è 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. Può anche essere usato per modificare i parametri di affidabilità di una chiave pubblica.
Ritorno all'Indice
Per modificare i parametri di affidabilità di una chiave pubblica:
pgp -ke ID [portachiavi]
Il parametro opzionale [portachiavi], se specificato, deve essere un portachiavi pubblico, non segreto.
Ritorno all'Indice
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
pgp -kvc ID [portachiavi]
Questo mostrerà una selezione di 16 bytes dei componenti della chiave pubblica. Leggete questa impronta digitale di 16 bytes al proprietario, che farà lo stesso con la sua copia, usando lo stesso comando -kvc.
Potete verificare reciprocamente le rispettive chiavi in questo modo, e poi firmarle tranquillamente. È 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 è inviarne l'impronta digitale per e-mail, perchè può essere intercettata e modificata. È meglio usare un mezzo indipendente da quello che avete usato per inviare la chiave stessa. Una buona combinazione è 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 è ricavata usando la funzione di "mescolamento" MD5. Una futura versione di PGP permetterà 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 può manometterle tutte. Le differenze sarebbero presto notate da qualcuno che la controllasse usando più 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
Queste informazioni potrebbero ancora essere manomesse nell'edizione
elettronica di questo manuale. Se però state leggendo la versione
stampata, disponibile nelle librerie ed edita da MIT press, è sicuro
assumere che questa sia effettivamente l'impronta digitale della mia
chiave.
Ritorno all'Indice
Potreste però voler aggiungere un portachiavi "enorme" al vostro
portachiavi perchè siete interessati a poche dozzine di chiavi
fra quelle contenute. Se questo è tutto quello che volete, sarebbe
più 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 più
piccoli, o essere pazienti.
Ritorno all'Indice
Per usare un modo di filtro stile Unix, leggendo dallo standard input
e scrivendo nello standard output, aggiungere l'opzione -f, così:
pgp -feast dest_ID
Questa funzione rende più 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 è
spiegata più avanti.
Ritorno all'Indice
Abilitando il flag BATCHMODE nella linea di comando, PGP non
richiederà informazioni non necessarie o nomi di files alternativi.
Ecco un esempio di come abilitare questo flag:
pgp +batchmode filecifrato
È 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 è attivo, quindi
gli shell scripts potrebbero doverli evitare.
BATCHMODE può anche essere abilitato per controllare la validità di
una firma in un file. Se non ci sono firme, il codice di uscita è 1.
Se c'è una firma valida il codice di uscita è 0.
Ritorno all'Indice
pgp +force filecifrato
Questa funzione è utile per lanciare PGP in modo non interattivo da
uno shell script di Unix o da un file batch di MSDOS.
Ritorno all'Indice
Ritorno all'Indice
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 è stato
tradotto, perchè qualunque frase serve allo scopo. Inoltre, per chi
conosce il riferimento è proprio una bella frase. N.d.T.)
Questa pericolosa funzione vi rende la vita più comoda se dovete
lavorare regolarmente con un gran numero di messaggi indirizzati alla
vostra chiave segreta, eliminando la necessità di inserire
ripetutamente la vostra frase.
Ho aggiunto questa funzione dopo diffuse richieste. Comunque, si
consideri che la funzione è in qualche modo pericolosa, perchè
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 potrò 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 più 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 è però 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 già descritti per l'uso della
variabile PGPPASS.
Ritorno all'Indice
Il nome "config.txt" è 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, tenterà 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 è fornito assieme a PGP, in modo
che possiate vedere degli esempi.
Nel file di configurazione, le linee vuote sono ignorate, così 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:
Si noti che è 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
Di seguito è riportato un sommario dei vari parametri definibili nel
file di configurazione.
Ritorno all'Indice
Il parametro TMP specifica la directory da usare per i files
temporanei. Il posto migliore, se ne avete uno, è un RAM disk. La
velocità aumenta leggermente, ed in qualche modo anche la sicurezza.
Se TMP non è definito, i files temporanei saranno salvati nella
directory corrente. Se la variabile ambiente TMP è definita, PGP
userà comunque la directory specificata in questa variabile.
Ritorno all'Indice
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. È però 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.
Può 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:
PGP utilizzerà il Francese per i suoi messaggi. La lingua di default
è 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 è 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 è distribuita con il pacchetto standard di PGP, ma è disponibile
separatamente.
Ritorno all'Indice
Il parametro MYNAME specifica l'ID di default che PGP userà per
selezionare la frase segreta e generare le firme. Se MYNAME non è
definito, PGP userà la chiave che è stata inserita più di recente
nel vostro portachiavi segreto. L'utilizzatore può scavalcare questa
impostazione specificando un ID nella linea di comando con l'opzione
-u.
Ritorno all'Indice
Il parametro TEXTMODE è equivalente al comando -t. Se è 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 verrà posto automaticamente nello stato
"off" nel momento in cui ciò che sembra essere un insieme di dati
binari verrà 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
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 dovrà 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 è la rappresentazione interna usata da PGP per il testo
canonico, quindi non viene effettuata nessuna conversione se lo
selezionate. Si noti che anche KOI8 è trattato come LATIN1, sebbene
sia un carattere totalmente diverso (Russo), perchè il tentativo di
convertire KOI8 sia in LATIN1 che CP850 sarebbe comunque futile. Tutto
questo significa che impostare CHARSET a NOCONV, LATIN1 o KOI8 è
equivalente.
Se usate MSDOS e ritenete di dover inviare o ricevere messaggi scritti
usando delle lingue Europee occidentali, impostate CHARSET= "CP850".
PGP convertirà il testo canonico ricevuto da LATIN1 a CP850 dopo
averlo decifrato. Se usate l'opzione -t (textmode) per convertire in
testo canonico, PGP convertirà 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
Il Parametro ARMOR è 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
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 più 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 spezzerà 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
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 può farlo
automaticamente. Se doveste voler decifrare nuovamente il file, vi
basterà 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
Il parametro COMPRESS abilita o disabilita la compressione dei dati
prima della cifratura. È 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
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
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
Il parametro CERT_DEPTH specifica quanti livelli di presentazioni
secondarie PGP dovrà accettare per certificare altri presentatori. Per
esempio, se CERT_DEPTH vale 1, può esistere un solo livello di
presentatori al di sotto della vostra chiave completamente affidabile.
Se questo è 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 è 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
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, più alcune componenti segrete.
Questo significa che PGP può 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 è definito, PGP non effettuerà 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
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 è particolarmente pratica per evitarvi di specificare
un portachiavi alternativo nella linea di comando.
Ritorno all'Indice
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 è particolarmente pratico se volete tenere il portachiavi
segreto in una directory o su un apparato più 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
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. Può essere utile se volete tenere il file su
di un supporto più 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
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 dovrà 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 userà sempre la propria funzione
interna.
Per maggiori dettagli, si veda la sezione "Presentare il testo
decifrato sullo schermo".
Ritorno all'Indice
PGP non vi permette normalmente di vedere la vostra frase chiave mentre
la battete. Questo rende più 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. Così è 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 ciò
che battete quando inserite la vostra frase chiave.
Ritorno all'Indice
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 però, a causa di un sistema MSDOS configurato in modo
improprio, il tempo è restituito in US Pacific Standard Time più 8
ore. Sembra bizzarro, vero ? Forse succede perchè 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 è già 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 è definita correttamente,
potete lasciare TZFIX=0. I sistemi Unix normalmente non richiedono
nessuna impostazione di TZFIX. Se state però 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 è 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 più pulito definire la vostra variabile ambiente MSDOS
TZ all'interno del file "AUTOEXEC.BAT", piuttosto che usare la
correzione TZFIX. MSDOS vi fornirà delle etichette di tempo corrette,
e terrà conto dell'ora legale per voi. Ecco alcuni esempi di linee da
inserire in AUTOEXEC.BAT per le diverse zone:
Ritorno all'Indice
Normalmente, i messaggi firmati, ma non cifrati, da PGP hanno un
certificato di firma allegato in formato binario. Il messaggio inoltre
è compresso, per cui è 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 dovrà sempre usare PGP per togliere
l'armatura, o decomprimere il messaggio, o entrambi, prima di poter
leggere.
Se il messaggio originale è composto da solo testo (non binario) è
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 servirà a
verificare la firma.
Il valore di default di CLEARSIG è "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, così:
pgp -sta +clearsig=on lettera.txt
Questa rappresentazione del messaggio è analoga a quella usata dal
PEM (Internet Privacy Enhanced Mail) per i messaggi di tipo MIC-CLEAR.
È importante notare come siccome l'armatura ASCII è applicata solo
alla firma, e non al messaggio, ci siano dei rischi che quest'ultimo
possa subire delle manomissioni accidentali strada facendo. Può
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 darà esito negativo, dandovi una falsa
indicazione di una manomissione intenzionale. Siccome però il PEM ha
questa stessa vulnerabilità, 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
VERBOSE può 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 quantità
ragionevole di dettagli nei messaggi diagnostici o di avviso.
2 - Visualizza tutte le informazioni disponibili, normalmente per
diagnosticare dei problemi di PGP. Non è consigliabile per l'uso
normale. D'altra parte PGP non ha problemi, giusto ?
Ritorno all'Indice
L'abilitazione di questo modo di funzionamento forzerà PGP a chiedere
conferma prima di aggiungere al vostro portachiavi pubblico ognuna
delle chiavi contenute in un file esterno.
Ritorno all'Indice
È 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 però
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 è
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
capacità di registrazione limitate, sicchè vorrebbero poter evitare
di occupare spazio con i manuali. Per soddisfare questa esigenza, PGP
può essere indotto a soprassedere a questo controllo, abilitando il
flag NOMANUAL durante la generazione delle chiavi, così:
pgp -kg +nomanual
Il flag NOMANUAL può 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 è stata caricata su Compuserve, e
distribuita ad un numero enorme di utilizzatori che mi hanno chiamato
al telefono per chiedermi come mai un programma così complicato non
avesse nessun manuale. Questo pacchetto è 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
Ritorno all'Indice
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 difficoltà a trovare qualcosa di utile in questo file, perchè
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 già fidando dello stesso algoritmo per proteggere i
vostri messaggi. Se è 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
Il DES (Federal Data Encryption Standard) era un buon algoritmo per la
maggior parte delle applicazioni commerciali. Il Governo non si è
però mai fidato del DES per proteggere i propri dati classificati,
perchè la chiave del DES è di soli 56 bits, abbastanza corta da
soccombere ad un attacco condotto con la forza bruta. Anche il DES
completo a 16 passaggi è stato attaccato con qualche successo da
Biham e Shamir con l'uso della crittoanalisi differenziale, e da Matsui
con l'uso della crittoanalisi lineare.
Il più devastante attacco pratico portato al DES è 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, può ottenerne la produzione per 10.50 $ al pezzo,
e può inserirne 57000 in una macchina speciale con un costo di 1
milione di dollari. Questa macchina può provare tutte le chiavi DES in
7 ore, ottenendo la soluzione mediamente in 3,5 ore. Si può stornare
e nascondere 1 milione di dollari dal budget di molte società.
Spendendo 10 milioni di dollari la soluzione è 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 può essere violato in alcuni secondi. Tutto
questo significa che il DES a 56 bits ormai è morto per ciò 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 è però tre volte più 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, bensì 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. È basata sulla filosofia della
miscelazione di operazioni da diversi gruppi algebrici. È molto più
veloce del DES e, come il DES, può 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 è stata sviluppata all'ETH di Zurigo
da James L. Massey e Xuejia Lai, e pubblicata nel 1990. Non è un
algoritmo "casalingo". I suoi progettisti hanno un'ottima reputazione
nella comunità dei crittografi. I primi documenti pubblicati
chiamavano l'algoritmo IPES (Improved Proposed Encryption Standard),
ma più tardi il nome è 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 più
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, così come i servizi militari di diversi
Paesi Europei. Man mano che questo nuovo algoritmo attira le attenzioni
e gli sforzi dei più 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 verità: 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 più veloci. Dopo tutto, una catena è forte
come il suo anello più debole. Essi chiedono una spiegazione di questo
apparente "compromesso" nella solidità di PGP. Questo può succedere
perchè 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 più forte di ogni sistema di cifratura
convenzionale. Bene, non lo è.
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
più 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 è nell'algoritmo a chiave pubblica,
e non in quello convenzionale.
Non è 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
più 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 è la sua maggiore
forza intrinseca, ma la semplicità di gestione delle chiavi.
L'RSA non è 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 è
questa: usare l'RSA puro per ammassi di dati è l'approccio sbagliato,
punto. È troppo lento, non è più forte, e può perfino essere più
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
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., è 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 perchè, a differenza della funzione di
compressione di PGP, PKZIP e ZIP danno la simpatica possibilità di
immagazzinare più di un file nello stesso file compresso. PGP non
tenterà di comprimere un file già compresso. Dopo la decifrazione,
il destinatario potrà decomprimere il testo in chiaro usando PKUNZIP.
Se il file decifrato è 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. È
stato scelto ZIP principalmente per la disponibilità del codice
sorgente in C liberamente portabile, perchè ha un rapporto di
compressione veramente buono, e perchè è 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
La selezione del messaggio è 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, cosicchè qualunque
alterazione del messaggio stesso farà sì che esso produca una
selezione differente. Questo rende possibile controllare se una simile
alterazione è effettivamente avvenuta ad opera di un falsario. La
selezione di messaggio è 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 è migliore di un semplice checksum,
perchè è abbastanza facile sviluppare un messaggio che produca un
checksum uguale. Come per un checksum comunque, è impossibile ricavare
un messaggio partendo dalla sua selezione.
Una selezione da sola non è sufficiente ad autenticare un messaggio.
L'algoritmo di generazione è conosciuto pubblicamente, e non richiede
la conoscenza di nessuna chiave per essere applicato. Se tutto ciò che
facciamo è allegare una selezione al messaggio, un falsario può
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 è calcolata dal mittente, che usa la propria
chiave segreta per cifrarla assieme ad un'etichetta di tempo, creando
così una firma digitale, o certificato di firma. Questa firma è 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 è 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 è praticabile), oppure creare una nuova firma
partendo dal messaggio falso (e non è praticabile senza possedere la
chiave segreta del mittente).
Le firme digitali provano l'identità del mittente, e la genuinità del
messaggio (il messaggio non è stato alterato nè per errore, nè per
dolo). Inoltre le firme impediscono di ripudiare il messaggio, perchè
per il mittente non è semplice rinnegare la propria firma apposta con
la propria chiave segreta.
Oltre ad essere più veloce che firmare direttamente tutto il
messaggio, l'uso delle selezioni presenta altri vantaggi. La firma può
essere di un formato piccolo e standard, indipendente dal formato del
messaggio. Il software può controllare automaticamente l'integrità
del messaggio, in modo simile all'uso del checksum. La firma può
restare separata dal messaggio, forse addirittura in un archivio
pubblico, senza rivelare informazioni importanti sul messaggio stesso,
perchè nessuno può ricavare il contenuto del messaggio dalla sua
selezione.
L'algoritmo di selezione del messaggio usato qui è 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 probabilità di trovare due messaggi che producano
la stessa selezione sia di 1 contro 2^64, mentre la probabilità di
riuscire a scrivere un messaggio che produca una selezione data è
dell'ordine di 1 contro 2^128. L'algoritmo MD5 è stato verificato
scrupolosamente per trovare delle debolezze. Comunque è 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
Al di fuori degli Stati Uniti, il brevetto RSA non è valido, così 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 accetterà il nuovo formato, la cui descrizione
dettagliata è disponibile presso il MIT. Se tutti acquisiranno le
versioni nuove prima di settembre 1994, o poco dopo, ci saranno pochi
problemi di interoperabilità.
Questo cambio di formato a partire dalla versione 2.6 è 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
capacità di leggere quello prodotto dalle versioni vecchie. L'unica
differenza in questo caso, è che si tratta di un aggiornamento
"legale" invece che tecnico. Vale la pena di effettuare questo
cambiamento, se può portare la pace nei nostri giorni.
Secondo ViaCrypt, che vende la versione commerciale di PGP, il suo PGP
si evolverà per mantenere l'interoperabilità con la versione
freeware.
Un'altro cambiamento influenza l'interoperabilità 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
necessità 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 più
lunghe di 1024 bits. Si è sempre pensato al limite superiore di 1024
bits -- deve esserci un limite superiore, per ragioni di prestazioni ed
interoperabilità. A causa però di un difetto nelle versioni
precedenti di PGP, era possibile generare chiavi più lunghe di 1024
bits. Queste chiavi più grandi causavano problemi di interoperabilità
fra le diverse versioni più vecchie di PGP, che usavano algoritmi
aritmetici differenti con formati diversi delle parole. Su alcune
piattaforme PGP si inchiodava sulle chiavi più grosse. Oltre a questi
vecchi problemi di formato di chiavi, il limite di 1024 bits è ora
anche imposto da RSAREF. Una chiave di 1024 bits è molto probabilmente
al di là delle possibilità di attacco dei principali governi. Nelle
versioni future, PGP potrà maneggiare chiavi più grosse.
In generale c'è compatibilità dalla versione 2.0 fino alla 2.4. A
causa dell'aggiunta di nuove funzioni, le versioni più vecchie
potrebbero non essere sempre in grado di maneggiare alcuni files creati
con le versioni più 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 è più 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 è 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
Nessun sistema per la sicurezza dei dati è impenetrabile. PGP può
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
più economici, senza preoccuparvi di quelli che comportano alti costi.
Alcuni dei punti che seguono possono sembrare indebitamente paranoici,
ma questo tipo di atteggiamento è appropriato per una discussione
ragionevole sui temi della vulnerabilità.
Ritorno all'Indice
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 può essere scoperta facilmente con un computer
che provi tutte le parole del dizionario fino ad individuare quella
giusta. È per questo che una frase chiave è molto meglio di una
parola chiave. Un attaccante più 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 può 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
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 è 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
In effetti questo può anche accadere accidentalmente, se per qualche
ragione capita qualcosa di strano al disco e dei files vengono
cancellati o corrotti. Qualcuno può 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 cancellò dopo averla spedita. Tempo dopo, a storia
finita, il floppy disk fu danneggiato in qualche modo, e dovette
recuperarlo, perchè conteneva altri documenti importanti. Chiese a suo
marito di salvare il disco, cosa che le sembrava completamente sicura
perchè sapeva di aver cancellato la lettera incriminante. Il marito
utilizzo un pacchetto commerciale di recupero dei dischi, e recuperò
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 è
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
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 è al
di là 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, è 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 è
difficile da creare per un assalitore, perchè il codice sorgente di
PGP è 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 più 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 è 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
però non vi aiuterà per niente se il vostro sistema operativo è
infetto, e non scoprirà se la vostra copia originale di PGP.EXE è
stata maliziosamente alterata in modo da comprometterne la capacità
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 è distribuita assieme
ad una o più 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
Non cullatevi in un falso senso di sicurezza solo perchè possedete un
programma di crittografia. Le tecniche di crittografia proteggono i
vostri dati solo finchè sono cifrati-- la violazione della sicurezza
fisica può ancora compromettere i dati in chiaro o le informazioni
scritte e dette.
Questo tipo di attacco è più economico della crittoanalisi.
Ritorno all'Indice
Ritorno all'Indice
Adesso però, 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 è più 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 ciò che si vede sul vostro
schermo. In un sistema Unix, qualunque altro utente può 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 perchè tutti gli utilizzatori sono fidati, o perchè hanno
misure di sicurezza di sistema in grado di fronteggiare gli attacchi
possibili da parte degli intrusi, o ancora semplicemente perchè non
ci sono sufficienti potenziali intrusi interessati. Alcuni sistemi Unix
sono sicuri perchè 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 è nato per proteggere i vostri dati mentre sono in chiaro o su
di un sistema compromesso. Non può 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 è tale da
consigliarvi di usare PGP solo su di un sistema isolato a singolo
utente e sotto il vostro diretto controllo fisico. È ciò che faccio
io, ed è ciò che raccomando.
Ritorno all'Indice
Ritorno all'Indice
Non c'è 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
può 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 può 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 è peggiore di quello già esistente per le firme
scritte. Chiunque può scrivere vicino alla propria firma su di un
contratto la data che preferisce, eppure nessuno sembra preoccuparsi
più di tanto per questo stato di cose. In alcuni casi, una data
"inesatta" vicino ad una firma può anche non essere associata con una
truffa effettiva. La data vicino alla firma può indicare il momento in
cui il documento è stato firmato, oppure il momento in cui si vuole
che acquisti validità.
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 è stato firmato.
Un'autorità di certificazione degna di fiducia od un notaio possono
generare firme notarili con un'etichetta di tempo affidabile. Questo
non richiederebbe necessariamente un'autorità centralizzata. Forse
qualunque presentatore affidabile o qualunque parte disinteressata
potrebbe assolvere questa funzione, nello stesso modo in cui è 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 credibilità più grande o più valore legale
dell'etichetta allegata alla firma originale.
Un'ottima trattazione di questo argomento è 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
È possibile che il Governo abbia qualche metodo classificato per
violare l'algoritmo di crittografia convenzionale IDEA(tm) usato da
PGP. Questo è 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. È probabile
che il carico di lavoro necessario per rompere questo codice sia di
gran lunga più costoso di quello che è 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 necessità. La Boulder Software Engineering
(indirizzo e telefono sono riportati alla fine di questo documento)
può fornire questo tipo di servizio.
Riassumendo, senza una protezione crittografica adeguata delle vostre
trasmissioni di dati, può 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 più sforzi ed affrontare molte spese per
violare la vostra riservatezza.
Se vi proteggete contro gli attacchi più semplici, e vi sentite sicuri
del fatto che la vostra riservatezza non sarà violata da aggressori
determinati e ricchi di risorse, probabilmente sarete al sicuro usando
PGP. PGP vi darà una riservatezza abbastanza buona (Pretty Good
Privacy).
Ritorno all'Indice
Ritorno all'Indice
PGP è (c) Copyright Philip R. Zimmermann, 1990-1994. Tutti i diritti
sono riservati. Anche questo manuale d'uso di PGP è 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 può derivare.
Il MIT può 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 responsabilità per i danni che possano
derivare dall'uso di questo software, anche se dovessero essere causati
da difetti del software stesso, e non dà alcuna indicazione a
proposito del valore di mercato di questo software o della sua
applicabilità a specifiche situazioni. Il software è fornito "così
come è", senza garanzie esplicite o implicite di qualsiasi tipo.
Siccome determinate azioni possono portare alla cancellazione di files
o alla loro irrecuperabilità, l'autore non assume nessuna
responsabilità per la perdita o modifica di qualunque dato.
Ritorno all'Indice
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 è applicabile fuori dai confini e, almeno
al momento della stesura del documento, l'autore non è al corrente di
nessun brevetto RSA in altri Paesi. Alcune agenzie federali potrebbero
usare l'algoritmo RSA, poichè il suo sviluppo è 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 più 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 così
come è stata fatta non viola le leggi sui brevetti.
PKP non si è 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
società 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, perchè penso che la crittografia a chiave pubblica sia
destinata a diventare una tecnologia cruciale per la protezione della
nostra riservatezza e delle nostre libertà civili nella nostra
società sempre più 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 è 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 è stato rilasciato dal MIT per un breve periodo di prova nel
maggio 1994, prima di rilasciare la versione 2.6. PGP 2.5 è stato
rilasciato sotto la licenza RSAREF del 16 marzo 1994, che è una
licenza a tempo indeterminato, per cui questa versione potrebbe essere
usata negli USA per sempre. Sarebbe meglio però 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 sarà in grado di leggere il formato nuovo
generato a partire dal 1 settembre 1994. (si veda la sezione
"Compatibilità con le versioni precedenti e future di PGP").
La versione 2.0 di PGP è 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 è 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 è spontaneamente diffusa negli Stati Uniti
senza nessun intervento mio o del gruppo di sviluppo.
La cifratura convenzionale a blocchi IDEA(tm) usata da PGP è coperta
da brevetto in Europa. Il brevetto è detenuto dall'ETH e da una
società svizzera chiamata Ascom-Tech AG. Il brevetto USA è il numero
5,214,703, mentre quello Europeo si chiama EP 0 482 154 B1. IDEA(tm) è
marchio registrato da Ascom-Tech AG. Non è 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 può 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 è 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, perchè
attualmente non è possibile ottenere una versione licenziata di PGP al
di fuori di quelle nazioni. Se la situazione legale negli Stati Uniti
cambierà, in modo che gli utilizzatori esteri possano acquistare una
versione commerciale di PGP (da ViaCrypt, da me, o da una società
estera che possieda una mia licenza), allora Ascom-Tech farà valere i
suoi diritti di brevetto sugli utilizzatori commerciali. Per ottenere
notizie più 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
Potete anche distribuire il pacchetto di rilascio con i codici
sorgenti. Il codice sorgente di PGP è 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'integrità della crittografia dipende dallo stretto
controllo di qualità sugli algoritmi e sui protocolli. Oltre a questo,
i "miglioramenti" di PGP possono influenzare l'interoperabilità,
creando confusione per gli utilizzatori e problemi di compatibilità
che potrebbero danneggiarne la reputazione (oltre a danneggiare la
mia), e minare l'affidabilità guadagnata dal marchio registrato PGP.
Questo è già successo, ed è il motivo per cui lo sottolineo qui.
È una cosa che crea mal di testa per l'assistenza tecnica, e ricevo
telefonate da utenti confusi che hanno dei problemi o perchè
possiedono loro stessi una versione mutante di PGP, o perchè stanno
cercando di lavorare con una chiave, una firma o un messaggio prodotti
da una versione mutante ed incompatibile. Il codice sorgente non è
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 possibilità 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 è
sempre rilasciata con le firme degli sviluppatori, in modo che possiate
controllare l'integrità 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 più nuove di PGP non sono più pubblicate sotto GPL. I
termini della licenza RSAREF sono più restrittivi di quelli della GPL.
Però, anche se una versione di PGP è pubblicata senza RSAREF, in una
situazione od in un posto dove il brevetto RSA non è applicabile, non
voglio che la GPL sia applicata a PGP, per una quantità di motivi, non
ultimo il fatto che la GPL non è ottimale per proteggere PGP
dall'essere ripubblicato con dei "miglioramenti" ad-hoc.
Fuori dagli Stati Uniti, il brevetto RSA non è valido, sicchè 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 è necessario, è facile modificare e
ricompilare il codice di PGP in modo che esegua i calcoli RSA senza
usare la libreria RSAREF, come è stato fatto per PGP 2.3a. In casi del
genere, questo PGP modificato può essere ri-rilasciato sotto gli
stessi termini di licenza della versione ufficiale freeware
corrispondente, ma senza le restrizioni specifiche RSAREF. Non può
essere rilasciato sotto GPL, come alcune versioni più vecchie. Inoltre
questo manuale deve comunque essere allegato. La versione modificata di
PGP non può essere usata in ambienti dove RSAREF è richiesto.
Ritorno all'Indice
Ho raggiunto un accordo con ViaCrypt nell'estate 1993 per licenziare in
esclusiva i diritti commerciali su PGP, sicchè c'è per le società un
modo di utilizzare PGP senza rischi di persecuzioni legali da parte di
PKP per aver infranto i diritti di brevetto. Perchè 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 già ottenuto una licenza da PKP per produrre, usare e
vendere prodotti che utilizzino RSA. ViaCrypt offre una via di uscita
dal pantano dei brevetti perchè PGP possa penetrare nell'ambiente
delle società. 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 è imposta dal
mio accordo con ViaCrypt: la versione freeware di PGP è 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
è un modo che soddisfa questo requisito.
Ritorno all'Indice
Il rilascio standard freeware di PGP
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
In origine PGP è 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 è di
qualche centinaio di chiavi. Essendo però 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 è in grado di eseguire questa operazione in un tempo
ragionevole, mentre voi attendete davanti alla vostra tastiera. Almeno
non per portachiavi enormi.
Gli amanti di Unix sono abituati ad usare i collegamenti Unix per far
lavorare insieme due applicazioni. L'uscita di un'applicazione può
essere inviata attraverso un collegamento per fungere da ingresso per
un'altra. Perchè 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 può funzionare in
questo modo. Se non capite cosa questo significhi, probabilmente questa
funzione non vi serve.
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:
o:
pgp -kr +force Smith
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.
Normalmente PGP richiede all'utilizzatore di inserire una frase chiave
laddove sia richiesta per sbloccare una chiave segreta. È però
possibile inserire questa chiave in una variabile di sistema, operando
dallo shell. La variabile PGPPASS può quindi contenere la frase chiave
che PGP tenterà di usare per prima. Se la frase contenuta in PGPPASS
non è corretta, PGP la chiederà all'utilizzatore.
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. # TMP è la directory per i file temporanei di PGP (tipo RAM disk)
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.
TMP = "e:\" # Può essere scavalcato dalla variabile di ambiente TMP.
Armor = on # Usa il comando -a (armatura ASCII) ogni volta che è applicabile.
# CERT_DEPTH indica la profondità della catena di affidabilità,
# ovvero per quanti livelli un presentatore può presentarne un
# altro.
cert_depth = 3
o: pgp -ea lettera.txt smith
Valore di default: TMP = ""
Valore di default: LANGUAGE = "en"LANGUAGE = "fr"
Valore di default: MYNAME = ""
Valore di default: TEXTMODE = off
Valore di default: CHARSET = NOCONV
Valore di default: ARMOR = off
Valore di default: ARMORLINES = 720
Valore di default: KEEPBINARY = off
Valore di default: COMPRESS = on
Valore di default: COMPLETES_NEEDED = 1
Valore di default: MARGINALS_NEEDED = 2
Valore di default: CERT_DEPTH = 4
Valore di default: BAKRING = ""
Valore di default: PUBRING = "$PGPPATH/pubring.pgp"
Valore di default: SECRING = "$PGPPATH/secring.pgp"
Valore di default: RANDSEED = "$PGPPATH/randseed.bin"
Valore di default: PAGER = ""
Valore di default: SHOWPASS = off
Valore di default: TZFIX = 0
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
Valore di default: CLEARSIG = on
Valore di default: VERBOSE = 1
Valore di default: INTERACTIVE = off
Valore di default: NOMANUAL = off
Diamo un'occhiata ad alcune funzioni interne di PGP.
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". Può 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.
Come già 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 più veloce.
Parliamo quindi di questo algoritmo di cifratura convenzionale. Non è
il DES.
PGP normalmente comprime il testo in chiaro prima di cifrarlo. Sarebbe
troppo tardi cercare di comprimerlo dopo la cifratura; il testo cifrato
è 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.
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".
PGP versione 2.6 può 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 però.
PGP 2.6 è stato programmato in modo da cambiare leggermente il suo
comportamento a partire dal 1 settembre 1994. Da quella data, PGP
comincerà ad utilizzare un formato nuovo e leggermente diverso per i
messaggi, le firme e le chiavi. Sarà ancora in grado di leggere ed
elaborare messaggi, firme e chiavi prodotti con il vecchio formato, ma
genererà quello nuovo. Questo cambiamento è teso a scoraggiare l'uso
delle versioni vecchie (2.3a o più 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.
Vulnerabilità
È probabile che l'attacco più semplice sia quello che può 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, può leggere i vostri messaggi e firmare a vostro
nome.
Una vulnerabilità maggiore può esistere se la vostra chiave pubblica
è stata manomessa. Questa può essere la vulnerabilità più cruciale
di un sistema di crittografia a chiave pubblica, in parte perchè
alcuni nuovi utilizzatori potrebbero non riconoscerla immediatamente.
L'importanza di questa vulnerabilità e le appropriate contromisure
sono dettagliate nella sezione "Come proteggere il vostro portachiavi
pubblico dalle manomissioni" nel "Volume I".
Un altro potenziale problema per la sicurezza è 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. È come eliminare dei documenti
cartacei classificati mettendoli nel cestino della carta da riciclare,
anzichè nel distruggi-documenti. Il settore di disco continua a
contenere i dati classificati che volevate cancellare, e sarà
probabilmente sovrascritto da dati nuovi nel futuro. Se un intruso
legge questo settore di disco poco dopo il vostro utilizzo, può
recuperare il vostro file.
Un'altro attacco può 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 sì che non controlli le
firme in maniera completa. Questo tipo di attacco è più economico di
quello crittoanalitico.
Una breccia nella vostra sicurezza fisica può permettere a qualcuno di
acquisire (fisicamente appunto) i vostri files in chiaro o i vostri
messaggi stampati. Un avversario determinato può 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. È 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 è successo all'hotel Watergate.
Un altro tipo di attacco che è 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, è probabilmente ancora più 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 può 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 è conosciuta come "Tempest", ed è 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 ?
PGP è 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
potrà vedere i miei testi in chiaro o le mie chiavi segrete.
Anche se un assalitore non può 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. È equivalente alla sorveglianza che può essere
effettuata controllando la vostra bolletta del telefono per vedere
chi avete chiamato, quando e quanto è durata la conversazione anche
senza conoscere l'effettivo contenuto di quest'ultima. Si chiama
analisi del traffico. PGP da solo non può 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.
Una vulnerabilità di PGP in qualche modo oscura è 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.
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 può succedere, ma è 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.
Aspetti legali
"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.
Il sistema di crittografia a chiave pubblica è stato sviluppato dal
MIT, che detiene un brevetto su di esso (U.S. patent #4,405,829, del
20 settembre 1983). Una società 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).
PGP non è shareware, ma freeware. Pubblicato come un servizio per la
comunità. Distribuire PGP gratis incoraggerà molte più persone ad
usarlo, con un impatto sociale più grande. Sentitevi liberi di
distribuire il pacchetto di rilascio di PGP completo e senza modifiche
a quante più 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.
La versione freeware di PGP è 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 viacrypt@acm.org).
PGP non può, 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.