![[*]](/icons/footnote.png){kind=icon}
. Wir bezeichnen das
Format nach RfC1991 als "altes Format" und RfC2440 (genauer: die
dort als V4 bezeichnete Version eines Schlüsselzertifikats) als
"neues Format". Private Schlüssel haben ein eigenes Format für
Zertifikate, das sich vom Format für öffentliche Schlüssel aber kaum
unterscheidet und nur sehr selten gebraucht wird (private Schlüssel
werden nicht so oft weitergegeben wie öffentliche...),
weswegen wir es hier nicht näher betrachten werden.
Ein Zertifikat enthält zunächst einmal natürlich den öffentlichen
Schlüssel selbst; dieser Eintrag besteht aus mehreren langen Zahlen.
Genaueres zu diesen Zahlen finden Sie in der Beschreibung der
jeweiligen Algorithmen. Hinzu kommt ein Texteintrag, der angibt, wem
dieser Schlüssel gehört. Im alten Datenformat ist hierfür ein
einzelnes Textfeld vorgesehen, innerhalb dieses Feldes sollten Sie aus
Portabilitätsgründen nur ASCII verwenden, also z.B. keine Umlaute.
Im neuen Datenformat hingegen können Sie (prinzipiell) im Namen
beliebige (Unicode-)Zeichen verwenden.
Im neuen Datenformat haben Sie die Möglichkeit, innerhalb eines Zertifikates mehrere Schlüssel (mit einer gemeinsamen User-Kennung) zu haben. Es ist beispielsweise sinnvoll, einen lange gültigen Schlüssel zu verwenden, um andere Schlüssel zu unterschreiben (Master-Key) und Schlüssel mit kürzerer Gültigkeitsdauer für die Verschlüsselung von Nachrichten an Sie oder für digitale Unterschriften unter Texte und Dateien. Sie können natürlich auch verschiedene Schlüssel für verschiedene Einsatzmöglichkeiten verwenden. Beispielsweise ist es sinnvoll, einen anderen Schlüssel für Firmenpost zu verwenden als für private Mails - den Firmenschlüssel können Sie dann auch einer Urlaubs- oder Krankheitsvertretung geben, wenn es nötig wird, ohne daß diese gleich Ihre private Post lesen kann. Über diese Möglichkeit ist auch realisiert, daß jetzt verschiedene Algorithmen (und damit auch zwangsweise verschiedene Schlüssel) für Unterschriften und Verschlüsselung verwendet werden können, beispielsweise die Mischung DSA/ElGamal.
PGP 2.6.x verwendet die letzten 64 Bit des Schlüssels, von denen nur die letzten 32
Bit angezeigt werden, z.B. 0x6ce93239. Mit ein wenig
Mathematik ist es ohne nennenswerten Aufwand möglich, zu einer
gegebenen Schlüssel-ID (deren letzte Ziffer ungerade ist) einen
funktionsfähigen Schlüssel zu erzeugen, die ID hat von daher keinerlei
Bedeutung als Sicherheitsmerkmal. (Die Version 2.6.3in hat übrigens
auch eine Option, mit der sich derartige Schlüssel erzeugen lassen.
Von der Verwendung ist abzuraten. Das Einlesen derartiger Schlüssel
kann die Schlüsselverwaltung anderer PGP-Versionen
durcheinanderbringen - die ID wird verwendet, um auf einen Schlüssel
zuzugreifen.) Nachfolgende Versionen (PGP 5.x/6.x, OpenPGP, GnuPG)
verwenden daher als Schlüsselkennung den Fingerabdruck des Schlüssels
(näheres zum Begriff des Fingerabdrucks finden Sie im
Abschnitt 4.6).
GnuPG arbeitet mit einer externen Quelle für alle benötigten Zufallszahlen, da es hauptsächlich für Systeme konzipiert ist, die eine derartige Quelle bereits zur Verfügung stellen. Linux und FreeBSD erzeugen aus "Umgebungslärm" wie zum Beispiel minimalen Schwankungen in Festplattengeschwindigkeiten, Mausbewegungen und präzisen Zeitmessungen von Tastatureingaben zuverlässige Zufallszahlen. Übrigens basiert die Implementation der Linux-Zufallszahlen-Quelle /dev/random ursprünglich auf PGP-Code. Für den Einsatz unter Windows verwendet GnuPG eine mitgelieferte DLL, die entropy.dll, die im Wesentlichen dasselbe leistet. Für den Einsatz auf Unix-Versionen ohne /dev/random oder etwas vergleichbares bietet sich der Einsatz eines Perl-Daemons namens "entropy gathering daemon" an. Auch dieses Programm sammelt Umgebungslärm, um ihn Programmen bei Bedarf als zuverlässige Zufallszahlen zur Verfügung zu stellen.
PGP verwendet einen kryptographisch zuverlässigen Pseudozufallszahlengenerator, um wechselnde Einmal-Schlüssel für die konventionelle Verschlüsselung einzelner Dateien zu erzeugen. Die Datei, die den Startwert für den Zufallszahlengenerator enthält, heißt (in der Standardeinstellung, von der wir im weiteren ausgehen) randseed.bin. Sie sollte ebenso wie die anderen von PGP benötigten Dateien in dem Verzeichnis stehen, das durch die Umgebungsvariable PGPPATH angegeben wird. Falls die Datei nicht vorhanden ist, wird sie automatisch erzeugt. Sie erhält einen Startwert aus echten Zufallszahlen, die aus dem zeitlichen Abstand von Tastatureingaben u.ä. abgeleitet werden. In die Datei randseed.bin werden bei jedem Aufruf des Zufallszahlengenerators neue Daten geschrieben, unter Einbeziehung der aktuellen Uhrzeit in Millisekunden und anderer echter Zufallsdaten.
Die Datei randseed.bin sollte wenigstens etwas geschützt sein, um das Risiko klein zu halten, daß ein Angreifer die nächsten Schlüssel, die PGP generieren wird, oder die letzten Schlüssel, die PGP generiert hat, berechnet. Dieser Angreifer hätte Schwerstarbeit zu erledigen, weil PGP die Datei randseed.bin vor und nach jeder Benutzung kryptographisch "in die Mangel nimmt". Trotzdem ist es keine unangebrachte Vorsicht, darauf zu achten, daß die Datei nicht in die falschen Hände gerät.
Leser, denen diese algorithmisch abgeleiteten Zufallszahlen unheimlich sind, sollten nicht vergessen, daß sie der Sicherheit derselben konventionellen Verschlüsselungsalgorithmen vertrauen, um Nachrichten zu verschlüsseln. Wenn der Algorithmus für die Verschlüsselung sicher genug ist, sollte er hinreichend zuverlässig sein, um Zufallszahlen zu erzeugen, die den konventionellen Schlüssel bilden. Zu beachten ist noch, daß PGP zur Erzeugung eines Paares von öffentlichem und geheimem Schlüssel, die über längere Zeit sicher sein sollen, echte Zufallszahlen verwendet, die im wesentlichen aus den Zeitabständen von Tastatureingaben abgeleitet werden.
Die Erzeugung von Pseudozufallszahlen, also von Zahlenfolgen, die zwar
"zufällig aussehen", die aber aus einem Algorithmus abgeleitet
werden, ist eine schwierige Aufgabe. Wegen der "guten
Zufallsqualität" wird auch bei Anwendungen, die nichts mit
Verschlüsselung zu tun haben, wie Statistik oder numerischer
Mathematik, gerne ein Verschlüsselungsalgorithmus verwendet, um
"Zufallszahlen" zu erzeugen. Die Probleme bei Verschlüsselung und bei der
Erzeugung von Zufallszahlen sind ähnlich: In beiden Fällen geht es
darum, Bitfolgen zu erzeugen, die möglichst wenig Systematik zeigen.
Bei der Verschlüsselung sind diese Bitfolgen der verschlüsselte Text,
bei der Erzeugung von Zufallszahlen sind die Bitfolgen eben die
Zufallszahlen. Leser, denen die Verwendung der Datei
randseed.bin trotz dieser Argumente unheimlich bleibt, können
sie immer noch vor jedem Start von PGP einfach löschen. Allerdings
müssen sie dann für die Verschlüsselung eines Klartextes jedesmal
ungefähr 90 Tastendrücke für die Erzeugung einer echten Zufallszahl
ausführen. Hierbei sammelt PGP deutlich mehr Informationen als
benötigt und speichert das "mehr" in der randseed.bin.
Normalerweise sind neue Tastatureingaben nur nötig, wenn PGP die
Zufallsinformationen in der randseed.bin "aufgebraucht"
hat.
Eine Kleinigkeit ist zu den von PGP verwendeten Zufallszahlen noch
anzumerken: Seit der Version 5.0 werden Nachrichten, die aufgrund
ihrer Größe in mehrere Teile geteilt werden (vgl. Abschnitt
ARMORLINES in 14 auf
Seite ![[*]](/icons/crossref.png){kind=icon}
), mit einer Seriennummer versehen,
um sicherzustellen, daß die zusammengefügten Teile beim Empfänger auch
alle Teile derselben Nachricht und in der richtigen Reihenfolge sind.
Bei PGP 5.0 war dieses Feature ein wenig unüberlegt implementiert
worden, dort wurde diese Seriennummer aus demselben Pool für
Zufallszahlen gewonnen wie die Einmal-Schlüssel. Somit besteht ein -
wenn auch unscheinbarer - Zusammenhang zwischen der für jedermann
sichtbaren Seriennummer und dem geheimen Einmal-Schlüssel. Das Ganze
ist kein besonders großes Sicherheitsloch (niemand hat eine Methode
beschrieben, um es auszunutzen), zeigt aber, daß auch Firmen und
Personen mit einem guten Hintergrund in Verschlüsselungstechnik nicht
vor versehentlich eingebauten subtilen Schwachstellen gefeit sind.
Stunden, was
etwa 4*1018 Jahren entspricht. Zum Vergleich: Das Alter des
Weltalls wird derzeit auf etwa 1.5*109 Jahre
geschätzt, also etwa ein Milliardstel der Zeit, um mit aktueller,
speziell optimierter Hardware eine 128 Bit-Verschlüsselung zu brechen.
Auch wenn wir eine nochmals deutlich schnellere Entwicklung der
Rechner annehmen als bislang geschehen, wird von uns niemand mehr
erleben, daß es Hardware nach bisheriger Technologie gibt, die alle
möglichen IDEA-Schlüssel ausprobieren kann. Quantencomputer
sind ein ganz anderes Thema, aber die müßten erst einmal mehr als fünf
bis zehn Bit Rechenleistung aufbringen...
Im Vergleich mit DES steht IDEA von der Sicht des Anwenders her gut da: Es verwendet längere Schlüssel als DES und ist trotzdem deutlich schneller (DES ist ein Hardware-Standard, IDEA ist auf Software optimiert). Nachteile von IDEA sind, daß es patentiert ist und die Verwendung außer im rein privaten Bereich Lizenzgebühren kostet, und zwar auch in Europa (die Gebühren sind aber sehr niedrig, näheres erfahren Sie bei der Firma Ascom Tech, http://www.ascom.ch) und daß IDEA nicht wie DES für sich beanspruchen kann, der mit Abstand am besten analysierte Verschlüsselungsalgorithmus in der öffentlich zugänglichen Literatur zu sein. Aber IDEA hat durchaus auch eine längere Liste von Artikeln über gescheiterte Angriffe vorzuweisen. Bis heute hat IDEA kryptanalytischen Angriffen wesentlich besser standgehalten als andere Verfahren wie FEAL, REDOC-II, LOKI, Snefru und Khafre. IDEA widersteht dem sehr erfolgreichen differentiellen kryptanalytischen Angriff von Biham und Shamir wesentlich besser als DES. Biham und Shamir untersuchten IDEA erfolglos auf Schwachstellen. Akademische Arbeitsgruppen von Kryptanalytikern aus Belgien, England und Deutschland suchen Angriffsmöglichkeiten bei IDEA, ebenso militärische Geheimdienste mehrerer europäischer Länder. (Letztere veröffentlichen ihre Ergebnisse normalerweise natürlich nicht.) Je mehr und je länger dieser Algorithmus Angriffsversuche aus den gefürchtetsten Arbeitsgruppen der kryptanalytischen Welt auf sich zieht, desto mehr steigt das Vertrauen in ihn.
Ein paar sehr technische Randbemerkungen: Ähnlich wie DES kann IDEA für Cipher Feedback (CFB, Rückführung der verschlüsselten Textes) und für Cipher Block Chaining (CBC, Verkettung von Blöcken verschlüsselten Textes) verwendet werden. Bei PGP wird IDEA mit 64-Bit CFB verwendet. Wenn Ihnen die Unterschiede zwischen ECB, CFB und CBC nichts sagen, ist das nicht wirklich tragisch, solange Sie nicht versuchen, Kryptographie zu implementieren. Für die wirklich Interessierten hier eine kurze Erläuterung: Im einfachsten Betriebsmodus, Electronic Codebook (ECB), wird derselbe Klartextblock immer auf denselben Output abgebildet. Das hat die gravierenden Nachteile, daß dieser Klartextblock erstens wiedererkannt werden kann und es zweitens möglich ist, Nachrichten zu verändern, ohne die Verschlüsselung umgehen zu müssen. CBC und CFB umgehen diese Probleme dadurch, daß der Klartext vor der Verschlüsselung mit dem vorherigen verschlüsselten Block verknüpft wird, also die Verschlüsselung sowohl vom Klartextblock als auch der Nachricht vor diesem Block abhängt. Auch die anderen symmetrischen Verfahren in den neueren PGP-Versionen (in OpenPGP sind 3DES, IDEA, CAST5 und Blowfish definiert) verwenden CFB. Exemplarisch für die Funktionsweise eines Blockchiffre finden Sie eine detaillierte Beschreibung des IDEA-Algorithmus im Anhang E.1.
Ein paar technische Details zu 3DES: Es handelt sich um einen symmetrischen Algorithmus, der Blöcke von 64 Bit unter Verwendung eines 112 Bit langen Schlüssels in Blöcke von wiederum 64 Bit abbildet. 3DES ist ein sogenanntes Feistel-Netzwerk. Für uns ist die wichtigste Eigenschaft dieser Gruppe von Verschlüsselungsalgorithmen, daß die Entschlüsselung - ebenso wie bei IDEA - mit demselben Algorithmus geschehen kann, indem die intern generierten Teilschlüssel in umgekehrter Reihenfolge verwendet werden. 3DES kann in allen Block-Chiffre-Modi verwendet werden, PGP verwendet den CFB-Modus.
Die Argumente, die gegen die Verwendung von DES sprechen, beziehen sich meistens auf die Schlüssellänge, was mit 3DES kein nennenswertes Problem mehr darstellt, oder sind eher gefühlsmäßig begründet - viele Designentscheidungen, die in die Entwicklung des Algorithmus eingeflossen sind, sind bis heute nicht erklärt worden und viele Menschen sind nach wie vor davon überzeugt, daß die NSA in der Entwicklung ihre Finger drin hatte und den Algorithmus auf eine ausgeklügelte Art und Weise mit einer Hintertür versehen hat. Fünfzehn Jahre intensiven Studiums durch brillante Wissenschaftler und Horden von Hobby-Kryptographen haben keine Anzeichen für eine Hintertür entdecken können, aber das mulmige Gefühl ob der unverstandenen Teile bleibt dennoch bestehen.
Vom pragmatischen Standpunkt aus ist das einzige gute und begründete Argument, das gegen die Verwendung von 3DES spricht, die niedrige Geschwindigkeit. Wie im vorigen Kapitel bereits erwähnt, ist DES in Software deutlich langsamer als IDEA, und einen Block dreimal zu verschlüsseln, trägt auch nicht gerade zu einer Steigerung der Geschwindigkeit bei. Auf der Haben-Seite ist zu 3DES zu sagen, daß es die (auf der Anzahl der gescheiterten Angriffe basierenden) Vertrauenswürdigkeit von DES übernimmt, dabei aber (nach derzeitigem Kenntnisstand) den größten Nachteil von DES, die kurze Schlüssellänge, vermeidet. Gegenüber IDEA hat 3DES den großen Vorzug, frei von Lizenzgebühren verwendet werden zu können.
RSA läßt sich mit denselben Schlüsseln sowohl für Verschlüsselung als auch für elektronische Unterschriften einsetzen und kann auch über elliptischen Kurven eingesetzt werden. Nach Meinung der Befürworter dieser Vorgehensweise erhöht sich die Sicherheit bei gleicher Schlüssellänge beträchtlich. Konservativere Stimmen halten dagegen, daß elliptische Kurven erst wesentlich kürzer untersucht werden als die üblichen Strukturen bei RSA und ElGamal und elliptische Kurven nur dort eingesetzt werden sollten, wo der Platz wirklich knapp ist, beispielsweise bei Chipkarten. RSA ist das bekannteste und am besten untersuchte asymmetrische Verfahren. Der größte Nachteil von RSA ist es, daß es in den USA patentiert ist und seine Verwendung dort deshalb entweder Lizenzgebühren kostet oder (und das nur im nichtkommerziellen Einsatz) eine bestimmte Implementierung namens RSAREF verwendet werden muß, die nur beschränkt lange Schlüssel verwenden kann. Das RSA-Patent in den USA wird am 20. September 2000 auslaufen.
Das Verfahren ist nicht patentiert. Eine Firma namens PKP war der Ansicht, es falle unter das Patent für Diffie-Hellman (auf das sie die Verwertungsrechte hatten). Da jenes Patent 1997 ausgelaufen ist, ist die Frage kaum noch von Interesse.
Das stimmt nicht. Ein asymmetrisches Verfahren kann durch zu kurze
oder auch "weiche" Schlüssel leicht angreifbar werden, andererseits können konventionelle Verschlüsselungen
bei Wahl eines guten Algorithmus sehr sicher sein. In den meisten Fällen ist es schwierig, genau zu sagen,
wie gut eine konventionelle Verschlüsselung ist, ohne sie wirklich zu
knacken. (Dann ist es natürlich leicht zu sagen "höchstens so und so
gut".) Ein guter konventioneller Algorithmus kann durchaus
schwerer zu knacken sein als ein RSA-Schlüssel der Größenordnung, die
PGP als "militärischen Standard" bezeichnet. Der Reiz einer
Verschlüsselung mit öffentlichen Schlüsseln besteht nicht darin, daß
sie aus sich heraus sicherer als eine konventionelle Verschlüsselung
ist - ihr Vorteil besteht in der wesentlich bequemeren und
vielseitigeren Handhabung der Schlüssel.
Leute, die beruflich mit der Erforschung von Faktorisierungsalgorithmen zu tun haben, sagen, daß ein Durchprobieren der 2128 möglichen Schlüssel für IDEA vom Rechenaufwand her der Faktorisierung eines RSA-Schlüssels mit 3100 Bit entspreche. Das ist deutlich mehr als die 1024 Bit, die die in der US-Version von PGP 2.6 verwendeten RSAREF-Routinen zulassen und auch deutlich mehr, als vom Standpunkt der Geschwindigkeit her sinnvoll ist. Wenn wir annehmen, daß IDEA keine besonderen Schwachstellen enthält, ist der Schwachpunkt, an dem ein kryptanalytischer Angriff ansetzen würde, RSA und nicht IDEA. (Der RSA-Schlüssel ist auch insofern "wertvoller", als daß er über einen viel längeren Zeitraum verwendet wird als der IDEA-Schlüssel einer einzelnen Nachricht.) Außerdem kann es bei der Verwendung eines reinen RSA-Algorithmus zusätzliche Konstellationen geben, die Ansatzpunkte für einen Angriff ergeben. Fachleute schätzen, daß ElGamal und DSS-Signaturen (die "neuen Schlüssel" ab PGP 5.0) bei gleicher Schlüssellänge noch sicherer sind als RSA.
Dateien, die für eine Kompression zu klein sind, oder die sich nicht gut komprimieren lassen, werden von PGP unkomprimiert gespeichert. Bei Bedarf läßt sich auch bzip2, PKzip, rar oder ein anderes Datenkomprimierungsprogramm verwenden, um den Klartext vor der Verschlüsselung zu komprimieren. PKzip ist ein weit verbreitetes und effizient arbeitendes Kompressionsprogramm von PKWare Inc. für MS-DOS, das als Shareware vertrieben wird. Sie können auch zip benutzen, ein PKzip-kompatibles Freeware-Programm für Unix und andere Betriebssysteme von Jean-Loup Gailly. Natürlich gibt es auch PKzip-kompatible Programme mit Windows-Oberflächen, beispielsweise WinZip. Die Verwendung von PKzip/zip, tar oder rar hat unter Umständen Vorteile gegenüber der internen Kompression PGPs, weil diese Programme im Gegensatz zu PGP in der Lage sind, mehrere Dateien in einer einzigen komprimierten Datei zusammenzufassen. Bei der Dekompression werden natürlich wieder die einzelnen Originaldateien erzeugt. Die Verwendung von bzip2 macht vor allem dann Sinn, wenn die Datenmengen wirklich groß werden, da die Kompression in der Regel deutlich besser ist als bei den anderen genannten Verfahren. Auf der beiliegenden CD finden Sie im Verzeichnis Tools eine Auswahl verschiedener Packprogramme.
PGP versucht nicht, eine bereits komprimiert vorliegende Klartext-Datei erneut zu komprimieren. Die Empfängerin einer so komprimierten Datei muß sie nach der Entschlüsselung dekomprimieren. Wenn der entschlüsselte Klartext eine komprimierte Datei in einem der Standardformate ist, erkennt PGP dies automatisch und weist den Empfänger darauf hin, daß es sich wahrscheinlich um eine derartige Datei handelt. PGP 2.6.3i setzt auch gleich eine entsprechende Dateinamenserweiterung, so daß auch Systeme, die den Typ einer Datei an der Endung erkennen wollen wie z.B. Windows, damit weiterarbeiten können.
Für die technisch interessierten Leserinnen sei noch erwähnt, daß die aktuelle Version von PGP die Freeware-Kompressions-Routinen enthält, die Jean-Loup Gailly, Mark Adler und Richard B. Wales geschrieben haben. Diese ZIP-Routinen verwenden Algorithmen, die funktionsäquivalent zu denjenigen von PKzip 2.0 von PKWare sind. Sie wurden im wesentlichen deshalb in PGP eingebaut, weil sie als gut portierbarer C-Quellcode patentfrei zur Verfügung stehen, weil sie wirklich gut komprimieren und weil sie schnell sind.
Um eine digitale Unterschrift zu erzeugen, verwendet PGP den geheimen
Signaturschlüssel, jedoch nicht für die "Codierung" des gesamten
Textes. Das würde zuviel Rechenzeit kosten. Statt dessen
verwendet PGP eine "Textprüfsumme" und codiert diese mit dem
geheimen Schlüssel.
Diese Textprüfsumme ist ein kleines, 128 oder 160 Bit langes
"Destillat" einer Nachricht, von der Idee her ähnlich einer
Quersumme oder einer CRC-Summe, falls Ihnen das etwas
sagt. Man kann sich die Textprüfsumme auch als eine Art Fingerabdruck
der Nachricht vorstellen. Die Textprüfsumme
"repräsentiert" die Nachricht in dem Sinne, daß sich bei (praktisch)
jeder Änderung an der Nachricht eine andere Textprüfsumme für die
Nachricht ergibt. An der Textprüfsumme läßt sich also zuverlässig
erkennen, ob sich ein Fälscher an der Nachricht zu schaffen
gemacht hat. Die Textprüfsumme wird durch eine kryptographisch
zuverlässige "Einweg-Hash-Funktion" (engl. to hash =
zerhacken) berechnet. Ein Fälscher kann wegen des immensen
erforderlichen Rechenaufwands keine zweite Nachricht produzieren, die
dieselbe Textprüfsumme wie die Originalnachricht hat. In dieser
Hinsicht ist das bei PGP verwendete Verfahren zur Berechnung der
Textprüfsumme wesentlich besser als die üblichen Quersummen oder
CRC-Summen, bei denen es einfach ist, zu einer gegebenen Nachricht
eine zweite Nachricht zu finden, die die identische Quer- oder
CRC-Summe hat. Andererseits kann aus der Textprüfsumme ebensowenig
wie aus einer Quer- oder CRC-Summe die Originalnachricht berechnet
werden. Die Länge der Prüfsumme in Bits (128 oder 160) ist
entscheidend für den Rechenaufwand, den ein Angreifer betreiben müßte,
um zwei Nachrichten mit derselben Prüfsumme oder (was sehr viel
aufwendiger ist) eine (zweite) Nachricht zu einer gegebenen Prüfsumme
zu finden.
Die Textprüfsumme alleine reicht nicht aus, um die Echtheit einer Nachricht zu kontrollieren. Der Algorithmus für ihre Berechnung ist allgemein bekannt, und er verwendet keinen geheimen Schlüssel. Wenn man die Textprüfsumme einfach so zur Nachricht hinzufügte, könnte ein Fälscher die Nachricht ändern und die Prüfsumme für die geänderte Nachricht neu berechnen. Für eine zuverlässige Kontrolle der Echtheit einer Nachricht muß die Absenderin die Prüfsumme mit ihrem geheimen Schlüssel codieren. Erst hierdurch entsteht eine authentische Unterschrift.
Die Textprüfsumme wird von dem PGP-Programm der Absenderin einer Nachricht berechnet. Die digitale Unterschrift entsteht dadurch, daß die Absenderin die Textprüfsumme und die Zeitmarke mit ihrem geheimen Signaturschlüssel codiert. Die Absenderin verschickt Nachricht und digitale Unterschrift an den Empfänger. Dessen PGP-Programm erhält die für die Unterschrift verwendete Textprüfsumme, indem es die digitale Unterschrift mit dem öffentlichen Signaturschlüssel der Absenderin decodiert. Zur Kontrolle wird die Textprüfsumme aus der erhaltenen Nachricht berechnet. Wenn die aus der Nachricht berechnete Textprüfsumme und die in der Unterschrift enthaltene Prüfsumme übereinstimmen, ist gewährleistet, daß die Nachricht nicht geändert wurde und daß sie von derjenigen Person stammt, deren öffentlicher Schlüssel für die Kontrolle der Unterschrift verwendet wurde. Bei Verwendung von RSA werden hierbei i.A. dieselben geheimen und öffentlichen Schlüssel wie bei der Verschlüsselung von Nachrichten verwendet, bei ElGamal/DSS-Schlüsseln sind die Schlüssel zum Verschlüsseln und die Schlüssel zum Unterschreiben voneinander unabhängig.
Ein Fälscher müßte die Nachricht entweder so ändern, daß die Textprüfsumme gleich bleibt, was praktisch ausgeschlossen ist, oder er müßte mit der geänderten Textprüfsumme eine neue digitale Unterschrift erzeugen, was ohne den geheimen Schlüssel der Absenderin auch praktisch nicht möglich ist.
Eine digitale Unterschrift beweist, wer eine Nachricht abgeschickt hat, und ob die Nachricht geändert wurde, sei es aufgrund eines technischen Fehlers oder absichtlich. Ebenso verhindert sie, daß ein Absender die Unterschrift unter einer Nachricht leugnen kann.
Bei Verwendung von ElGamal/DSS ist die Verwendung zweier voneinander unabhängiger Schlüssel für Unterschriften und Verschlüsselungen verfahrensbedingt, da DSS nicht für die Verschlüsselung geeignet ist und nicht jeder ElGamal-Schlüssel für Unterschriften eingesetzt werden kann. Diese Trennung ist auch bei Verwendung von RSA-Schlüsseln durchaus sinnvoll, insbesondere, da Schlüssel bei jedem Verschlüsselungssystem in regelmäßigen Abständen gewechselt werden sollten. Es ist sinnvoll, den für Verschlüsselung eingesetzten Schlüssel häufiger zu wechseln als den für Unterschriften eingesetzten, da letzterer die Unterschriften anderer Benutzer trägt. Die Version 2.6.3in unterstützt dies explizit, bei anderen Versionen der 2.6-Reihe erfordert es Mitarbeit des Benutzers, so etwas zu tun. Im neuen Datenformat (PGP 5.x/6.x, OpenPGP) ist es auch möglich, eine ganze Hierarchie von "Teilschlüsseln" mit unterschiedlicher Bedeutung (angegeben durch Kommentare und Benutzungshinweise wie "nur zur Verschlüsselung") und Gültigkeitsdauern als einen Schlüssel anzusehen - dann sollte einer der Schlüssel nur dafür verwendet werden, die anderen Schlüssel zu signieren, und dieser Schlüssel sollte dann die Unterschriften von anderen Personen bekommen.
Die Verwendung der Textprüfsumme für die digitale Unterschrift hat neben der Geschwindigkeit noch weitere Vorteile im Vergleich zur Codierung der gesamten Nachricht mit dem geheimen Schlüssel. Die Unterschriften haben alle die gleiche geringe Länge, unabhängig von der Größe der jeweiligen Nachricht. Sie ermöglichen der Software eine automatische Kontrolle der Korrektheit einer Nachricht, ähnlich wie Quer- oder CRC-Summen. Die Unterschrift kann getrennt von der Nachricht gespeichert werden, bei Bedarf sogar in einem öffentlich zugänglichen Archiv, ohne daß vertrauliche Informationen aus der Nachricht offengelegt werden, weil es unmöglich ist, aus der Kenntnis der Textprüfsumme irgend etwas über den Inhalt der Nachricht zu ermitteln. Darauf basierend, können Sie die Prüfsumme oder auch eine abgetrennte PGP-Unterschrift veröffentlichen, ohne die betreffende Nachricht selbst aus der Hand geben zu müssen. Das kann beispielsweise für Vorhersagen Sinn machen, für Nachrichten oder Pressemitteilungen, aber auch bei Nachrichten, die nie veröffentlicht werden sollen, wie Verträgen, kann es beruhigend sein, zu wissen, daß an einer öffentlichen Stelle genug über den Text dokumentiert ist, damit er nicht manipuliert werden kann. Eine gute öffentliche Stelle für so etwas ist Lutz Donnerhackes "ewiges Logfile" unter http://www.iks-jena.de/mitarb/lutz/logfile/.
Die bei PGP verwendeten Algorithmen für die Berechnung der Textprüfsumme sind MD5 (Message Digest 5), von der RSA Data Security Inc. für Public Domain Verwendung freigegeben, sowie SHA1 aus dem "digital signature standard" (DSS). Inzwischen sind Angriffe auf MD5 gefunden und publiziert worden, die MD5 zwar noch nicht brechen können, es aber ratsam erscheinen lassen, von diesem Algorithmus wegzumigrieren. Er wird noch unterstützt, um Kompatibilität zu älteren PGP-Implementierungen zu bieten.