DEUTSCHE PGP ANLEITUNG

 Überblick oder "Was ist PGP ?"

Diese Anleitung geht vom Einsatz der CKT PGP 6.5.8 Version aus.

Informationen zu CKT [Cyber Knight Templar] PGP

  • die CKT Versionen werden von Imad R. Faiad, basierend auf dem veröffentlichten Sourcecode der regulären PGP 6.5.8 Version, gepflegt und mit dem Sourcecode veröffentlicht
  • neben den bekannten symmetrischen Algorithmen IDEA, CAST, Triple-DES sind ausserdem die OpenPGP Algorithmen Blowfish, Twofish und AES-128 bis AES-256 implementiert
  • neben den bekannten Hashalgorithmen MD5 und SHA-1 ist ausserdem RIPE-MD-160 implementiert
  • unterstützt die Herstellung von DH/DSS, ElGamal, RSA v.3 und RSA v.4 Keys
  • erweiterte Anzeigeoptionen in PGPkeys und den Verschlüsselungs-/Entschlüsselungswindows
  • Anzeige der Key-ID und des Fingerprints im Kommentar
  • Bestimmung des Subkey Algorithmus bei v.4 Keys
  • die Lizenz von NAI PGP erlaubt die eigene Kompilierung des Quellcodes, untersagt aber jede Modifizierung des Quellcodes, wie es bei PGP CKT der Fall ist.
    Deshalb sollte man vom Einsatz von PGP CKT im kommerziellen Umfeld absehen und stattdessen eine reguläre NAI PGP 6.5.8 Version einsetzen.

Die Geschichte von PGP

PGP 5.0 als grafisches Benutzerprogramm war die neueste PGP-Entwicklung seit Erscheinen der PGP Version 2.6.3 und wurde im Juni 1997 veröffentlicht. PGP 5.0 basierte auf der PGP Version 3.0, die aber nie veröffentlicht wurde.
Die Version 2.6.3, die kommandozeilenorientiert arbeitet und über die Eingabeaufforderung oder über grafische Shells (Benutzeroberflächen) bedient wird, erfreut sich weiterhin (teilweise aus guten Gründen) grosser Beliebtheit.
Es gibt einige Unterschiede zwischen beiden Versionen, die auch in dieser Anleitung behandelt werden und Einschränkungen im Funktionsumfang, der bei der Version 6 nicht so gross ist wie bei der Version 2.6.3.
Wer sich näher mit der Version 2.6.3 beschäftigen möchte, kann sich die informative Comp.Security.PGP.FAQ, mit der deutschen Übersetzung von Michael Uplawski der comp.security.pgp FAQ von A. "Galactus" Engelfriet herunterladen.



Phil Zimmermann 1996, nachdem das Verfahren gegen ihn endgültig eingestellt wurde.
PGP ist die Abkürzung für "Pretty Good Privacy", was sich etwas holprig mit "Ganz guter Geheimhaltung" übersetzen lässt.
PGP wurde von dem amerikanischen Programmierer Phil Zimmermann geschrieben und im Jahr 1991 als Freeware veröffentlicht.
Weil es kurz darauf von unbekannten Personen aus den USA nach Europa gelangte, wurde gegen Zimmermann drei Jahre lang wegen Verstosses gegen die amerikanischen Exportkontrollgesetze ermittelt, denn PGP wurde wegen seiner starken Verschlüsselung in den USA als "Waffe" eingestuft, die nicht in andere Staaten exportiert werden durfte.

Laut der Pressemitteilung vom 13.12.1999 besitzt Network Associates ab sofort eine Exportlizenz der amerikanischen Regierung zur weltweiten Ausfuhr von PGP.

Dazu Noah Salzmann von NAI am 14.12.1999:

 
 
-----BEGIN PGP SIGNED MESSAGE----- 
Hash: SHA1 
 
 
Hello, 
 
I suppose I shouldn't get into a "ADK features are not Key Escrow" debate 
as I am sure everyone's opinions are already set in stone... 
 
However, I would like to address the perception (below) that the ADK 
feature has been "locked-open" as this is indeed not the case.    
 
PGP business products, as sold in the US or anywhere else, do not have 
the ADK feature turned on by default.  The purchasing company must turn 
this on themselves.   
 
PGP products sold in the retail channel, like Personal Privacy, _never_ 
force the user to respect an ADK.  The retail (and freeware) users can 
always encrypt to the primary key while avoiding the ADK that is 
associated with that primary key.  If a company wants to prevent 
retail/freeware users from sending their employees ADK-less mail then 
they must put up scanning tools on their mail server to enforce their 
policy. 
 
NAI/PGPinc has never entered into an agreement with the U.S. Government 
in which we have traded features in PGP software for an export license, 
nor would we ever do so. 
 
We have never built a weakened version of PGP.  In fact, we don't even 
include 56-bit DES in our IPsec software, even though must of our 
competitors do.    :-P  
 
  Noah Salzman 
     noah@nai.com 
     408.346.5186 
 
 
 
 
-----BEGIN PGP SIGNATURE----- 
Version: PGP 6.5.2 
 
iQA/AwUBOFayHSQ6gdj6pyJyEQK2MACgiACc/uhd6Qfjq3aNaIeIikdA8UgAn1CQ 
xxMT8fRvpUoQu4YQXVOqWFME 
=m+WS 
-----END PGP SIGNATURE----- 
 

Zur angesprochenen ADK Funktion siehe GAK, CMR, ARR, MRK, ADK und PGP 5/6.

1996 gründete Zimmermann seine Firma PGP Included, nachdem die Ermittlungen gegen ihn eingestellt wurden, im Dezember 1997 wurde PGP Inc. von der Firma Network Associates gekauft - zu diesem Zeitpunkt stand PGP bei Version 5.5.3 -, die bis zur Version 7.0.3 mit Zimmermann zusammen weiterentwickelt und vertrieben wurde.
Auch die meisten Entwickler aus dem Team von Zimmermann wechselten mit, der Kern der Entwickler hat sich von 5.0 bis 7.0 nicht geändert.
Die erste Version von PGP nach dem Verkauf an NAI war PGP 5.5.5 - der Version 5.5.3 war nur ein neuer Infotext (About Button) hinzugefügt worden.
Die erste, neu überarbeitete und um PGPdisk und eine spezielle Businessvariante erweiterte Version unter NAI war die PGP 6.0 Reihe aus dem Jahr 1998. Mit dem PGPadmin Tool der Businessvariante Desktop Security war es auch zum ersten Mal möglich, eigenständige PGP Client-Installer-Versionen für Anwender zu erstellen, die über eine vorgegebene Konfiguration eine Erzeugung von Public Keys mit ADK-Keys erzwingen konnte.

Die OpenPGP Allianz

Anfang 2001 verlässt Phil Zimmermann NAI, um Beratertätigkeiten bei anderen Firmen, darunter HushMail, aufzunehmen und die Entwicklung weiterer OpenPGP Implementationen voranzutreiben.
Ein weiterer Beweggrund wird in der veränderten Geschäftspolitik von NAI vermutet, die auch einschließt, den Quellcode von PGP nach Version 6.5.8 nicht mehr vollständig zu veröffentlichen.
Phil Zimmermann übernimmt eine persönliche Garantie für die Integrität von NAI PGP nur noch bis PGP 7.0.3
Dem Zweck der Förderung von OpenPGP dient auch die gegründete OpenPGP Allianz.
Daneben dient die OpenPGP Allianz der technischen Abstimmung zwischen einzelnen Entwicklern, bzw. Firmen, die, gestützt auf den OpenPGP Standard RFC 2440, eigene Implementationen herstellen, um Kompatibilität zwischen den einzelnen Umsetzungen zu gewährleisten, der gemeinsamen Vermarktung OpenPGP kompatibler Produkte, der Promotion der PGP PKI und des Erfahrungsaustausches und der Beratung zwischen den Mitgliedern.
Die Mitgliedschaft ist für Unternehmen, Organisationen und Personen offen, die an der Produktentwicklung oder Erbringung von Diensten, welche auf dem OpenPGP Standard basieren, beteiligt sind.
Zu den Mitgliedern zählen u. a. Biodata, GnuPG, Network Associates, Hush Communications, Qualcomm, Zero-Knowledge.

Das Ende von NAI PGP

Ende 2001 mehrten sich die Gerüchte, NAI wolle PGP einstellen. NAI selbst lässt verlautbaren, einige PGP Komponenten in andere NAI Produktlinien zu integrieren und den Rest verkaufen zu wollen.
Im Februar 2002 verschwinden die PGP Seiten und Links von der NAI Website und Network Associates teilt seinen PGP Kunden mit, dass die weitere Entwicklung des PGP Desktop Produktes eingestellt wurde und es keine Bugfixes und Updates mehr gibt. Die Crew des ursprünglichen PGP Teams wird aufgelöst und in andere NAI Abteilungen versetzt. Dies alles, nachdem NAI keinen Käufer für seine PGP Produktlinie gefunden hatte.

Die technischen Komponenten

PGP ist ein Programm, mit dem man lokal auf der eigenen Festplatte alle Dateiarten verschlüsseln kann.
Besondere Bedeutung hat PGP aber dadurch erlangt, dass eine Vielzahl von Internetanwendern weltweit PGP zur Verschlüsselung von E-Mails und anderer Daten, die über Netzwerke versendet werden, benutzen.
Darüber hinaus kann man mit PGP Texte in Klarform (Faxe, E-Mails) mit einer digitalen Signatur versehen, um auch im elektronischen Bereich, in dem eine handschriftliche Unterschrift nicht möglich ist, eine Überprüfung der Authentizität elektronisch vorliegender Texte und Daten zu ermöglichen.
Sowohl zur Verschlüsselung als auch zur Signierung setzt PGP dabei mathematische Verschlüsselungsmethoden, sogenannte kryptografische Algorithmen, wie IDEA, RSA, Diffie-Hellmann, MD5 und SHA-1, ein, die in der Welt der Kryptografie als anerkannt sicher vor Entschlüsselung, bzw. Errechnen der originalen Daten (z. B. des Klartextes einer E-Mail) aus der verschlüsselten Form durch nicht autorisierte dritte Parteien eingestuft werden.

Ein kurzer Blick auf die Struktur und Funktionsweise des Internets reicht aus, um sich die Notwendigkeit der Verschlüsselung und Signierung vor Augen zu führen.
Wenn eine E-Mail versendet wird, werden die Datenpakete der E-Mail zum Mailserver des Providers übertragen, von dort versendet der Mailserver die Mail an den Ziel-Mailserver des Empfängers. Dabei wird die E-Mail meistens mehrere Rechner im Internet passieren, bis sie am Zielserver ankommt. Der Mailserver des Empfängers überträgt schliesslich die E-Mail auf den Rechner des Empfängers. Während des ganzen Transportweges werden die Datenpakete stets in lesbarem Klartext übertragen. D. h. an verschiedenen Stationen des Weges kann die E-Mail abgefangen und auch verändert werden: Auf dem Weg vom eigenen Rechner zum Mailserver, zwischen den einzelnen Rechnern während des Transportes und vom Ziel-Mailserver zum Empfänger. Verschafft sich eine Person einen illegalen Zugang zu einem der beteiligten Rechner, kann auch dort direkt die E-Mail abgefangen werden. Zu diesem Zweck gibt es spezielle Programme wie die Paket-Sniffer, mit denen Datenpakete abgefangen werden können. Die abgefangenen Pakete können auch in ihrem Inhalt verändert und wieder in den Datenstrom eingespeist werden.

Zur Verschlüsselung und Signierung bedient sich PGP des asymmetrischen Verschlüsselungsverfahrens und der Idee des "Web of Trust".

Asymmetrisches Schlüsselverfahren

In diesem Kapitel werden die einzelnen Bestandteile der asymmetrischen Verschlüsselung beschrieben und in Schaubildern der Verschlüsselungs- und Signiervorgang dargestellt.
Eine interaktive Flashdarstellung findet sich auf der Seite "Visualisierung zur digitalen Signatur" des Instituts für Telematik der Fraunhofer Gesellschaft
(Anmerkung: Diese Darstellung bezieht sich auf S/MIME und Signaturen nach dem SigG, wo die Schlüssel in einem Trustcenter erstellt werden, die Verschlüsselungsprinzipien sind aber vergleichbar).

Bei PGP 6 wird, wie schon zuvor mit der Version 2.6.3 ia oder 2.6.3 in, das asymmetrische Schlüsselverfahren eingesetzt. Das heisst, jeder PGP-Benutzer hat zwei zusammengehörende Schlüssel (ein Schlüsselpaar), bestehend aus:

Private Key ("privater Schlüssel")

der Aufbewahrungsort für den eigenen (wenn man nur einen PGP-Key benutzt) oder die eigenen (wenn man mehrere PGP-Keys verwendet) privaten Schlüssel ist der private Schlüsselbund (die Datei "secring.skr")
PGP bildet einen Hashwert aus der gewählten Passphrase, den "Secret Key". Mit dem Secret Key wird der Private Key von PGP verschlüsselt und dann im Secring gespeichert. Somit wird der Private Key direkt durch den Secret Key und indirekt durch die dem Secret Key zugrunde liegende Passphrase geschützt.
Detaillierte Informationen zur Passphrase, auch "Mantra" genannt, finden sich in der Mantra FAQ

Mit dem Private Key werden verschlüsselte Nachrichten entschlüsselt und die digitalen Unterschriften ("Signaturen") erzeugt.
Deshalb wird PGP jedesmal, wenn man entschlüsselt oder signiert, die Passphrase abfragen, da ja in beiden Fällen der Private Key, bzw. Secret Key zum Einsatz kommt.

Public Key ("öffentlichen Schlüssel")

der Aufbewahrungsort für alle öffentlichen Schlüssel, also auch dem eigenen Public Key ist der öffentliche Schlüsselbund (die Datei "pubring.pkr")
Mit dem Public Key wird eine Nachricht verschlüsselt oder die Signatur eines Absenders überprüft. Verschlüsselung und Signierung können dabei miteinander kombiniert werden.

Dabei kann man aus dem Public Key den Private Key nicht berechnen und ohne den Private Key zu besitzen, kann man keine Nachricht entschlüsseln, die mit dem dazugehörigen Public Key verschlüsselt wurde. Auch wenn mit dem Private Key eine Signatur erstellt wurde, kann man aus dieser Signatur nicht den Private Key errechnen.
Darüber hinaus kann eine Nachricht nicht entschlüsselt, bzw. Signaturen erstellt werden, wenn der Private Key entwendet wurde, wenn der Angreifer die Passphrase und damit den Secret Key nicht kennt, bzw. über Wörterbuchangriffe (Dictionary Attack) errechnen kann.

PGP und die Sicherung des Umfeldes

Der Klima-Rosa-Angriff, März 2001

Dies galt bis zur Veröffentlichung des Klima-Rosa Angriffsszenarios Mitte März 2001.
Die beiden tschechischen Kryptologen Vlastimil Klima und Tomas Rosa der zur ICZ Gruppe gehörenden Firma Decros hatten während einer Forschungsarbeit im Auftrag des tschechischen Geheimdienstes verschiedene Wege entdeckt, um den private key OpenPGP-kompatibler PGP-Programme (PGP, GnuPG) zu errechnen ohne Notwendigkeit, die Passphrase zu erraten oder den Algorithmus anzugreifen, mit denen der private key verschlüsselt wird.
Der Angriff wird durch fehlerhafte, bzw. fehlende Schutz- und Authentifizierungsmassnahmen im Schlüsselformat von (Open)PGP-Keys ermöglicht.

Im Klima-Rosa Szenario muss ein Angreifer physischen Zugriff auf den private key einer Zielperson in Form des privaten Schlüsselbundes, sprich sekring.skr bei PGP oder secring.gpg bei GnuPG, bzw. des exportierten private keys in Form einer Datei nehmen.
Der Angreifer führt einige wenige Modifikationen in den öffentlichen und geheimen Bestandteilen des Datenpakets aus, das den private key enthält und schiebt diese modifizierte Version der Zielperson unter.
Wenn die Zielperson das nächste Mal Signaturen mit dem modifizierten private key erstellt und der Angreifer im Besitz einer derart signierten Nachricht ist, kann der Angreifer mit einem Programm aus der Signatur den private key der Zielperson berechnen und anschliessend damit selbst authentische Signaturen im Namen der Zielperson erstellen.
Abschliessend speichert er die ursprüngliche Version des private keys am Ursprungsort zurück, um seinen Einsatz zu vertuschen.

Dazu NAI/PGP:

Am 20. März gaben zwei tschechische Kryptologen in einer Presseerklärung bekannt, daß sie eine Schwachstelle im openPGP-Standard gefunden hätten, der in PGP-Produkten und anderen Verschlüsselungsprodukten verwendet wird. Wir räumen ein, daß diese Schwachstelle zwar theoretisch besteht; unseren Anwendern sichern wir aber zu, daß zur Ausnutzung der Schwachstelle physischer Zugriff auf den Rechner und die Modifizierung von Dateien erforderlich ist. Grundlegende Voraussetzung für Sicherheit und Schutz der Privatsphäre ist die Kontrolle über den Rechner. Ist diese Mindestvoraussetzung erfüllt, werden Risiken auf ein Minimum reduziert. Selbst wenn die Schwachstelle ausgenutzt würde, so wäre davon nur die Signatur betroffen. Zugriffe auf verschlüsselte Daten sind auf keinen Fall möglich. Nach Meinung von Sicherheitsexperten ist das aus der Schwachstellen erwachsende Risiko als gering zu veranschlagen. Um aber auch dieses Risiko auszuschließen, wird PGP entsprechende Maßnahmen ergreifen, um die Schwachstelle in der ab Mitte des Jahres erhältlichen Version zu beseitigen.

Sandra L. Brooks
Direktor für Produktmarketing

Zusatz:
Es bleibt festzuhalten, dass der Klima-Rosa Angriff ein Angriff mit hohem Gefahrenpotential darstellt, aber den physischen Zugriff auf den private key voraussetzt.
Wie an diesem Ort schon früher ausgeführt, zählte zu einem verantwortungsvollen Einsatz von PGP schon immer der besondere Schutz des private keys.
Ausserdem stellt sich die Frage, ob ein Angreifer, dem möglich ist, auf den private key zuzugreifen, nicht sowieso weitergehende Überwachungs- und Spionagemethoden wie Key-Logger, Abhörwanzen, TEMPEST-Attacken u. ä. gegen die Zielperson fahren würde.

Siehe dazu als Beispiel KEY-LOGGER - die Wanzen im Rechner

Für PGP 2.6.3 IN und GnuPG sind gegen den Klima-Rosa Angriff gepatchte Versionen verfügbar.

Links:

Regeln für die PGP-Keys
  1. dass der Public Key ohne Bedenken weitergeben werden kann,
    der Private Key niemals
  2. dass eine starke Passphrase gewählt wird
  3. das die Passphrase niemals weitergegeben und/oder für andere Personen zugänglich aufbewahrt wird
  4. dass die Passphrase nie in Vergessenheit gerät

Mehr noch:
Der Private Key sollte möglichst sicher abgelegt sein.

Zum Beispiel kann man den Secring auf einer Diskette abspeichern und diese nur einlegen, wenn man PGP benutzen will. Dazu muss in PGP noch der Pfadhinweis zum Secring abgeändert werden.
Fallweise ist eine zusätzliche Sicherung des Secrings durch Verschlüsselung der Datei Secring.skr oder der gesamten Diskette durch ein anderes Verschlüsselungstool überlegenswert.
Geeignete und sichere Verschlüsselungstools auf DOS und Windowsebene finden sich auf der
No Big Brother Page - Kryptografische Programme.
Denn wenn jemand den Secret Key und die ihn schützende Passphrase des Keybesitzers kennen würde, könnte er alle an den Keybesitzer verschlüsselte E-Mails entschlüsseln !
Doch dazu später.
Siehe auch Die Sicherheit des geheimen Schlüssels von Ralf Senderek.

 

USB-Sticks als Speichermedium

Eine weitere, sehr interessante Lösung stellen USB-Plugins dar, weil USB mittlerweile zu den Standardschnittstellen der Motherboards zählen, die Handhabung sehr einfach ist, die Speicherung und Bearbeitung von Keymaterial schneller als auf Diskette von statten geht, das Medium stabiler als eine Diskette und besser zu transportieren ist.
Die Speichergrößen erlauben es auch, GnuPG und PGP (Anwendungen) mitzuspeichern.

Deshalb möchte ich exemplarisch drei Produkte vorstellen, die mir im Web aufgefallen sind:

Pen Drive

Pen Drive

  • erhältliche Kapazitäten von 4 MB, 128MB und 256MB (Stand Okt. 20001)
  • außer bei Windows 98 keine zusätzlichen Treiber
    Linux
  • unterstützt flash ROM (EEPROM) für ISP (In-System Programming) zum Update der Firmware über den USB Port
  • unterstützt Toshiba & Samsung NAND Flash Memory 32Mbit, 64Mbit, 128Mbit, 256Mbit, 512Mbit and 1Gbit.
  • unterstützt USB-Spezifikation 1.1
  • USB-Transferrate: bis zu 12Mbits/sec.
  • unterstützt Stromsparmodi
  • Schreibschutz

Links:

 

Voyager

Dicota Voyager

  • erhältliche Kapazitäten: 16 MB, 32 MB, 64 MB
  • Passwortschutz
  • Schreibschutz
  • Material: ASB
  • USB-Transferrate: bis zu 12Mbits/sec.
  • unterstützt USB-Spezifikation 1.1

Links:

Dicota Voyager Homepage

 

Flash USB-Drive

  • erhältliche Kapazitäten: 16MB, 32MB, 64MB, 128MB, 256MB
  • unterstützt USB-Spezifikation 1.1
  • Schreibschutz
  • EMI Compliance FCC, CE, EMI, EMS
  • Stromversorgung via USB-Bus (4.5V - 5.5V)

Links:

imafox Flash USB-Drive Homepage

Getestet habe ich den Voyager und den Pen Drive Stick.
Beide Sticks funktionierten bei mir unter W2K nach Installation der Treiber einwandfrei.
Beim Voyager wurde noch ein Passwort vergeben.
Wie versprochen, bringt beim Pen Drive W2K die Treiber bereits mit, so dass nur die W2K Installations-CD nötig war (nett war auch das beiliegende USB-Adapterkabel, das in den USB-Port meiner Tastatur eingesteckt, ein bequemes Andocken des USB-Sticks ermöglicht).
Das Pen Drive (in der Größe 32 MB) konnte ich sowohl mit FAT, als auch mit NTFS formatieren.
Nach Kopieren der Keyringe für GnuPG und CKT PGP auf die Sticks und Anpassen der Pfade in der Konfiguration von GnuPG und PGP habe ich nun ein sichere und mobiles Speichermedium für meine GnuPG/PGP-Daten. Nebenbei habe ich GnuPG und meine Password Safe Passwortdatenbank ebenfalls noch untergebracht.

PGP und sicheres Umfeld

Es ist sinnvoll, sich darüber hinaus weitergehende Überlegungen zur Sicherheit des Systems, auf dem PGP arbeitet, zu machen, d. h. für eine möglichst sichere Umgebung zu sorgen. Das trifft gerade für Windowssysteme zu. Denn es hilft nichts, PGP zu verwenden, aber z. B. die Möglichkeit zuzulassen, dass ein Hacker über das Internet in den eigenen PC einbricht, ein Remote Control Sever über ein "Trojanisches Pferd" Virus installiert oder die Passphraseeingabe durch anwesende Personen in der Umgebung vom Monitor abgelesen werden kann.
Neben der Verwendung eines starken Keys mit einem sicheren Algorithmus und einer starken Passphrase sollte man deshalb für einen starken Virenschutz sorgen, also z. B. alle Programme vor Installation mit einem Virenscanner überprüfen, den eigenen Rechner gegenüber dem Internet mit einem Firewall- und/oder Intrusion Detection Programm absichern und sensible Daten wie den Private Key und die Passphrase sicher "verwahren".
Sieht man einmal von einem TEMPEST-Angriff oder einem installierten Key-Logger System ab, gegen den ein normaler Anwender eh keine Chance hat, kann man so wenigstens die wichtigsten Angriffspunkte, die ein durchschnittlicher Angreifer wählen würde, neutralisieren.

Der Scarfo-Fall

Der bekannteste Fall des Jahres 1999, wo zum ersten Mal ein Software-Keylogger (als Bestandteil eines umfassenderen Keyloggersystems) eingesetzt wurde, war die Untersuchung des FBI gegen Nicodemo Scarfo, einem Angehörigen der Gambiano Mafiafamilie.
Das FBI war in das Büro von Scarfo eingebrochen und hatte die Festplatte seines Computers kopiert. Wichtige Daten hatte Scarfo aber mit PGP verschlüsselt.
Deshalb suchte das FBI, nur mit einem Durchsuchungsbefehl ausgestattet, das Büro nochmals auf und installierte im Computer das, was der Deputy Assistant Director der Investigative Technology Branch der FBI Laboratory Division, Randall S. Murch, in einer Gerichtsanhörung als "Key Logger System (KLS)" bezeichnete. Murch beschreibt das KLS so:

FBI engineers configured a hardware/software and/or firmware solution based upon previously developed techniques which would permit the FBI to obtain the defendant's key (den PGP Private Key) and key-related information (die Passphrase). These techniques, and their various components, have become to be known collectively within the FBI as the Key Logger System (KLS).
(...)
The KLS, depending upon the hardware and software configuration of a targeted computer and the use of that computer, can, and typically will, have multiple components.
(...)
A component of the KLS deployed in this case was a "keystroke capture" component that was designed to record, under certain conditions described below, each keystroke typed on the keyboard.
(...)
In conclusion, the KLS, by design, prohibited the capture of keyboard keystrokes whenever the computer modem was on; other component(s), described above, limited their capture to only the passphrase and key-related information.

Für Windows Systeme siehe auch die Win-Security Page und die No Big Brother Page No. 2.

Grafische Darstellung des Ver- und Entschlüsselungsvorgangs
beim asymmetrischen Verfahren mit PGP:

Verschlüsselung durch den Absender:

Verschlüsselung

 

Entschlüsselung durch den Empfänger:

Entschlüsselung

 

Wie aus den Abbildungen hervorgeht, kommt beim asymmetrischen Verschlüsselungsverfahren auf Seiten des Absenders der öffentliche RSA oder DH Schlüssel (Public Key) des Empfängers, der weltweit jeder Person, die PGP einsetzt, zur Verfügung steht und ein konventioneller Verschlüsselungsalgorithmus wie IDEA, CAST oder Triple-DES zum Einsatz, aber kein Passwort oder eine Passphrase.
Auf Seiten des Empfängers kommt der private Schlüssel (Private Key) des Empfängers, der nur ihm vorliegt und sonst keiner anderen Person, seine Passphrase und einer der konventionellen Verschlüsselungsalgorithmen zum Einsatz.

 

Grafische Darstellung des Ver- und Entschlüsselungsvorgangs
beim symmetrischen Verfahren

symmetrisches Verfahren

Wie aus der Abbildung hervorgeht, wird beim symmetrischen Verschlüsselungsverfahren der Absender den Klartext, z. B. eine E-Mail, mit einem IDEA, CAST oder Triple-DES Schlüssel verschlüsseln, wobei der Schlüssel durch eine Passphrase, die sich der Absender ausdenkt, verschlüsselt, bzw. geschützt wird. Der Empfänger wiederum muss die gleiche Passphrase angeben, damit der gleiche Schlüssel, der auf Seiten des Absenders noch zur Verschlüsselung eingesetzt wurde, als Entschlüsselungsschlüssel den verschlüsselten Text in Klartext entschlüsselt.
Damit der Empfänger aber überhaupt den Entschlüsselungsvorgang starten kann, muss ihm zuvor durch den Absender die Passphrase über einen abhör- und abfangsicheren Kanal (z. B. persönliches Treffen, abhörsichere Telefonleitung) zugegangen sein.
Wenn aber ein sicherer Kanal die Vorbedingung ist, bzw. existiert, kann der Absender auch gleich den Klartext über diesen sicheren Kanal an den Empfänger weitergeben, ohne eine Verschlüsselung einsetzen zu müssen.
Der Vorteil beim asymmetrischen Verfahren besteht also gerade darin, dass dieser sichere Kanal nicht vorliegen muss, um Texte abhör- und abfangsicher über grosse Entfernungen austauschen zu können, da auch der Austausch einer Passphrase keine Vorbedingung darstellt.

Aus diesem Grund ist das symmetrische Verfahren nur sinnvoll, wenn es entweder von ein und derselben Person verwendet wird, z. B. vom Anwender, der seine Dateien auf der eigenen Festplatte verschlüsseln möchte (so wird das symmetrische Verfahren von PGP und PGPdisk zur Verschlüsselung lokaler Daten angewendet) oder in einem Umfeld, wo Daten für zwei Personen verfügbar vorliegen sollen, aber keiner dritten Person und diese zwei Personen die Möglichkeit haben, die gemeinsame Passphrase persönlich auszutauschen, z. B. zwei Kollegen, die ein gemeinsames Projekt in einer Firma bearbeiten.

Wer sich einen näheren Überblick zu kryptografischen Verfahren und Begriffen verschaffen möchte, sollte sich die (englischsprachige) FAQs About Today's Cryptography? der RSA Labors besorgen.

Zu beachten ist auch, dass sich das Dateiformat des Pub- und Secrings von PGP 6 von dem Dateiformat von PGP 2.6.3 unterscheidet. Deshalb sollte man darauf achten, dass ein Zugriff einer PGP Version auf die falsche Datei ausgeschlossen ist und es nicht zu einer versehentlichen Umbenennung oder Löschung einer Pub- oder Secring Datei kommt, wenn sich die Dateien beider Versionen im gleichen Verzeichnis befinden oder bei beiden Versionen der gleiche Zugriffspfad angegeben ist.
Veränderungen an den Public- und Private Keys, die in einer PGP-Version durchgeführt werden, sollten analog in der anderen PGP-Version wiederholt werden.
Auf diesem Wege können Fehlermeldungen, die beim Ent- und Verschlüsseln auftreten und fälschlicherweise einer Inkompatibilität oder Keyfälschung zugeschrieben werden, im Vorfeld verhindert werden.