PGP combines the convenience of the Rivest-Shamir-Adleman (RSA) public key cryptosystem with the speed of conventional cryptography, message digests for digital signatures, data compression before encryption, good ergonomic design, and sophisticated key management. And PGP performs the public-key functions faster than most other software implementations. PGP is public key cryptography for the masses.Zum Funktionsumfang gehören u.a. folgende Dienste:
Digitale Signaturen gestatten es dem Empfänger/Leser, mit hoher Sicherheit festzustellen, ob eine Datei, E-Mail etc. authentisch und integer ist, d.h. tatsächlich vom angegebenen Autor/Absender stammt und nicht durch Dritte erstellt bzw. von diesen nachträglich verändert wurde. Außerdem ist es für den Unterzeichner praktisch unmöglich, die geleistete Unterschrift später abzustreiten. Digitale Unterschriften ermöglichen also die Sicherung der Authentizität und Integrität von Nachrichten sowie einen Urhebernachweis.
Computernetze wie z.B. das Internet sind als potentiell unsicher zu betrachten. Es besteht technisch die Möglichkeit, fremde Daten zu lesen und auch zu manipulieren. Durch eine Verschlüsselung unter Verwendung sog. symmetrischer Verfahren läßt sich die Vertraulichkeit der über das Netz ausgetauschten Informationen erreichen, d.h., nur die dazu berechtigten Empfänger gelangen in den Besitz der vertraulichen Information, da nur sie die verschlüsselte Nachricht entschlüsseln können.
Werden die betreffenden Dokumente zusätzlich digital signiert, so lassen sich neben der Vertraulichkeit auch noch die o.g. Eigenschaften (Authentizität, Integrität, Urhebernachweis) erreichen.
Ein wichtiges Anwendungsgebiet von PGP ist der kryptographische Schutz von E-Mails. Die Nachrichteninhalte werden dabei mit Hilfe des symmetrischen Algorithmus IDEA verschlüsselt. Die Verteilung der hierfür benötigten Schlüssel erfolgt mit Hilfe des asymmetrischen RSA-Verfahrens, das außerdem noch der Erstellung und Verifikation digitaler Signaturen dient. Der entscheidende Vorteil asymmetrischer gegenüber symmetrischen Verfahren besteht darin, daß der Schlüsselaustausch keinen sicheren Kanal erfordert, sondern problemlos über öffentliche Kanäle (Telefon, Internet, ...) erfolgen kann. Unter Verwendung von PGP ist es daher relativ leicht möglich, mit bisher unbekannten Personen oder Gruppen vertraulich zu kommunizieren.
Die für die beiden zuvor genannten Funktionen benötigten Schlüsselpaare sowie die zu ihrer sicheren Weitergabe benötigten Zertifikate können durch PGP erzeugt und in sog. Schlüsselringen verwaltet werden.
Vertrauliche Informationen sollten auch im Dateisystem eines Computers verschlüsselt hinterlegt werden, da sonst generell die Gefahr besteht, daß sie in falsche Hände gelangen. Dies betrifft nicht nur netzbasierte Filesysteme (AFS, NFS, ...), wie sie z.B. in Rechenzentren typisch sind, sondern auch Festplatten im eigenen PC sowie Disketten, die entwendet oder leicht kopiert werden können, sofern andere Personen Zugang zu ihnen haben.
PGP gestattet deshalb den Schutz privater Datenbestände durch konventionelle Kryptographie, konkret durch den Algorithmus IDEA. Als externe Repräsentation der Schlüssel dienen vom Nutzer gewählte Passphrases. Dabei handelt es sich im Gegensatz zu Paßwörtern um beliebig lange Zeichenfolgen (z.B. ganze Sätze mit Leer- und Sonderzeichen). Um einen Mißbrauch in der Praxis auszuschließen, sollte man die Passphrases stets hinreichend lang und qualitativ so gut wählen, daß sie mit an Sicherheit grenzender Wahrscheinlichkeit nicht erraten werden können.
Die im zentralen Filesystem der TU Chemnitz unter /uni/global installierte internationale Version PGP 2.6.3ia basiert auf den folgenden drei kryptographischen Algorithmen:
RSA und IDEA gelten gegenwärtig als sehr sicher, da es trotz intensiver Kryptoanalyse durch viele anerkannte Kryptologen aus dem akademischen und kommerziellen Umfeld nicht gelungen ist, diese Verfahren zu brechen. Zumindest liegen darüber keine Veröffentlichungen vor. Man muß dabei aber immer damit rechnen, daß es durchaus (z.B. bei den technisch und personell sehr gut ausgestatteten Geheimdiensten) der Fall sein kann, daß Verfahren existieren, die ein teilweises oder vollständiges Brechen dieser Kryptosysteme gestatten.
Davon wird die Öffentlichkeit nur in Ausnahmefällen erfahren, da sich das Mitteilungsbedürfnis der Geheimdienste und bestimmter staatlicher Behörden sehr stark in Grenzen hält. Ein Beispiel hierfür ist die Geschichte der Public-Key-Kryptographie. Als deren Erfinder werden Whitfield Diffie und Martin Hellman sowie unabhängig von beiden auch Ralph Merkle angesehen. Es gilt allerdings mittlerweile als ziemlich sicher, daß der NSA (National Security Agency der USA) und ähnlichen Organisationen die der Public-Key-Kryptographie zugrunde liegende Idee schon eher als den drei genannten Wissenschaftlern bekannt war. Einige Informationen dazu wurden von Steve Bellovin auf der Seite The Prehistory of Public Key Cryptography [http://www.research.att.com/~smb/nsam-160/] zusammengetragen.
In den dort erwähnten, im Dezember 1997 veröffentlichten Papieren der CESG (Communications-Electronics Security Group, eine britische Regierungsbehörde [http://www.cesg.gov.uk/]) schreibt der mittlerweile verstorbene CESG-Mitarbeiter James H. Ellis, daß er bereits in den 60er Jahren die Idee der Public Key Cryptography (PKC) entwickelt hatte, damals unter der Bezeichnung Non-Secret Encryption (NSE). Im Januar 1970 publizierte er im (geheimen) CESG-Report The Possibility of Secure Non-Secret Digital Encryption sein Existence Theorem, also den Nachweis, daß es NSE bzw. PKC überhaupt geben kann. Aus anderen CESG-Reports geht hervor, daß die CESG das Prinzip der bis heute breit genutzten asymmetrischen Verfahren Diffie-Hellman (1976) und RSA (1978) bereits einige Jahre vor deren Veröffentlichung in der akademischen Gemeinde kannte.
Diese Papiere der CESG stehen unter dem URL http://www.cesg.gov.uk/about/nsecret.htm öffentlich zur Verfügung.
Der Algorithmus MD5 wurde ursprünglich als ein sehr starkes Verfahren betrachtet. Neuere Untersuchungen durch den deutschen Kryptologen Prof. Hans Dobbertin haben aber gezeigt, daß Teile des Verfahrens erfolgreich attackiert werden können, so daß das Vertrauen in die Kollisionsresistenz des MD5 relativ stark gesunken ist. Zwar ist es bisher nicht gelungen, das gesamte Verfahren zu brechen, allerdings wird bei der Entwicklung neuer Protokolle, Verfahren und Werkzeuge der MD5 meist nicht mehr favorisiert, so wie das noch bis etwa 1995/96 der Fall war.
Für weitere Details sei auf die folgenden beiden Dokumente verwiesen:
PGP 2.6.x chiffriert generell alle Nutzerdaten mit IDEA, wobei der Schlüssel je nach Anwendungsmodus aus einer vom Anwender frei wählbaren Passphrase abgeleitet oder zufällig erzeugt wird. Vor der Verschlüsselung werden die Daten komprimiert. Dazu verwendet PGP Routinen von Mark Adler, Richard B. Wales und Jean-loup Gailly, die aus dem relativ bekannten Paket Info-ZIP stammen.
Möchte man verschlüsselte Nachrichten austauschen, dann genügt es, die öffentlichen Schlüssel der jeweiligen Partner zu beschaffen. Die Gefahr des Abhörens besteht dabei nicht, da die Schlüssel ohnehin öffentlich sind. Lediglich ihre Manipulation muß zuverlässig verhindert werden. Dazu verwendet PGP sog. Zertifikate, die durch eine digitale Signatur die Echtheit eines öffentlichen Schlüssels, d.h. dessen tatsächliche Zugehörigkeit zu seinem vermeintlichen Eigentümer beurkunden.
PGP nutzt den relativ aufwendigen und daher zeitintensiven RSA-Algorithmus nicht zur Verschlüsselung der möglicherweise sehr umfangreichen Daten der Anwender, sondern nur zur Erstellung digitaler Signaturen sowie zur kryptographisch gesicherten Verteilung der zufällig generierten IDEA-Schlüssel, mit denen die Nutzerdaten chiffriert wurden.
Die digitalen Unterschriften werden nicht aus der Nachricht selbst, sondern aus dem mittels der Einweg-Hashfunktion MD5 (MD steht für Message Digest) gebildeten "Fingerabdruck" der Länge 128 Bit erzeugt. Das Verfahren MD5 stammt wiederum von Ronald Rivest und wurde 1992 im RFC 1321: The MD5 Message-Digest Algorithm beschrieben.
Unter einer Hashfunktion versteht man eine Funktion, die mindestens die folgenden zwei Eigenschaften besitzt:
In seinem Artikel The Status of MD5 After a Recent Attack sagt Dobbertin, daß die von ihm präsentierten Attacken für praktische Anwendungen des MD5 zwar noch keine Gefährdung darstellen, einer solchen aber schon recht nahekommen. Deshalb empfiehlt er, den MD5 künftig nicht mehr in Applikationen einzusetzen, die kollisionsresistente Einweg-Hashfunktionen benötigen, wozu typischerweise Verfahren zur Erstellung digitaler Signaturen zählen. Als Alternativen nennt er SHA-1 und RIPEMD-160. Diese beiden Verfahren werden allerdings von 2.6.x nicht unterstützt. Bei PGP 5.x/6.x kommt dagegen vorzugsweise SHA-1 zur Anwendung.
Wie das folgende Zitat aus einem News-Artikel zeigt, vertritt Markus G. Kuhn die Ansicht, daß die Kollisionsresistenz von Hashfunktionen bei digitalen Signaturen entbehrlich ist:
Dass man fuer digitale Unterschriften Kollisionsresistenz einer Hashfunktion braucht halte ich fuer ein weit verbreitetes Missverstaendnis. Die Einwegeigenschaft sollte ausreichen wenn man gesetzlich alle Hash preimages als unterschrieben ansieht. Nur der Unterschreiber kann Kollisionen ausnutzen, also muss das nur zu seinem Nachteil ausgelegt werden und schon braucht man keine Kollisionsresistenz mehr. Man muss dann nur sicherstellen, dass man keinen Text unterschreibt den man nicht selbst erstellt hat, aber das laesst sich ja durch Hinzufuegen von ein paar Zufallsbits an den Anfang eines Textes bevor man unterschreibt vermeiden.Aus dem gleichen Grund reicht es voellig, bei PGP nur die ersten 10 Bytes des Fingerprints zu vergleichen. Man kann so Platz auf Visitenkarten sparen ohne Sicherheit einzubuessen.
Es empfiehlt sich natürlich generell, regelmäßig und aufmerksam die neusten kryptographischen Erkenntnisse zu verfolgen, um so früh wie möglich auf erfolgreiche Attacken gegen die eingesetzten kryptographischen Verfahren reagieren zu können.
pgp [Optionen] [Argumente]
Anmerkung: Die in eckigen Klammern eingeschlossenen Angaben sind optional.
Eine detaillierte Beschreibung der PGP-Funktionen kann den zur Software mitgelieferten Manuals entnommen werden, die unter dem AFS-Pfad
/afs/tu-chemnitz.de/global/text/doc/pgp-2.6.3ibzw. unter
/uni/global/text/doc/pgp-2.6.3izu finden sind.
In der Mehrzahl der Fälle dürfte allerdings der sehr kompakte Überblick über die wichtigsten Kommandos und deren Syntax genügen, den man durch Aufruf der Online-Hilfe erhält:
pgp -h
Wer an deutschen Hilfe-Texten interessiert ist, sollte sich die Datei
/uni/global/text/doc/pgp-2.6.3i/config.txtin das Verzeichnis $HOME/.pgp/ kopieren und dort die Zeile
Language = engegen
Language = deersetzen.
Hinweis: In der deutschen Hilfe wird die Passphrase als Mantra bezeichnet.
pgp -kgJeder Nutzer, der selbst Mails oder Dokumente unterschreiben und/oder von anderen Personen verschlüsselte (und typischerweise per Netz erhaltene) Informationen lesen möchte, benötigt zu seiner Identifikation mindestens ein RSA-Schlüsselpaar. In der Regel besitzt ein Nutzer genau ein solches Paar, das, sobald einmal der Public Key öffentlich bekanntgegeben wurde, so lange wie möglich konstant bleiben sollte. Deshalb ist es wichtig, den privaten Schlüssel sorgfältig vor Verlust zu schützen und keinem Dritten zugänglich zu machen.
Die Schlüssellängen sollten nicht zu kurz gewählt werden. Bisher wurde oft auf 1024 Bit orientiert, wobei dieser Wert in Anbetracht der rapide zunehmenden Rechenleistung der zur Verfügung stehenden Computer mittlerweile eher als Untergrenze anzusehen ist. Für neu generierte Schlüssel sollte man sicherheitshalber besser 2048 oder, sofern es die verwendete PGP-Implementierung gestattet und es von der beabsichtigten Verwendungsdauer des Schlüssels her sinnvoll erscheint, noch mehr Bits als Länge wählen.
PGP legt die RSA-Schlüssel in sog. Schlüsselringen ab. Dabei handelt es sich um Binär-Dateien mit einer klar definierten Struktur. Die generierten privaten Schlüssel finden sich in der Datei secring.pgp, die öffentlichen Schlüssel liegen im File pubring.pgp.
Diese und weitere von PGP verwendete Dateien können prinzipiell in jedem beliebigen Verzeichnis gespeichert werden. Dessen vollständiger Pfad ist in der Umgebungsvariablen PGPPATH zu spezifizieren. Existiert diese Variable nicht, so wird standardmäßig das Verzeichnis $HOME/.pgp/ angenommen. Die nachfolgenden Bemerkungen beziehen sich ausschließlich auf diesen Standard-Pfad.
Die privaten Schlüssel werden aus Sicherheitsgründen in der Regel verschlüsselt im Dateisystem abgelegt. Deshalb fordert PGP den Anwender bei der Key-Generierung zur Eingabe einer Passphrase auf, die er nachträglich zwar jederzeit ändern kann, aber niemals vergessen sollte, da sonst seine Schlüssel wertlos geworden sind.
Wichtig: Das Verzeichnis $HOME/.pgp/ muß von Hand angelegt werden:
mkdir $HOME/.pgp
Es sollte nur dem jeweiligen Eigentümer zugänglich sein. Im UNIX-Filesystem empfiehlt sich daher folgende Anweisung:
chmod 700 $HOME/.pgp
Im AFS sollte die Access Control List nur den Eigentümer sowie den Backup-Nutzer backup enthalten. Zur Manipulation der ACL steht das Kommando fs zur Verfügung. Um z.B. den anonymen Nutzer system:anyuser von der Liste zu entfernen, könnte man folgendes Kommando verwenden:
fs sa $HOME/.pgp system:anyuser none
pgp -ka Schlüssel_Datei
Die in der Datei Schlüssel_Datei gespeicherten öffentlichen Schlüssel werden zum Inhalt der Datei $HOME/.pgp/pubring.pgp hinzugefügt. Dabei hat der Nutzer die Gelegenheit, die neuen Keys sofort zu signieren.
pgp -kr Nutzer-ID
Der zur Nutzeridentifikation Nutzer-ID gehörende Public Key wird aus dem Schlüsselring $HOME/.pgp/pubring.pgp entfernt. Gibt es mehrere Keys pro Nutzer, sind sie schrittweise zu löschen.
pgp -kxa Nutzer-ID Datei
Der zur Nutzeridentifikation Nutzer-ID gehörende Schlüssel wird zusammen mit allen vorhandenen Zertifikaten aus dem Schlüsselring $HOME/.pgp/pubring.pgp extrahiert, so daß er leicht an einen Partner übergeben werden kann. Das Ergebnis findet man unter dem Namen Datei.asc im Format ASCII radix-64, das sich direkt (also auch ohne Verwendung von MIME) für die Verschickung per E-Mail eignet.
pgp -ks Nutzer-ID
Durch diese Operation kann jeder Anwender den öffentlichen Schlüssel des angegebenen Nutzers im eigenen Schlüsselring zertifizieren.
pgp -sa Datei
Die angegebene Datei wird mit dem eigenen privaten Schlüssel signiert. Als Resultat ensteht das File Datei.asc, das die Nachricht und die Signatur enthält. Bedingt durch die Option -a liegt das Ergebnis im Format ASCII radix-64 vor, das sich direkt (also auch ohne Verwendung von MIME) für die Verschickung per E-Mail eignet.
Hinweis: Durch Aufruf von pgp -sta ist es möglich, die Nachricht im Klartext zu belassen und die ASCII-Signatur darunterzusetzen. Auf diese Weise kann ein Empfänger, der kein PGP zur Verfügung hat, die Nachricht lesen, auch wenn er natürlich ihre Authentizität und Integrität nicht prüfen kann. Die Option -t bewirkt allerdings ggf. Modifikationen am Text, die beim Empfänger nicht korrekt rückgängig gemacht werden, so daß sich eine inkorrekte Signatur ergibt, obwohl die Nachricht authentisch und integer ist. Benötigt man eine robuste Lösung, speziell bei der Kommunikation zwischen verschiedenartigen Systemen (z.B. UNIX <--> DOS), so sollte immer pgp -sa verwendet werden.
pgp -ea Datei Nutzer-ID [Nutzer-ID ...]
Die angegebene Datei wird unter Verwendung des öffentlichen RSA-Schlüssels des spezifizierten Nutzers verschlüsselt, so daß sie nur noch mit dessen privatem RSA-Schlüssel dechiffriert werden kann. Es ist möglich, mehrere Nutzer-Identifikationen anzugeben, so daß eine Menge von Empfängern in der Lage ist, dieselbe Nachricht zu entschlüsseln. Die Ausgabe erfolgt in das File Datei.asc, da mit der Option -a das ASCII-Format gewählt wurde.
pgp -esa Datei Nutzer-ID [Nutzer-ID ...]
Dieses Kommando kombiniert die beiden zuvor beschriebenen Funktionen, d.h. das digitale Signieren sowie die Verschlüsselung unter Verwendung öffentlicher RSA-Keys.
pgp -cw Datei
Es erfolgt eine reine IDEA-Verschlüsselung. Der benötigte Key wird aus einer vom Nutzer erfragten Passphrase abgeleitet. Die verschlüsselte Datei erhält den Namen Datei.pgp. Schlüsselringe werden für diese Operation nicht benötigt. Die angegebene Option -w bewirkt das Vernichten der Original-Datei.
Achtung: Der Verlust der gewählten Passphrase bedeutet in der Praxis, daß der Klartext nicht wiederhergestellt werden kann! Das ist der Preis für den Einsatz kryptographisch starker Verfahren, die nur mit extremem technischem, zeitlichem und finanziellem Aufwand zu brechen sind.
pgp Datei
PGP erkennt selbständig, ob und wie die Datei verschlüsselt und/oder signiert wurde. Der Nutzer wird bei Bedarf zur Eingabe einer Passphrase aufgefordert.
PGP 5.x war anfangs ein Produkt der 1996 von Philip Zimmermann gegründeten Firma Pretty Good Privacy, Inc., die im Dezember 1997 von Network Associates (NAI) gekauft wurde. PGP ist heute ein Produkt von NAI. Dessen Windows-Versionen sind mit einer graphischen Oberfläche ausgestattet und bieten eine nahtlose Integration in verschiedene E-Mail-Programme sowie allgemein in den Windows-Desktop. Daneben steht ab Version 6.5 auch wieder die von PGP 2.6.x her bekannte Kommandozeilen-Schnittstelle zur Verfügung.
Unter dem Namen PGP bietet Network Associates eine ganze Familie kommerzieller und teilweise auch kostenfreier kryptographischer Werkzeuge an. Informationen zu den aktuellen Produkten, Lizenzbedingungen usw. finden sich auf den WWW-Seiten von NAI: http://www.pgp.com/.
Ab PGP 5.0 werden neue kryptographische Verfahren unterstützt und vorzugsweise an Stelle von RSA, IDEA und MD5 eingesetzt:
Das RSA-Verfahren wird dabei durch zwei verschiedene asymmetrische Algorithmen ersetzt, für die jeweils separate Paare aus öffentlichem und privatem Schlüssel verwendet werden:
Für das digitale Signieren und das Chiffrieren von Dokumenten werden hier also getrennte Schlüsselpaare genutzt, wogegen bei RSA ein und dasselbe Schlüsselpaar beide Funktionen erfüllt.
Jedem DSA-Signaturschlüssel (primary key) können mehrere ElGamal-Schlüssel (subkeys) zugeordnet werden, die beispielsweise für unterschiedliche Zeiträume gültig sein können. Somit ist ein Wechsel der zur Verschlüsselung genutzten ElGamal-Schlüssel möglich, ohne den Signaturschlüssel tauschen zu müssen. Dabei bleiben alle existierenden Zertifikate gültig, da sich diese immer auf den primären DSA-Schlüssel beziehen.
Bei DSA handelt es sich um den Digital Signature Algorithm. Er wird im Digital Signature Standard (DSS), dem Standard der US-Regierung für digitale Signaturen, spezifiziert: http://csrc.nist.gov/fips/fips186.ps. Trotz starker Kritik vieler Kryptologen begrenzt dieser Standard die Schlüssellänge beim DSA auf 1024 Bit.
SHA-1 ist der Secure Hash Algorithm. Es handelt sich hierbei um eine Einweg-Hashfunktion. Sie wurde im Secure Hash Standard (SHS), einem US-Bundesstandard, spezifiziert: http://csrc.nist.gov/fips/fip180-1.ps. In neueren PGP-Versionen kann außerdem die von Hans Dobbertin, Antoon Bosselaers und Bart Preneel entwickelte Einweg-Hashfunktion RIPEMD-160 genutzt werden: http://www.esat.kuleuven.ac.be/~bosselae/ripemd160.html. Beide Funktionen erzeugen jeweils einen 160 Bit langen Hashwert.
Neben IDEA stehen zwei weitere symmetrische Kryptosysteme zur Verfügung:
Beim Algorithmus CAST, der vermutlich nach seinen Autoren Carlisle Adams und Stafford Tavares benannt wurde, handelt es sich um ein relativ neues Entwurfsverfahren für symmetrische Chiffren. PGP nutzt die im RFC 2144: The CAST-128 Encryption Algorithm beschriebene und kostenfrei verfügbare konkrete Realisierung CAST-128 (auch CAST5 genannt) mit 128-Bit-Schlüsseln.
3DES (Triple DES) ist durch die dreifache aufeinanderfolgende Ausführung von DES-Operationen gekennzeichnet. DES ist der weltweit eingesetzte Data Encryption Standard, der seit 1977 den Status eines offiziellen Standards der US-Regierung hat.
DES ist eine relativ alte Chiffre, die bereits Anfang bis Mitte der 70er Jahre entwickelt und seither sehr sorgfältig und intensiv von einer Vielzahl anerkannter Kryptologen analysiert wurde. Dennoch ist bis heute kein allgemein praktikables Verfahren veröffentlicht worden, das es gestattet, den vollständigen DES-Algorithmus auf eine deutlich effizientere Weise als durch eine Brute-Force-Attacke (systematisches Durchprobieren aller Schlüssel) zu brechen. Bei DES handelt es sich nach Meinung verschiedener Experten um das weltweit am intensivsten studierte und am weitesten verbreitete Kryptosystem.
Die DES-Schlüssellänge von 56 Bit ist allerdings unter Beachtung der Leistungsfähigkeit heutiger Computertechnik zu gering, weswegen man mehrere (meist drei) DES-Operationen hintereinander anwendet. Beim Einsatz zweier unterschiedlicher DES-Schlüssel erhöht sich die Schlüssellänge dabei auf 112 Bit, bei drei unterschiedlichen Schlüsseln sogar auf 168 Bit.
Hinweis: Wenn man mit Partnern kommunizieren möchte, die noch PGP 2.6.x verwenden, ist es notwendig, eine PGP-Implementierung einzusetzen, die weiterhin die kryptographischen Algorithmen und externen Nachrichtenformate dieser älteren Versionen beherrscht. Dies ist z.B. bei PGP 6.5.1 der Fall.
GnuPG verfügt gegenwärtig wie PGP 2.6.x ausschließlich über eine Kommandozeilen-Schnittstelle. Durch verschiedene Flags kann der Anwender bei Bedarf unterschiedliche Gruppen von Operationen (Lesen und Schreiben von PGP-Paketen, Langzahlarithmetik, Verschlüsselung, Primzahlengenerierung, ...) sehr detailliert überwachen.
Bei der IETF gibt es eine Arbeitsgruppe, deren Ziel darin besteht, IETF-Standards für die von PGP genutzten Algorithmen und Datenformate zu spezifizieren sowie den MIME-Rahmen zu definieren, der einen Austausch von PGP-Daten über E-Mail oder beliebige andere Protokolle gestattet. Das externe Nachrichtenformat (message-exchange packet format) dieser als OpenPGP bezeichneten Standards ist im RFC 2440: OpenPGP Message Format spezifiziert. Weitere Informationen über OpenPGP finden sich unter http://www.ietf.org/html.charters/openpgp-charter.html sowie in einem Artikel von Ingmar Camphausen und Lutz Donnerhacke (Mitautor des RFC 2440): Probleme beim PGP-Einsatz in Zertifizierungsstellen und deren Lösung durch PGP 2.6.3in und OpenPGP.
Aktuelle GnuPG-Versionen (z.B. GnuPG 1.0.1) sind vollständig OpenPGP-kompatibel gemäß RFC 2440, unterstützen allerdings nicht die empfohlene MIME-Formatierung nach RFC 2015.
Die GnuPG-Software sowie viele weitere Informationen dazu findet man über die WWW-Seite http://www.gnupg.org.
Auf einige Punkte sei hier speziell hingewiesen:
Die Weiterentwicklung von GnuPG wird laut Pressemitteilung vom 19.11.1999 durch das Bundesministerium für Wirtschaft und Technologie (BMWi) gefördert.
GnuPG kann durch dynamische Bibliotheken um zusätzliche kryptographische Algorithmen erweitert werden. Implementierungen für IDEA und RSA stehen zur Verfügung. Damit ist GnuPG in der Lage, auch mit PGP 2.6.x zusammenzuarbeiten. Wie dies konkret geschieht, ist in dem Handbuch Replacing PGP 2.x with GnuPG beschrieben, allerdings im Unterschied zu PGP teilweise etwas trickreich und umständlich. Eine Erzeugung von RSA-Schlüsseln ist bei GnuPG generell nicht möglich.
10. Februar 2000