Pretty Good Privacy

Pretty Good Privacy software
Genere	Crittografia
Sviluppatore	Phil Zimmermann
Data prima versione	1991
Ultima versione	1.0 2.0 2.3 2.5 (maggio 1994) 2.6.2i (24 ottobre 1994) 2.7.1 2.6.3i (18 gennaio 1996) 2.3a 2.4 5.0 (1999) 8.0.3 (2003) 6.5.8 (2000) 7.0.3 6.5 (5 aprile 1999) 8.1 5.5 2.6 (26 maggio 1994)
Sistema operativo	Multipiattaforma
Linguaggio	C
Sito web	www.broadcom.com/products/advanced-threat-protection/encryption

Pretty Good Privacy (PGP) è una famiglia di software di crittografia per autenticazione e privacy, da cui è derivato lo standard OpenPGP.

È probabilmente il crittosistema più adottato al mondo, descritto dal crittografo Bruce Schneier come il modo per arrivare «probabilmente il più vicino alla crittografia di livello militare».

PGP è stato originariamente sviluppato da Phil Zimmermann nel 1991. Il nome gli fu suggerito da una drogheria di Lake Wobegon, l'immaginaria città natale del conduttore radiofonico Garrison Keillor. La drogheria si chiamava "Ralph's Pretty Good Grocery" ("la drogheria piuttosto buona di Ralph") e il suo slogan era "se non lo puoi trovare da Ralph, probabilmente puoi anche farne a meno", chiusa pochi anni dopo l'apertura.

OpenPGP come standard Internet

Inizialmente Phil Zimmermann aveva distribuito PGP come software proprietario, ma per la sua rapida diffusione nel 1998 le sue specifiche furono raccolte dall'Internet Engineering Task Force (IETF) attraverso i seguenti standard RFC: RFC2440 nel 1998, RFC3156 nel 2001 e l'RFC4880 nel 2007. Così nacque lo standard OpenPGP.

Un'implementazione conforme allo standard OpenPGP è ad esempio GNU Privacy Guard.

Sicurezza di PGP

Per la teoria della complessità computazionale l'uso appropriato di PGP rende praticamente impossibile che un intermediario fra mittente e destinatario possa giungere al messaggio d'origine, ad esempio tramite metodo forza bruta. Questo tipo di attacco impiegherebbe un grande calcolatore per un tempo simile ad un migliaio di volte l'età dell'universo conosciuto, fermo restando che sia il messaggio originale che la propria chiave privata dovrebbero essere salvati su un dispositivo non compromesso se si vuole che la robustezza dell'intero sistema ovviamente non crolli.

Nessun crittosistema, PGP incluso, può proteggere informazioni ottenute violando fisicamente il dispositivo su cui è salvata la chiave privata dell'interessato e scoprendo la sua passphrase, o in altri modi come ad esempio tramite phishing, ingegneria sociale o tramite il cosiddetto metodo del tubo di gomma. Occorre quindi che gli utilizzatori di crittosistemi non diventino loro stessi la via per violare i loro dati.

Ad esempio, in un'indagine del 2005 l'FBI ottenne un mandato per installare keylogger o altri spyware sul computer di un sospettato di spaccio. L'indagine si è conclusa con 30 anni di reclusione del sospettato, dato che compromettendo direttamente il suo computer si era facilmente risaliti a qualsiasi suo documento.

PGP ed email

Con PGP è possibile cifrare ogni tipo di dato o file ed è consuetudine vederlo impiegato per scambiarsi posta elettronica, dato che le e-mail non hanno un sistema di cifratura nativo. PGP e l'S/MIME sono infatti due standard RFC per lo scambio di posta elettronica.

Un esempio di software libero per scambiarsi posta elettronica tramite PGP è Enigmail per Mozilla Thunderbird.

Come funziona PGP

Uso di PGP per proteggere la confidenzialità dei messaggi: a sinistra la cifratura ed a destra la decifratura

PGP usa sia la crittografia asimmetrica (detta anche a chiave pubblica) sia quella simmetrica, e fino ad un certo punto una infrastruttura a chiave pubblica (PKI) che ha qualche somiglianza con lo standard dei certificati d'identità X.509. PGP usa la crittografia a chiave asimmetrica, nella quale il destinatario del messaggio ha generato precedentemente una coppia di chiavi collegate fra loro; una chiave pubblica ed una privata. La chiave pubblica del destinatario serve al mittente per cifrare una chiave di sessione per un algoritmo di crittografia simmetrica; questa chiave viene quindi usata per cifrare il testo in chiaro del messaggio. Molte chiavi pubbliche di utenti PGP sono a disposizione di tutti dai numerosi key server (server delle chiavi) PGP sparsi per il mondo, che operano come mirror reciproci.

Il destinatario di un messaggio protetto da PGP decifra prima la chiave di sessione inclusa nel messaggio usando la sua chiave privata. Decifra poi il testo usando la chiave di sessione con l'algoritmo simmetrico. L'uso di due cifrature è giustificato dalla notevole differenza nella velocità di esecuzione tra una cifratura a chiave asimmetrica ed una a chiave simmetrica (l'ultima è generalmente molto più veloce). Ci sono inoltre delle vulnerabilità crittografiche nell'algoritmo a chiave asimmetrica utilizzato da PGP quando viene usato per cifrare direttamente un messaggio.

Una strategia simile può essere usata per capire se un messaggio è stato alterato, o se è stato mandato effettivamente da chi dice di essere il mittente. Per fare entrambe le cose, il mittente usa PGP per 'firmare' il messaggio con l'algoritmo di firma RSA o Digital Signature Algorithm (DSA). Per fare questo, PGP calcola un 'hash' (anche chiamato message digest) dal testo in chiaro, e crea poi da questo hash la firma digitale usando la chiave privata del mittente.

Il destinatario del messaggio calcola il message digest dal testo in chiaro decifrato, e poi usa la chiave pubblica del mittente ed il valore del message digest firmato con l'algoritmo di firma. Se la firma corrisponde al message digest del testo in chiaro ricevuto, si presuppone (con un grande margine di sicurezza) che il messaggio ricevuto non sia stato alterato né accidentalmente né volontariamente da quando è stato firmato. Questa presunzione si basa su diverse considerazioni: è poco probabile, visti gli algoritmi ed i protocolli usati in PGP, che un avversario possa creare una firma per un messaggio qualsiasi, e quindi un messaggio ricevuto che superi questo test dev'essere stato mandato da chi dice di essere il mittente. Gli esperti di sicurezza chiamano spesso questa proprietà non ripudio: non si può ripudiare la paternità del messaggio.

In ogni caso chiunque possegga la parte privata delle chiavi può facilmente creare una firma corretta per ogni cosa. In un mondo di e-mail virus, rootkits, trojan, ed altri malware, ed agenti dell'FBI con ordinanze della corte, il termine 'non-repudiation' dev'essere usato con le pinze, dato che le chiavi private possono essere compromesse (e copiate) in maniera illegale. Ma questa è una affermazione valida per 'tutti' i sistemi che utilizzano algoritmi a chiave asimmetrica per la firma digitale e quindi inglobano il concetto di non-repudiation. PGP non è particolarmente vulnerabile, ma Zimmerman è stato saggio e non solo divertente, nel chiamare il suo sistema "pretty good" (abbastanza buono).

Sia quando si cifra un messaggio che quando si verifica la firma, è fondamentale che la chiave pubblica utilizzata per mandare il messaggio ad una persona o ente appartenga effettivamente al destinatario. Scaricare una chiave pubblica da qualche parte non è per niente una garanzia di questa corrispondenza; lo spoofing intenzionale od accidentale è possibile. PGP include delle precauzioni per la distribuzione delle chiavi pubbliche in 'certificati d'identità' i quali sono costruiti crittograficamente, in maniera tale da rendere qualsiasi manomissione o disturbo accidentale facilmente rivelabile. Rendere un certificato effettivamente impossibile da modificare senza lasciare tracce non è sufficiente. Questo può prevenire la manomissione solo dopo la creazione del certificato, non prima. Gli utenti devono anche verificare in qualche maniera che la chiave pubblica in un certificato appartenga effettivamente alla persona o ente che ne reclama la paternità. Per questo PGP racchiude un sistema di 'voto' dei certificati; è chiamata web of trust (letteralmente, "rete di fiducia"). PGP ha anche sempre incluso una maniera per cancellare i certificati d'identità che possono essere diventati inutilizzabili; questo è, più o meno, l'equivalente dei certificate revocation list (certificati di revoca) dei sistemi PKI più centralizzati. Le versioni più recenti di PGP supportano anche una data di scadenza per i certificati.

Questa doverosa cautela nell'accettare le chiavi pubbliche di altri utenti non è una prerogativa di PGP. Tutti i sistemi di crittografia a chiave pubblica e privata hanno lo stesso problema, anche se in apparenza un po' diversi, e non esiste ancora una soluzione pienamente soddisfacente. Il sistema di PGP, almeno, permette all'utente di decidere se usare o meno il sistema di voto, mentre molti altri sistemi PKI richiedono invece che ogni certificato venga confermato da una CA (Certification Authority) centrale.

I primordi

PGP fu interessato dalle restrizioni sulla esportazione della crittografia del governo USA, già dagli albori. Questo inconveniente dimostra alcuni dei problemi politici che circondano la crittografia moderna di qualità e costituisce un pasticcio contingente e difficile da seguire. Che minaccia tempi di prigionia piuttosto elevati e multe salate.

Zimmermann produsse la prima versione del PGP nel 1991. Era stato per molto tempo un attivista anti-nucleare e creò il PGP in modo che i suoi compagni potessero usare sistemi BBS e memorizzare messaggi e file in tutta sicurezza. Non era richiesta licenza se l'uso non era commerciale, non c'era spesa neanche simbolica e veniva fornito il codice sorgente. PGP si diffuse su Usenet e di qui sul World Wide Web.

Limitazioni all'esportazione, indagini giudiziarie e ricadute politiche

In breve tempo il PGP iniziò a diffondersi al di fuori dei confini degli USA, e nel febbraio 1993 Zimmermann fu incriminato dal governo degli Stati Uniti con l'accusa di "esportazione di armi senza apposita licenza".

In molti trovarono difficilmente comprensibile questa accusa e fu osservato, in tono satirico, che un programma software può facilmente diventare un'arma con l'aggiunta di un detonatore e un po' di esplosivo.

Ciononostante secondo quanto stabilito dal Regolamento per l'Esportazione dei prodotti e servizi USA i sistemi di crittografia che utilizzassero una chiave maggiore di 40-bit erano considerati come munizioni e, dato che il PGP ha sempre adottato chiavi maggiori di 128 bit, all'epoca rientrava perfettamente nella casistica. Oltretutto le sanzioni, per chi fosse riconosciuto colpevole, erano e rimangono rilevanti. I regolamenti all'export statunitensi sono ancora in vigore, ma nel corso della seconda metà degli anni Novanta hanno subito importanti modifiche: la giurisdizione è stata assegnata al Dipartimento del Commercio invece di essere dipendente dal Dipartimento di Stato; i sistemi di crittografia sono stati riclassificati come duplice uso, invece di essere considerati come munizioni; il processo di approvazione è stato semplificato nel 2000; infine la lunghezza della chiave di norma ammessa è stata portata (in parecchi e confusi passaggi) oltre la soglia dei 40 bit.

Dal 2000 in poi il rispetto dei regolamenti è diventato inoltre più semplice. Ad esempio, nei primi anni Novanta l'approvazione di una domanda di export doveva ricevere un'approvazione esplicita. Invece dal 2000 vige il principio del silenzio-assenso per cui se l'approvazione non viene negata entro 30 giorni allora è lecito ritenere la domanda approvata. Sono state inoltre facilitate le procedure per approvare il codice sorgente, come pure altre facilitazioni per sviluppatori open source o per piccole aziende. Prima di imbarcarsi in un importante progetto crittografico che potrebbe essere interessato da tali regolamentazioni, sarebbe comunque il caso di consultare un avvocato che sia esperto degli aspetti legali legati alla crittografia.

Come conseguenza delle modifiche normative introdotte, il PGP attualmente non è più definibile come "arma non esportabile" e può essere utilizzato (ed esportato) ovunque (a condizione che la legislazione locale lo consenta). Inoltre l'incriminazione a carico di Zimmerman è stata archiviata senza che siano state rubricate condotte criminali in capo allo stesso o ad altri soggetti.

Dal momento che la regolamentazione statunitense sull'export non è comunque universalmente applicabile, il PGP dopo il suo lancio, acquisì un seguito considerevole in tutto il mondo. Tra gli utilizzatori e gli estimatori vi erano sia dissidenti nei paesi totalitari (alcune affezionate lettere di questi ultimi a Zimmerman sono state pubblicate ed utilizzate nelle deposizioni tenutesi davanti al Congresso statunitense), liberali in diverse parti del mondo (cfr. le pubblicazioni delle deposizioni di Zimmerman nel corso di varie udienze) nonché gli attivisti della 'libera comunicazione; questi ultimi si fecero promotori sia della pubblicizzazione che della diffusione del PGP (per i dettagli vedi diversi loro manifesti).

I problemi con i brevetti

Le versioni iniziali di PGP hanno avuto anche dei problemi con i brevetti già registrati. La prima versione ricorreva a un cifrario progettato dallo stesso Zimmermann e denominato Bass-O-Matic da uno sketch del Saturday Night Live in cui si utilizzavano dei pesci e dei tritatutto in cucina. Ben presto ci si accorse però che questo cifrario non era sicuro, così venne rimpiazzato dal cifrario IDEA. Entrambi gli algoritmi, sia quello per la chiave simmetrica IDEA che quello per la chiave asimmetrica RSA, sono brevettati e per utilizzarli è necessaria un'autorizzazione. All'epoca ci fu un acceso dibattito sul fatto che Zimmermann avesse avuto l'autorizzazione per utilizzare il RSA nel PGP. A tal proposito, Zimmermann dichiarò che l'allora RSA Data Security (operativa adesso come RSA Security), in uno dei primissimi incontri, gli avesse dato l'autorizzazione, purché fosse a scopo non-commerciale, mentre RSA smentiva tutto quanto. Di conseguenza, fu un reclamo partito dalla RSADSI alla Dogana statunitense a creare il cosiddetto caso Zimmermann sull'uso dell'algoritmo RSA nel PGP.

Per complicare ulteriormente il quadro, l'algoritmo RSA era brevettato solamente negli USA (questo per la difficoltà di rispondere alla varia modulistica di richiesta brevetti nel mondo) con il risultato di poter essere utilizzato liberamente (tenendo sempre conto delle problematiche di brevetto viste in precedenza) in tutte le altre nazioni. Ciò nonostante, gli inventori / proprietari di IDEA furono decisamente più liberali negli USA che nell'Unione europea. E se non ci fosse già abbastanza confusione, il brevetto dell'algoritmo RSA era parzialmente controllato dal MIT attraverso il proprietario del brevetto, il RSADSI: gli inventori del RSA lavoravano tutti al MIT al momento della sua creazione.

In qualunque modo andò la disputa Zimmermann/RSADSI, il MIT ebbe pochi problemi con IDEA; invece, si trovò parecchio in difficoltà a causa della posizione ostile del RSADSI, contraria all'uso non commerciale del RSA nel PGP. Il risultato del conflitto sulla licenza del RSA fu un fork di PGP in:

• una versione USA (conforme al brevetto RSA) che usa una libreria crittografica shareware dell'RSA
• una versione internazionale che usa il codice RSA originale creato da Zimmermann ed i suoi collaboratori.

La versione USA fu distribuita direttamente dallo stesso MIT, insieme ad altri, attraverso Internet, le BBS ed utenti e gruppi di sistemi di comunicazione privata come AOL e CompuServe. Alla fine sul sito del MIT, c'era il requisito che l'indirizzo email al quale PGP sarebbe stato inviato fosse negli USA od in Canada, e che il ricevente fosse residente in uno dei due stati.

In Norvegia, Ståle Schumacher Ytterborg sviluppò e mantenne la versione internazionale del PGP, che venne chiamata PGP-i (dove i sta per internazionale). Era desiderabile al tempo che la versione internazionale fosse sviluppata e mantenuta fuori dagli USA per evitare ulteriori difficoltà con i regolamenti USA sull'esportazione e con il brevetto RSA.

Sviluppi successivi

Durante tutta questa agitazione il team di Zimmermann stava lavorando ad una nuova versione di PGP chiamata PGP 3. Questa nuova versione doveva avere considerevoli miglioramenti nella sicurezza, compresa una nuova struttura di certificato che non aveva i piccoli problemi di sicurezza dei certificati usati da PGP 2.x oltre che permettere ad un certificato di avere chiavi separate per la firma e per la cifratura. Inoltre le passate negative esperienze con brevetti e problemi di esportazione li portò ad evitare completamente i brevetti. PGP 3 ha introdotto l'uso dell'algoritmo simmetrico CAST-128 (chiamato anche CAST5) e degli algoritmi asimmetrici DSA e ElGamal, nessuno di questi coperto da brevetto.

PGP diventa commerciale

Dopo l'indagine terminata nel 1996 Zimmermann ed il suo gruppo fondarono una compagnia per produrre nuove versioni di PGP. Si fusero con Viacrypt (alla quale Zimmermann aveva venduto i diritti commerciali di PGP e che aveva acquistato la licenza RSA direttamente dalla RSADSI), che cambiò nome in PGP Incorporated. Il nuovo team Viacrypt/PGP cominciò a lavorare alle nuove versioni di PGP basate su PGP 3. A differenza di PGP 2, che aveva esclusivamente una interfaccia a riga di comando, PGP 3 fu progettato sin dall'inizio per essere una libreria software, permettendo agli utenti di lavorare sia a riga di comando che grazie ad una interfaccia grafica. L'accordo originale tra Viacrypt e il gruppo di Zimmermann precisava che Viacrypt avrebbe distribuito versioni con numeri pari, mentre Zimmermann con numeri dispari. Viacrypt, quindi, creò una nuova versione (basata su PGP 2) che chiamò PGP 4. Per eliminare il dubbio che PGP 4 fosse un successore di PGP 3 (PGP 4 derivava appunto da PGP 2), PGP 3 fu rinominato e distribuito come PGP 5 nel maggio del 1997.

All'interno di PGP Inc., c'erano ancora dubbi riguardo ai brevetti. RSADSI criticava la cessione della licenza RSA della Viacrypt alla nuova società nata dalla fusione dei due gruppi. PGP Inc. adottò un'informale standard interno chiamato Unencumbered PGP (letteralmente, PGP senza intralci): "non usare nessun algoritmo con problemi di licenza".

OpenPGP e implementazioni

Data l'importanza mondiale di PGP molti sentivano il bisogno di scrivere una propria implementazione interoperabile con PGP5. Il team Unencumbered PGP all'interno della PGP Inc. ha convinto Phil Zimmermann e il resto degli esecutivi della PGP Inc. che uno standard aperto per PGP fosse critico per loro e per tutta la comunità crittografica. Già nel 1997 esistevano software compatibili con PGP, tra i quali un software della compagnia belga Veridis (chiamata Highware a quel tempo) che aveva comprato una licenza per l'uso del codice di PGP 2 direttamente da Zimmermann.

Nel giugno 1997 la PGP Inc. ha proposto al IETF la creazione di uno standard chiamato OpenPGP. Hanno dato il permesso al IETF di usare il nome OpenPGP per descrivere questo nuovo standard e qualsiasi programma che lo supportasse (PGP, Pretty Good Privacy e Pretty Good sono tutti marchi registrati della PGP Corporation, al 2002). Lo IETF ha accettato la proposta e ha creato l'OpenPGP Working Group.

GNU Privacy Guard è un software libero conforme a questi standard, patrocinato dalla Free Software Foundation e facente parte del Progetto GNU. Il suo sviluppo fu supportato da fondi stanziati dal governo tedesco e rimane patrocinato dalla Free Software Foundation.

L'acquisizione da parte della Network Associates

Nel dicembre del 1997, la PGP Inc. venne acquistata dalla Network Associates, Inc., di cui Zimmermann ed il gruppo PGP divennero dipendenti. La NAI continuò a sperimentare l'esportazione attraverso la pubblicazione del software, diventando la prima compagnia ad avere una strategia di esportazione legale, grazie alla pubblicazione del codice sorgente. Sotto questa protezione, il team PGP aggiunse al programma originale nuove funzionalità, come la cifratura dei dischi, firewall per desktop, rilevamento delle intrusioni, e le VPN di IPsec. Dopo la legalizzazione delle esportazioni del 2000 non fu più necessario pubblicare il codice sorgente, e la NAI smise di farlo, nonostante le obiezioni del gruppo PGP. Gli utenti di PGP sparsi in tutto il globo furono decisamente delusi, ed inevitabilmente, nacquero alcune teorie cospirative contro la NAI.

All'inizio del 2001 Zimmermann lasciò la NAI. Ha lavorato come capo crittografo per la Hush Communications, che fornisce un programma per email basato su OpenPGP, Hushmail. Ha anche lavorato con Veridis e altre società.

Nell'Ottobre 2001 la NAI ha annunciato che i suoi diritti sul PGP erano in vendita e che avrebbe sospeso lo sviluppo di PGP. Nel febbraio 2002, la NAI ha cancellato ogni progetto riguardante PGP.

La PGP Corporation

Nell'estate del 2002 alcuni ex-membri del gruppo PGP hanno acquistato i diritti di PGP dalla NAI (eccetto per la versione a riga di comando), e, nell'agosto dello stesso anno, hanno formato una nuova compagnia, la PGP Corporation. Questa si è fatta carico dei nuovi contratti di assistenza agli utenti di PGP e di onorare quelli stretti prima della sua nascita, e Zimmermann vi ha lavorato come consulente speciale.

NAI ha conservato i diritti sulla versione a riga di comando di PGP dopo il cambio del marchio aziendale in McAfee, a sua volta divenuta Intel security dopo l'acquisizione da parte di Intel, appunto, nell'agosto 2010, ha continuato a venderla sotto il nome di "McAfee E-Business Server". Fino al gennaio 2004, a causa dei suoi precedenti accordi con la NAI PGP Corp. non aveva il permesso di commercializzare prodotti in diretta concorrenza.

In cooperazione con Zimmermann, Verdis ha sviluppato e distribuito una versione di OpenPGP compatibile con quella a riga di comando, Filecrypt. I codici sorgenti di Filecrypt e GnuPG sono entrambi disponibili, così come quelli di versioni precedenti per varie piattaforme.

A partire dal suo acquisto dei diritti della NAI nel 2002, la PGP Corp. ha offerto assistenza tecnica in tutto in mondo. Nel 2002 ha pubblicato PGP 7.2 per Mac OS 9, seguito rapidamente da PGP 8.0 e PGP 8.0 Personal per Mac e Windows, e da una versione freeware ed una open source. Nel 2003, ha pubblicato PGP 8.0.1DE per gli utenti tedeschi, PGP Universal (basato su una nuova concezione di PGP per server, che implementa un'architettura di sicurezza che si auto-gestisce). Nel 2004, ha pubblicato PGP Desktop 8.1 per Mac e Windows, PGP Command Line 8.5 per Windows, Solaris e Linux (l'accordo riguardo alla riga di comando tra la PGP Corp. e la NAI scadeva nel gennaio 2004) e PGP Universal 1.2. Nel 2005, hanno pubblicato PGP Desktop 9.0, PGP Universal 2.0 e PGP Command Line 9.0.

Il 29 aprile 2010, la Symantec Corporation ha firmato l'acquisto della PGP Corporation, con la fusione delle due aziende resa effettiva nel mese di giugno di quello stesso anno.

Compatibilità tra versioni di PGP

Un concorrere di difficoltà con l'uso di prodotti brevettati e con le leggi per l'esportazione ha causato alcuni problemi di compatibilità, ma fortunatamente la situazione è migliorata sostanzialmente dopo l'adozione dello standard OpenPGP e la formazione della PGP Corp nel 2002.

Lo standard OpenPGP specifica i meccanismi perché le due copie di PGP presenti ai due capi di una comunicazione possano negoziare l'algoritmo di cifratura da utilizzare nei messaggi come anche altri parametri aggiunti man mano dopo la versione PGP 2.x. Tutte le implementazioni devono seguire questa parte di specifiche per essere conformi con OpenPGP, quindi non ci sono sostanziali problemi di interoperabilità tra implementazioni diverse, comprese quelle di PGP Corp, Gnu/FSF (ovvero GPG), Hushmail, Veridis, Articsoft, Forum e altre. Gli sviluppatori di questi programmi collaborano abbastanza strettamente e correggono i problemi di interoperabilità, considerati alla stregua di bug.

Problemi di compatibilità con PGP 2.x

La situazione è diversa quando versioni recenti di PGP operano con versioni 2.x dello stesso. PGP 2 usava algoritmi brevettati che erano licenziati sotto vari (e confusi) termini. Il brevetto di uno di questi algoritmi, RSA, è scaduto nell'autunno del 2000, ma il brevetto su IDEA è ancora valido. Mentre alcune versioni di PGP sono compatibili con PGP 2.x (per esempio, quella di PGP Corp. e Hushmail), altre non lo sono. La più conosciuta, GnuPG, di default non supporta l'algoritmo IDEA usato in tutte le versioni 2.x di PGP. Questo supporto può essere aggiunto come plugin, ma gli utenti devono compilarselo da soli, e -ovviamente- affrontare tutti gli eventuali problemi di licenza che possono riscontrare con il suo uso. L'uso commerciale di IDEA richiede una licenza, mentre quello non-commerciale no.

Al momento attuale, il modo migliore per trattare i problemi di interoperabilità con PGP 2.x è semplicemente di evitarli usando un sistema conforme ad OpenPGP. Nel decennio in cui è stato sviluppato e distribuito in PGP 2.x sono stati scoperti molti problemi di sicurezza minori. Tutti quelli risolubili sono stati risolti con una patch nelle versioni correnti ed aggiornate di PGP 2.x, ma è noto che alcuni protocolli fondamentali sono vulnerabili a certi tipi di attacchi e non sono stati modificati. Nessuna delle vulnerabilità conosciute è giunta né nello standard OpenPGP, né in nessuna delle sue implementazioni. Mentre nessuno di questi problemi con le versioni "patchate" di PGP 2.x è considerato seriamente insicuro, il gruppo OpenPGP di IETF sta per deprecare la compatibilità con PGP 2.x. Se non si ha un reale bisogno di compatibilità con PGP 2.x, questo non sarà un grosso problema. Nonostante ciò, Ståle Schumacher Ytteborg sta ancora mantenendo il suo sito web pgpi.org come repository per PGP, inclusi gli aggiornamenti di vecchie versioni come la 2.x. L'ultimo aggiornamento risale al 03.12.2002.

Storicamente c'era un'incompatibilità aggiuntiva e deliberata tra le stesse versioni 2.x, a causa della disputa sulla licenza RSA. Per risolvere la contesa PGP 2.6 venne reso incompatibile con le versioni 2.x precedenti, attraverso l'aumento dei numeri di versione di alcune strutture dati interne e usando l'implementazione RSAREF dell'algoritmo. Il codice PGP originale per l'algoritmo RSA poteva essere usato al di fuori degli USA, nelle varianti 'i', come PGP 2.6.3i. C'era più di una buona ragione di ordine tecnico, non solo legale, per fare ciò: l'implementazione dell'algoritmo del gruppo PGP aveva una velocità superiore al doppio di quella dell'RSAREF.

Nel frattempo negli USA il team PGP creò PGP 3 (effettivamente pubblicato come PGP 5, vedi sopra) e fu adottato lo standard IETF OpenPGP. I continui problemi di licenza con l'algoritmo RSA li costrinse, insieme al gruppo GnuPG, ad escluderlo. Ma quando il brevetto scadde nel 2000, il supporto per RSA fu riportato in PGP e nello standard OpenPGP e quindi è venuta meno la necessità di creare una versione "USA" ed una "Internazionale" di ogni versione di PGP.

Sinteticamente ora è meglio usare una versione recente di un sistema OpenPGP. La cooperazione tra gli sviluppatori di OpenPGP ha essenzialmente eliminato problemi di incompatibilità tra le diverse implementazioni.

Voci correlate

• Crittografia a chiave pubblica
• GNU Privacy Guard
• Phil Zimmermann
• Web of trust
• Signal

Collegamenti esterni

• (EN) Sito ufficiale, su broadcom.com.
• (EN) Denis Howe, Pretty Good Privacy, in Free On-line Dictionary of Computing. Disponibile con licenza GFDL
• PGP Corporation, su pgp.com. URL consultato il 1º maggio 2019 (archiviato dall'url originale il 30 dicembre 2004).
• Una versione PGP compatibile con OpenPGP, su veridis.com. URL consultato il 12 dicembre 2004 (archiviato dall'url originale il 17 dicembre 2004).
• The GNU Privacy Guard Un'implementazione della Free Software Foundation dello standard OpenPGP
• Gruppo standard per la versione "IETF - RFC 2440" di PGP, su openpgp.org.
• PGPI.org Informazioni sulle versioni open source attualmente disponibili di PGP, incluse le versioni 2.x, e informazioni generali su GPG e PGP.
• Home Page del creatore di PGP, con numerose informazioni sul programma, su philzimmermann.com.
• Practical Attacks on PGP, informazioni sulla sicurezza di PGP, su privacy.com.au. URL consultato il 12 dicembre 2004 (archiviato dall'url originale il 7 dicembre 2004).
• PGP Corporation's Support Forum Archiviato l'8 febbraio 2005 in Internet Archive. community di supporto e contributi dallo staff di supporto di PGP
• Guida pratica a PGP Documenti ed istruzioni per l'uso di PGP
• PGP, come funziona?, su dia.unisa.it. URL consultato il 13 marzo 2009 (archiviato dall'url originale il 17 luglio 2009).