Wie PGP entstand, warum es gerichtsfest gebaut wurde und was wir 35 Jahre später daraus lernen können

Auf einen Blick
Worum es geht. Phil Zimmermann hat 1991 ein Verschlüsselungsprogramm geschrieben und es ins Internet gestellt. Die US-Regierung hat ihn drei Jahre lang strafrechtlich verfolgt wegen unerlaubten Munitions-Exports. Sein Werkzeug heißt PGP. Es funktioniert heute noch.
Was du mitnimmst.
- Wie asymmetrische Verschlüsselung im Kern funktioniert ohne Mathematik, mit einer Briefkasten-Metapher.
- Warum starke Verschlüsselung in den USA bis 1999 als Waffe galt und welchen juristischen Trick Zimmermann genutzt hat, um diesen Status zu unterlaufen.
- Was PGP gut macht, wo seine Grenzen liegen, und warum die Geschichte dieses Werkzeugs uns mehr über Architektur lehrt als die Werkzeuge selbst.
Zeit bis zur ersten umsetzbaren Erkenntnis: 5 Minuten.
Eine Erinnerung aus dem Jahr 1993
Ich erinnere mich noch an den Moment, an dem die Geschichte zum ersten Mal die deutsche Fachpresse erreichte.
Es muss 1993 gewesen sein. Ich war 33, saß in einem Großraumbüro in Düsseldorf, programmierte Mainframe-Backends in COBOL, mit Java hatte ich noch nichts zu tun, das gab es noch nicht. In der c’t oder iX ich weiß nicht mehr genau stand eine kleine Meldung. Drei, vier Absätze. Ein amerikanischer Programmierer wird strafrechtlich verfolgt. Wegen unerlaubten Munitions-Exports.
Munition.
Ich habe die Meldung zweimal gelesen, weil ich dachte, ich hätte mich verlesen. Aber da stand es: das Bundeskriminalamt der USA, in Zusammenarbeit mit dem Zoll, ermittelt gegen Philip Zimmermann wegen Verstoßes gegen die International Traffic in Arms Regulations. Das ist das Gesetz, das den Export von Panzern, U-Booten und Kampfflugzeugen regelt. Zimmermann hatte keinen Panzer exportiert. Er hatte ein Computerprogramm geschrieben und ins Internet gestellt. Das Programm hieß PGP Pretty Good Privacy. Es verschlüsselte E-Mails.
Eine Software war für die US-Regierung dasselbe wie eine Waffe.
Ich habe an dem Abend lange darüber nachgedacht. Was muss das für ein Programm sein, dass eine Supermacht es als Waffe einstuft? Und was sagt das über die Welt aus, in der wir damals lebten?
Ich wusste damals noch nicht, dass diese Geschichte eine der wichtigsten Erzählungen der zivilen Kryptografie werden würde. Aber ich wusste, dass etwas passierte, das ich verfolgen wollte. Das ist mein Rückblick darauf geschrieben für Menschen, die wissen wollen, woher die Werkzeuge kommen, mit denen wir heute arbeiten.
🟢 Orientierung Was PGP war und warum es überhaupt existieren musste
Die Welt vor PGP
Wer heute 30 ist, kennt eine Welt, in der Verschlüsselung selbstverständlich ist. Jede Webseite mit HTTPS, jede Banking-App, jeder Messenger alle nutzen kryptografische Verfahren, ohne dass irgendjemand darüber nachdenken muss. Das war nicht immer so.
In den 1980er und frühen 1990er Jahren war starke Verschlüsselung etwas, das Behörden, Militärs und große Unternehmen hatten. Privatpersonen hatten sie nicht. Wer privat einen Brief schreiben wollte, hatte zwei Möglichkeiten: per Post in einem Briefumschlag, der vom Postgeheimnis geschützt war, oder per E-Mail im Klartext, lesbar für jeden, der irgendwo auf dem Weg in der Leitung saß.
E-Mail war damals neu. 1991, als PGP erschien, hatten in Deutschland vielleicht 100.000 Menschen überhaupt einen E-Mail-Zugang. Die meisten saßen in Universitäten, Forschungseinrichtungen oder den IT-Abteilungen großer Unternehmen. Die Bandbreite war karg, die Server liefen mit Unix, das World Wide Web gab es noch nicht Tim Berners-Lee veröffentlichte den ersten Webserver im selben Jahr, in dem Zimmermann PGP veröffentlichte. Beide Werkzeuge haben die Welt verändert, jedes auf seine Art.
Zimmermann und die Aktivisten
Phil Zimmermann war kein klassischer Hacker. Er war ein politisch engagierter Programmierer, dem die Überwachung durch Geheimdienste schon lange Sorgen machte. In den 1980ern hatte er für Anti-Atomwaffen-Bewegungen gearbeitet. Er hatte gesehen, wie Aktivisten in autoritären Staaten verfolgt wurden, weil ihre Kommunikation abgehört wurde. Er war der Überzeugung: wenn nur Behörden Verschlüsselung haben, ist Demokratie nicht zu verteidigen.
Sein Ziel war ein Verschlüsselungsprogramm, das jeder normale Mensch nutzen kann. Auf seinem eigenen PC. Ohne Lizenz, ohne Kosten, ohne Erlaubnis von irgendeinem Anbieter.
Er nannte es Pretty Good Privacy. Der Name war Understatement eine kleine Geste in einer Welt, die große Versprechen gewohnt war. Ziemlich gute Privatsphäre. Nicht perfekte. Nicht totale. Ziemlich gute. Das reichte.
Wie PGP im Kern funktioniert die Briefkasten-Metapher
Bevor wir in die juristische Geschichte gehen, ein kurzer Halt bei der Technik. Wer nicht weiß, was Public-Key-Verfahren sind, kommt im Rest des Artikels nicht voran. Es ist aber einfacher, als die meisten denken.
Stell dir einen Briefkasten vor.
Der Briefkasten hat einen Schlitz, durch den jeder einen Brief einwerfen kann. Du kannst, ich kann, jeder kann. Der Schlitz ist öffentlich. Das ist der öffentliche Schlüssel.
Der Briefkasten hat auch eine Klappe, die mit einem Schlüssel verschlossen ist. Diesen Schlüssel hat nur der Besitzer des Briefkastens. Nur er kann die Klappe öffnen und die Briefe wieder herausholen. Das ist der private Schlüssel.
Jeder, der dem Besitzer eine Nachricht schicken will, wirft sie in den Schlitz. Niemand außer dem Besitzer kann sie wieder lesen auch derjenige nicht, der sie eingeworfen hat. Sobald der Brief im Kasten ist, ist er nur noch für den Besitzer zugänglich.
Das ist im Kern, was PGP technisch macht. Jeder Teilnehmer hat zwei Schlüssel: einen, den er der ganzen Welt zeigt (öffentlich), und einen, den er für sich behält (privat). Wer eine Nachricht an jemanden schickt, verschlüsselt sie mit dessen öffentlichem Schlüssel. Lesen kann sie nur derjenige, der den passenden privaten Schlüssel hat.
Diese Idee gibt es seit 1976. Sie heißt asymmetrische Kryptografie und wurde von Whitfield Diffie und Martin Hellman vorgestellt. Das Verfahren, das PGP konkret nutzt, wurde 1977 von Rivest, Shamir und Adleman entwickelt RSA. Aber bis 1991 war diese Mathematik in keiner Software gelandet, die ein normaler Mensch installieren konnte. PGP war die erste, die das tat.
🟡 Praxis Wie aus Software „Munition“ wurde
Die ITAR-Regelung
In den USA gab es seit Jahrzehnten ein Gesetz namens International Traffic in Arms Regulations. Es regelte den Export von Waffen, militärischer Ausrüstung und damit verbundenen Technologien. Auf der Liste der „Munitionsgüter“ stand auch starke Kryptografie das heißt, Verschlüsselungsverfahren ab einer bestimmten Schlüssellänge.
Wo lag die Grenze? Bei 40 Bit. Verschlüsselung mit 40-Bit-Schlüsseln durfte exportiert werden sie war so schwach, dass die NSA sie binnen Stunden brechen konnte. Alles darüber, also alles, was wirklich sicher war, galt als Munition und durfte nicht außer Landes.
PGP nutzte RSA-Schlüssel mit 1024 Bit und IDEA als symmetrischen Algorithmus mit 128 Bit. Das war weit, weit jenseits der erlaubten Grenze. PGP war damit ITAR-eingestufte Munition.
Zimmermann hat das gewusst. Er hat PGP trotzdem 1991 ins Internet gestellt. Genauer gesagt: ein Freund von ihm hat das getan, ohne explizit zu fragen. Aber das Internet macht keine Unterschiede zwischen „ein bisschen exportiert“ und „weltweit verfügbar“. Innerhalb weniger Wochen lief PGP auf Rechnern in Australien, Deutschland, Russland und Brasilien. Es war aus dem Land. Und die US-Regierung wollte wissen, wer dafür verantwortlich war.
Die Ermittlungen
1993 begann die strafrechtliche Untersuchung. Drei Jahre lang ermittelte das US Customs Office, dann das US Attorney’s Office, gegen Phil Zimmermann. Es ging um eine Anklage wegen unerlaubten Munitions-Exports die Strafdrohung lag bei bis zu fünf Jahren Haft und einer Million Dollar Geldstrafe.
Zimmermann hatte einen Anwalt, der erfahren war im Umgang mit Export-Kontrollen. Aber das Verfahren zog sich. Niemand wusste, wann es zur Anklage kommen würde, niemand wusste, wie ein Gericht entscheiden würde. In der Krypto-Szene weltweit verfolgte man den Fall mit großer Aufmerksamkeit. Wenn Zimmermann verurteilt würde, würde das bedeuten: jeder Programmierer, der weltweit zugängliche Verschlüsselungs-Software schreibt, kann in den USA strafrechtlich belangt werden, wenn sein Code irgendwie nach Amerika oder von dort weg gelangt.
Es war ein Verfahren mit Signal-Wirkung weit über den Einzelfall hinaus.
Der Buch-Trick
Hier kommt der Moment, an dem die Geschichte zur Legende wird.
Zimmermann und seine Anwälte überlegten: was darf in den USA ohne Beschränkung exportiert werden? Die Antwort: alles, was unter den Schutz des First Amendment fällt. Das First Amendment schützt die Meinungsfreiheit, einschließlich der Pressefreiheit. Bücher fallen darunter. Bücher sind in den USA seit jeher faktisch unkontrollierbar der Staat darf keine Druckwerke verbieten, auch nicht für den Export.
Software hingegen wurde damals nicht unter Meinungsfreiheit gefasst. Sie wurde als „Munition“ eingestuft.
Die Frage, die sich Zimmermann stellte: was, wenn man Software in ein Buch verwandelt?
1995 erscheint bei MIT Press das Buch PGP Source Code and Internals, geschrieben von Philip R. Zimmermann. 907 Seiten dick. Inhalt: das vollständige Vorwort, eine kurze Einführung, und dann der komplette Quellcode von PGP 2.6.2, Zeile für Zeile, in lesbarer Schrift abgedruckt. Drei Seiten von Menschen für Menschen geschrieben, der Rest gedruckter Code.
Das Buch durfte aus den USA exportiert werden. Es war eine Druckschrift, geschützt vom First Amendment. Es ging legal über die Grenze.
In Deutschland, in den Niederlanden, in Australien wurde das Buch gekauft. Programmierer scannten die Seiten ein, ließen den Text durch OCR-Programme laufen, korrigierten die Fehler, und am Ende hatten sie wieder das, was sie eigentlich wollten: den Quellcode von PGP. Sie kompilierten ihn, packten ihn als ausführbares Programm, und stellten ihn auf europäische Server. Von dort verbreitete sich PGP weltweit, völlig legal.
Die US-Regierung sah dieses Vorgehen und musste etwas Bemerkenswertes feststellen: ihre eigene Argumentation hielt nicht. Wenn der Quellcode in einem Buch stehen darf, dann ist er Sprache. Wenn er Sprache ist, dann ist er kein Munitions-Gut, sondern Meinungsäußerung. Die Trennlinie, die das ITAR aufgemacht hatte, zerbrach an einem Buch.
Im Januar 1996 stellte das US Attorney’s Office die Ermittlungen gegen Zimmermann ein. Ohne Anklage, ohne Verurteilung, ohne öffentliche Begründung. Drei Jahre Verfahren vorbei. 1999 wurden die Kryptografie-Export-Beschränkungen der USA grundlegend gelockert. Die ITAR-Einstufung von Verschlüsselungs-Software wurde aufgehoben.
PGP hatte den Krieg um zivile Verschlüsselung gewonnen, ohne dass jemals ein Gericht entschieden hatte.
Was PGP NICHT verschlüsselt — die Metadaten-Lücke
So weit die heroische Geschichte. Jetzt kommt die ernüchternde technische Wahrheit, die im Marketing der Verschlüsselung gerne übersehen wird.
PGP verschlüsselt den Inhalt einer E-Mail. Es verschlüsselt nicht alles andere drumherum.
Eine E-Mail besteht technisch aus zwei Teilen. Es gibt die Kopfzeilen Absender, Empfänger, Betreff, Datum, Größe, manchmal auch Routing-Informationen. Und es gibt den Nachrichten-Körper, also den eigentlichen Text der Botschaft. PGP verschlüsselt nur den zweiten Teil. Die Kopfzeilen bleiben offen sichtbar.
Das hat eine Konsequenz, die jeder Berufsgeheimnisträger verstehen muss: wer mit wem wann über welches Thema kommuniziert, ist für jeden Beobachter auf dem Übertragungsweg lesbar. Auch wenn der Inhalt verschlüsselt ist.
Das nennen wir Metadaten-Lücke. Sie ist die wichtigste Einschränkung von PGP, die fast immer unterschätzt wird.
Stell dir vor, ein Mitleser hat Zugang zu den Mail-Servern. Er sieht: Anna Becker hat am 14. Mai 2026 um 9:23 Uhr eine E-Mail an Bernd Weber geschickt. Betreff: „Strategie für den Prozess am Donnerstag“. Größe: 3.247 Bytes. Der Inhalt ist verschlüsselt, ja. Aber der Mitleser weiß: hier kommunizieren eine Anwältin und ihr Mandant, einen Tag vor einem Gerichtstermin, über eine Prozessstrategie. Diese Information allein ist in vielen Fällen schon Gold wert.
PGP schließt die Inhalts-Tür. Es schließt nicht die Metadaten-Tür. Wer beide Türen schließen will, braucht andere Werkzeuge moderne Messenger wie Signal verschlüsseln auch die Metadaten, weil sie nicht über E-Mail-Server laufen, sondern eigene Infrastruktur nutzen.
Das ist 1991 noch nicht bekannt gewesen in dieser Schärfe. Aber heute ist es eine der wichtigsten Lehren aus dem PGP-Fall: Verschlüsselung ist nie nur „verschlüsselt fertig“. Sie ist immer „verschlüsselt was, gegen wen, mit welchen Lücken“.
Web of Trust das radikale Vertrauensmodell
Eine zweite Eigenheit von PGP verdient Aufmerksamkeit, weil sie für unsere ganze Architektur-Linie relevant ist.
Wenn Anna eine verschlüsselte Mail an Bernd schicken will, braucht sie Bernds öffentlichen Schlüssel. Das haben wir schon geklärt. Die nächste Frage ist aber: woher weiß Anna, dass der Schlüssel, den sie als „Bernds öffentlichen Schlüssel“ vor sich liegen hat, wirklich Bernd gehört?
Das ist nicht trivial. Wenn jemand zwischen Anna und Bernd sitzt ein Angreifer, der die Mails abfangen will könnte er Anna einen gefälschten Schlüssel unterschieben, der so tut, als wäre er Bernds. Anna verschlüsselt ihre Nachricht mit diesem gefälschten Schlüssel. Der Angreifer kann sie lesen, verschlüsselt sie dann mit Bernds echtem Schlüssel weiter, und Bernd merkt nichts. Das ist ein klassischer Man-in-the-Middle-Angriff.
Wie verhindert man das? Es gibt zwei grundsätzlich verschiedene Modelle.
Das eine Modell ist die zentrale Zertifizierungsstelle. Es gibt eine vertrauenswürdige Autorität eine Behörde, eine Firma, eine Stelle, der alle vertrauen. Diese Autorität bestätigt, dass ein Schlüssel wirklich zu einer Person gehört. Sie stellt ein Zertifikat aus. Wer Anna’s Schlüssel sieht und das Zertifikat dazu, kann sich darauf verlassen, dass es stimmt. So funktioniert HTTPS im Web die Browser kennen eine Liste von Zertifizierungsstellen, und nur deren Zertifikate werden anerkannt.
Das andere Modell ist das Web of Trust, das PGP eingeführt hat. Es gibt keine zentrale Autorität. Stattdessen bestätigen sich Nutzer gegenseitig ihre Schlüssel. Wenn ich weiß, dass der Schlüssel von Anna wirklich Anna gehört weil ich Anna persönlich getroffen habe und ihren Schlüssel auf einem Stück Papier mitgenommen habe dann unterschreibe ich diesen Schlüssel digital. Meine Unterschrift sagt: „Ich bestätige, dass dieser Schlüssel zu Anna gehört.“
Wenn nun ein Dritter Anna’s Schlüssel sehen will und mich kennt und mir vertraut, kann er auch Anna’s Schlüssel vertrauen über die Brücke meiner Unterschrift. Es entsteht ein Netzwerk gegenseitiger Bestätigungen. Wer in diesem Netzwerk einen Weg von sich selbst zu einer anderen Person findet, kann ihrem Schlüssel vertrauen.
Das Schöne an diesem Modell: es funktioniert ohne Autorität. Kein Staat, keine Firma, keine zentrale Stelle muss eingebunden werden. Das Vertrauen entsteht aus dem Netz selbst.
Das Schwierige: es braucht Pflege. Wer Schlüssel signiert, übernimmt Verantwortung. Wer keinem Schlüssel begegnet und keine Verbindung zu anderen aufbaut, bleibt allein. Das Web of Trust ist eine Architektur, die ihre Nutzer fordert.
In den 1990er und 2000er Jahren gab es Versuche, das Web of Trust groß zu machen. Es gab Schlüssel-Signing-Partys, auf denen sich Programmierer trafen und gegenseitig ihre PGP-Schlüssel unterschrieben. Ein eigenes Ritual, halb sozial, halb technisch. Daraus entstand ein Netzwerk, das Jahre hielt bis es nicht mehr hielt. Aber das ist eine andere Geschichte.
Was sich seither geändert hat Schlüssel-Server und WKD
Wer den Artikel bis hier gelesen hat, wird sich fragen: gibt es heute nicht einfachere Wege, an einen öffentlichen Schlüssel zu kommen? Muss man wirklich noch Papier mitnehmen oder auf Signing- Partys gehen? Die Antwort ist: nein. Schlüssel-Server gibt es seit den 1990er Jahren, und sie sind über die Zeit deutlich besser geworden. Der heute aktiv gepflegte Server keys.openpgp.org liefert auf Anfrage den öffentlichen Schlüssel zu einer E-Mail-Adresse, wenn jemand ihn hochgeladen hat. Daneben gibt es WKD Web Key Directory, bei dem die E-Mail-Domain selbst den Schlüssel ausliefert. Wer eine Mail an bernd@firma.de schreibt, dessen E-Mail-Programm fragt im Hintergrund bei firma.de an, ob es dort einen Schlüssel für bernd gibt, und holt ihn sich. Drittens gibt es Autocrypt der Schlüssel reist im Header jeder unverschlüsselten Mail mit und wird beim ersten Kontakt automatisch übernommen.
Mit diesen drei Verfahren ist die Schlüssel-Verteilung in der Praxis kein Problem mehr. Wer Bernds Schlüssel will, bekommt ihn ohne Treffen, ohne Papier, ohne Telefonat. Aber: dieselbe Frage, die ich ein paar Absätze weiter oben gestellt habe, bleibt offen. Woher weiß ich, dass der Schlüssel, den der Server liefert, wirklich Bernd gehört? Der Server kann das nicht garantieren. Was er prüft, ist schwächer: er prüft, dass beim Hochladen jemand Zugriff auf die genannte E-Mail-Adresse hatte. Mehr nicht. Wer eine Mailbox kapert, kann einen fremden Schlüssel auf seinen Namen registrieren. Wer in einer staatlichen Position auf den Mailfluss zugreift, kann das auch. Das ist nicht theoretisch es ist die Architektur solcher Server, und sie ist bewusst so gemacht. Der Server soll verteilen, nicht authentifizieren.
Für Alltagskorrespondenz reicht das. „Trust on First Use“ nennt sich die Logik beim ersten Kontakt nimmt man, was kommt, und verlässt sich darauf, dass es nicht manipuliert ist. Für 99 Prozent der Mails ist das eine vernünftige Annahme. Für die übrigen ein Prozent das anwaltliche Mandat in einer politisch heiklen Sache, die journalistische Quelle, die ärztliche Korrespondenz zu einem sensiblen Diagnose-Verdacht reicht es nicht. Da bleibt der manuelle Abgleich des Schlüssel- Fingerabdrucks über einen zweiten Kanal die einzige saubere Lösung. Ein kurzes Telefonat: „Ich lese dir die letzten acht Zeichen deines Fingerabdrucks vor, du sagst mir, ob es stimmt.“ Drei Minuten Aufwand, einmal pro Schlüssel. Und du weißt, mit wem du wirklich sprichst. Der „Buch-Trick“ des Web of Trust lebt also weiter nicht als Massen-Verfahren, sondern als das, was er von Anfang an war: eine Disziplin für die Fälle, in denen es darauf ankommt.
🔵 Tiefe Warum PGP „gescheitert“ ist und warum es trotzdem überlebt hat
Die Fehlannahme
Wer in den 2000er Jahren über PGP schrieb, schrieb meistens dieselbe Geschichte: PGP ist ein brillantes Werkzeug, aber es hat sich nicht durchgesetzt, weil es zu kompliziert ist. Die Bedienoberflächen sind schwer, die Schlüssel-Verwaltung ist Frickelei, normale Menschen kommen damit nicht klar. PGP ist deshalb gescheitert.
Diese Geschichte ist nicht ganz falsch, aber sie ist auch nicht ganz richtig. Es lohnt sich, genauer hinzuschauen.
PGP hatte nie die Ambition, das Standard-Werkzeug für jeden zu werden, der eine E-Mail schreibt. Es war von Anfang an für eine bestimmte Gruppe gedacht: für Menschen, die Verantwortung für vertrauliche Kommunikation tragen und bereit sind, dafür einen gewissen Aufwand zu betreiben. Aktivisten, Journalisten, Anwälte, Forscher, Whistleblower, Software-Entwickler, die ihre Releases signieren wollen. Diese Gruppe gab es 1991, sie gibt es 2026, und sie nutzt PGP heute noch.
Was PGP zeigt und das ist die Lehre
Was PGP wirklich zeigt, ist etwas anderes als „Verschlüsselung muss benutzerfreundlich sein“. Es zeigt eine tiefere Wahrheit über Sicherheits-Architektur.
Jede Sicherheits-Architektur muss eine Entscheidung treffen: wer trägt die Last der Disziplin? Es gibt nur drei Antworten.
Erstens kann die Last beim Nutzer liegen. Er muss verstehen, was er tut. Er muss Schlüssel verwalten, Signaturen prüfen, Identitäten verifizieren. PGP hat sich für diese Antwort entschieden. Sie ist ehrlich, sie ist gründlich, und sie macht das Werkzeug schwer.
Zweitens kann die Last bei einer Autorität liegen. Eine zentrale Stelle übernimmt die Verantwortung Zertifizierungsstellen, App-Stores, Cloud-Anbieter. Der Nutzer muss nichts wissen, er muss nur der Autorität vertrauen. Das ist bequem, aber es verlagert das Problem nur.
Drittens kann die Last in der Architektur selbst liegen. Das Werkzeug wird so gebaut, dass die Disziplin im Werkzeug eingebaut ist. Der Nutzer muss nicht alles wissen, und es gibt keine Autorität, der er blind vertrauen muss die Architektur selbst macht es schwer, Fehler zu machen. Das ist die teuerste Variante, weil sie am Anfang viel Engineering verlangt, aber sie ist die einzige, die in der Breite tragfähig ist.
PGP gehört zur ersten Variante. Es ist Architektur mit der Last beim Nutzer. Das ist nicht schlecht für seine Zielgruppe ist es genau richtig. Aber es erklärt, warum PGP nie das Werkzeug der Massen wurde. Massen tragen keine Disziplin, die sie nicht aufbringen können.
Signal der heutige Standard-Messenger für sichere Kommunikation gehört zur dritten Variante. Die Schlüssel-Verwaltung läuft im Hintergrund, der Nutzer sieht sie kaum. Die Architektur trägt die Disziplin. Deshalb nutzen Hunderte Millionen Menschen Signal, und nur ein paar Tausend nutzen PGP.
Das heißt nicht, dass PGP überholt wäre. Es heißt, dass PGP eine bestimmte Klasse von Problemen löst, für die andere Werkzeuge die falsche Antwort wären.
Wo PGP heute noch sinnvoll ist
Es gibt drei Bereiche, in denen PGP nach wie vor das richtige Werkzeug ist.
Erstens, signierte Software-Veröffentlichungen. Wenn ein Programmierer eine neue Version seiner Software ausliefert, signiert er sie mit seinem PGP-Schlüssel. Wer die Software herunterlädt, kann mit dem öffentlichen Schlüssel des Programmierers prüfen, ob sie wirklich von ihm stammt und auf dem Weg nicht manipuliert wurde. Das ist der Standard in der Linux-Welt, im Open-Source-Software-Ökosystem, und auch bei Werkzeugen wie Tor. Ohne PGP-Signaturen wäre dieses Ökosystem deutlich verwundbarer.
Zweitens, langfristige E-Mail-Kommunikation mit kleinen, festen Gruppen. Wer regelmäßig mit denselben drei oder fünf Personen sensible Korrespondenz führt ein Anwalt mit seinem Stammmandanten, ein Journalist mit einer langjährigen Quelle, ein Forscher mit Kollegen in einem Projekt für den lohnt sich der einmalige Aufwand des Schlüssel-Tauschs. Danach läuft die Verschlüsselung über Jahre stabil, ohne dass jemand etwas Neues einrichten müsste.
Drittens, Verschlüsselung von Dateien für die Archivierung. Wer Daten verschlüsseln will, die er in zehn Jahren noch entschlüsseln können muss, will keine moderne App nutzen, die in fünf Jahren nicht mehr existiert oder ihre Schlüssel-Verwaltung verändert hat. PGP gibt es seit 35 Jahren. Es wird in den nächsten 35 Jahren mit hoher Wahrscheinlichkeit weiter funktionieren. Das ist eine Stabilität, die in der Software-Welt selten ist.
Für alles andere schnelle Chats, Ad-hoc-Kommunikation, breit gestreute Botschaften nimm Signal oder ein anderes modernes Werkzeug. Das ist nicht Verrat an der PGP-Philosophie, sondern die richtige Anwendung des richtigen Werkzeugs.
Was bleibt
Drei Beobachtungen am Ende dieses Rückblicks.
Erstens: zivile Verschlüsselung ist nicht selbstverständlich. Sie ist erkämpft. Zimmermann hat drei Jahre Strafverfolgung in Kauf genommen, um sie zu verteidigen. MIT Press hat ein Buch verlegt, von dem 904 Seiten nur Code waren, um eine juristische Lücke zu nutzen. Programmierer in Europa haben Stunden mit Scannern und OCR verbracht, um Software zu retten, die in den USA als Waffe galt. Wer heute eine verschlüsselte Nachricht schickt, steht in dieser Tradition. Es lohnt sich, sie zu kennen.
Zweitens: alte Werkzeuge sind nicht zwangsläufig schlechte Werkzeuge. PGP ist über drei Jahrzehnte alt und funktioniert immer noch. Sein Konzept ist nicht überholt, es ist nur nicht überall die beste Antwort. Wer ein altes Werkzeug pauschal abschreibt, weil es alt ist, übersieht oft genau die Qualität, die es zur Reife gebracht hat. Mein Segelboot heißt Legacy aus genau diesem Grund. Manche Dinge wurden gebaut, um zu halten.
Drittens und das ist die Lehre, die über PGP hinausgeht: jede Sicherheits-Architektur trifft eine Entscheidung darüber, wer die Disziplin trägt. Der Nutzer, eine Autorität, oder das Werkzeug selbst. PGP hat sich für den Nutzer entschieden. Das war 1991 die einzige Möglichkeit, weil die nötige Engineering-Tiefe für die dritte Variante noch nicht da war. Heute ist sie da, und es gibt Werkzeuge, die die Disziplin in die Architektur einbauen. Das ist die Richtung, in der wir bei Fleet Data arbeiten.
Aber jede dieser Architekturen verdankt ihrer Vorgängerin etwas. Was Signal heute kann, geht zurück auf das, was PGP gezeigt hat. Was wir morgen bauen, wird auf dem stehen, was Signal heute leistet. Das ist die Linie, die ich in über vier Jahrzehnten Software-Entwicklung gesehen habe: die guten Werkzeuge bauen aufeinander auf. Wer das ignoriert, baut Sandburgen.
Häufige Fragen
1. Brauche ich PGP heute überhaupt noch?
Wenn du gelegentlich verschlüsselt mit jemandem kommunizierst und kein Software-Entwickler bist, der seine Releases signiert: wahrscheinlich nicht. Für die meisten Anwendungsfälle ist Signal die bequemere und sicherere Wahl. PGP lohnt sich nur, wenn du einen der drei oben genannten Anwendungsfälle hast — Software-Signatur, langfristige Mail-Korrespondenz, archivierungs-stabile Datei-Verschlüsselung.
2. Wie installiere ich PGP auf meinem Rechner?
Die heutige Standardvariante ist GnuPG (GPG) eine freie Implementation des OpenPGP-Standards. Auf Linux ist es in den meisten Distributionen vorinstalliert oder einen Befehl entfernt. Auf macOS empfehle ich die GPG Suite, die sich in Apple Mail integriert. Auf Windows kommt Gpg4win in Frage. Eine konkrete Schritt-für-Schritt-Anleitung folgt in einem separaten Artikel der hier soll nicht zur Schritt-für-Schritt-Anleitung werden.
3. Was passiert, wenn ich meinen privaten Schlüssel verliere?
Dann sind alle Nachrichten, die mit dem zugehörigen öffentlichen Schlüssel verschlüsselt wurden, dauerhaft unlesbar. Es gibt keinen Wiederherstellungs-Mechanismus. Das ist die kalte Seite der Architektur: PGP traut keinem, also auch keiner zentralen Stelle, die ein Backup deines Schlüssels haben könnte. Wer mit PGP arbeitet, muss seinen privaten Schlüssel selbst sicher aufbewahren verschlüsselte Festplatte, Backup auf einem separaten Medium, idealerweise an einem zweiten Ort.
4. Ist PGP von Geheimdiensten geknackt worden?
Nach dem heutigen öffentlichen Stand: nein. Die Mathematik, auf der PGP beruht RSA und die symmetrischen Algorithmen wie AES gilt als sicher, solange die Schlüssel groß genug sind. Was Geheimdienste tun können, ist andere Wege: Endgeräte kompromittieren, private Schlüssel stehlen, Tastatureingaben aufzeichnen. Das ist nicht „PGP knacken“, das ist „an PGP vorbeigehen“. Die Architektur des Werkzeugs hält, die Architektur drumherum kann brechen.
5. Was bedeutet OpenPGP, und wie hängt es mit PGP zusammen?
PGP war ursprünglich Zimmermanns proprietäre Software. 1997 hat er den Standard offengelegt das wurde als OpenPGP standardisiert (RFC 4880). GnuPG, das wir heute nutzen, ist eine freie Implementation dieses Standards. PGP ist also einerseits ein konkretes Produkt (heute von der Firma OpenText vertrieben), andererseits eine Familie von Programmen, die alle OpenPGP-kompatibel sind. Wenn jemand sagt „ich nutze PGP“, meint er meistens irgendeine OpenPGP-Implementation, nicht zwingend Zimmermanns Original.
6. Die unbequeme Frage: Wenn PGP so gut ist, warum nutzt es kaum jemand?
Das ist die ehrliche Wahrheit. PGP wird im Alltag von vielleicht ein paar hunderttausend Menschen weltweit genutzt eine Nische. Das hat zwei Gründe. Erstens ist die Schlüssel-Verwaltung in der Praxis aufwendig, und die meisten Menschen haben dafür keine Zeit. Zweitens haben moderne Messenger wie Signal viele der Anwendungsfälle übernommen, in denen früher PGP nötig war, und das mit einer Bedienoberfläche, die jeder versteht. PGP ist also nicht gescheitert, weil es schlecht wäre, sondern weil es die falsche Antwort auf die Frage „wie verschlüsseln wir alltägliche Kommunikation“ ist. Es ist die richtige Antwort auf engere Fragen, und für die wird es weiter genutzt.
Wer noch tiefer einsteigen will
Quellen zur Geschichte
Phil Zimmermann hat selbst einen Aufsatz geschrieben mit dem Titel Why I Wrote PGP bis heute ein lesenswertes Stück Software-Politik. Online verfügbar auf seiner eigenen Seite.
Steven Levys Buch Crypto erzählt die ganze Krypto-Wars-Geschichte der 1990er Jahre, inklusive PGP. Wer die größere Erzählung will, fängt hier an.
Simon Singhs The Code Book widmet PGP ein ganzes Kapitel und ist die zugänglichste Einführung in Kryptografie, die ich kenne auch auf Deutsch erhältlich als Geheime Botschaften.
Wer eine kurze biografische Einordnung sucht, findet sie im Eintrag der Internet Hall of Fame zu Zimmermann oder auf der deutschen Wikipedia-Seite.
Praktische Anlaufstellen
Die Webseite gnupg.org ist die kanonische Quelle für GnuPG, die freie OpenPGP-Implementation. Direkter Einstieg in den Download.
Für Windows: Gpg4win eine vollständige Installation mit grafischer Oberfläche und Outlook-Integration.
Für macOS: die GPG Suite integriert GPG in Apple Mail und das macOS-Schlüsselbund-System. Der Mail-Plugin ist kostenpflichtig, der Rest ist frei.
Die Free Software Foundation hat eine Anleitung Email Self-Defense, die GnuPG mit Thunderbird Schritt für Schritt erklärt auf Deutsch verfügbar, gut gemacht, für Einsteiger geeignet. Etwa eine halbe Stunde Zeitaufwand.
Der Schlüssel-Server keys.openpgp.org ist heute der Standard für die Schlüssel-Verteilung. Die Selbstbeschreibung des Servers erklärt, was er garantiert und was nicht Pflichtlektüre, bevor man ihm blind vertraut.
Verwandte Artikel auf fleet-data.de
In der Sicherheits-Rubrik findest du den begleitenden Artikel zur Geschichte von GrapheneOS eine andere Erzählung über zivile Sicherheits-Architektur, mit ähnlicher Lehre.
In der Berufsgeheimnis-Rubrik findest du den Artikel zum Berufsgeheimnis-tauglichen Smartphone, der die Frage stellt, was diese Architektur für Anwälte, Ärzte und Notare praktisch bedeutet.
Schluss
Wir haben den Weg von einem Programmierer in Colorado, der 1991 ein Werkzeug für Aktivisten geschrieben hat, bis zu der Frage verfolgt, was sein Werkzeug uns über Architektur lehrt. Wir haben einen juristischen Trick gesehen, der ein Buch über die Grenze brachte, einen mathematischen Trick, der Briefe verschlüsselt, einen sozialen Trick, der Vertrauen ohne Autorität schafft. Drei Tricks, die zusammen ein Werkzeug ergeben, das seit fünfunddreißig Jahren hält.
Was bleibt, ist eine Frage, die jeder Berufsgeheimnisträger sich stellen sollte: Welche meiner Werkzeuge tragen ihre Disziplin selbst, und welche verlangen sie von mir? Die Antwort entscheidet, wo deine Sicherheits-Architektur trägt und wo sie an dem Tag bricht, an dem du müde bist.
In der Ruhe liegt die Kraft. Auch in der Verschlüsselung.⛵
Franz-Martin ist Gründer von Fleet Daten & Systems Consulting und seit über vier Jahrzehnten in der Software-Entwicklung. Er schreibt auf fleet-data.de über Sicherheit, Architektur und die Frage, was zivile Werkzeuge können müssen, um zu halten. Kontakt: Franz-Martin.Herstell@fleet-data.de
© 2026 Fleet Daten & Systems Consulting | fleet-data.de Dieser Beitrag stellt keine Rechts- oder Steuerberatung dar.