Von Gregor Veröffentlicht am 26 Okt. 2025

Clientseitiger PGP-Keygenerator

Einleitung

Vertrauliche Informationen landen heute ständig im Postfach – von Vertragsunterlagen bis zu sensiblen Anhängen. Wir schicken Verträge, Zugangsdaten und persönliche Dokumente per Mail und speichern sie auf unseren Geräten oder in Cloud‑Speichern – häufig ohne zusätzliche Verschlüsselung. Trotzdem sind viele E‑Mails und gespeicherte Dateien im Ruhezustand nur unzureichend geschützt und können bei einem Geräteverlust, einer Kompromittierung des Kontos oder einem Serverangriff im Klartext ausgelesen werden. Pretty Good Privacy (PGP) setzt genau hier an: Es ermöglicht sowohl Ende‑zu‑Ende‑verschlüsselte E‑Mails als auch die starke Verschlüsselung von Dateien im Ruhezustand, damit Inhalte nicht nur „auf dem Weg“, sondern auch dauerhaft abgesichert sind. Echten Schutz bietet nur Ende‑zu‑Ende‑Verschlüsselung (E2EE), doch viele PGP‑Lösungen wirken für Nutzer:innen wie undurchsichtige Blackboxes: Wo und wie genau werden deine PGP‑Schlüsselpaare erzeugt, und kannst du ausschließen, dass sie heimlich protokolliert oder weitergegeben werden?

Um diese Schwachstellen zu vermeiden und dir maximale Kontrolle über deine Schlüssel zu geben, setzt mein PGP‑Schlüsselgenerator genau hier an:

✅ Kein Tracking, keine Werbung
✅ Keine Installation nötig: Läuft direkt im Browser
✅ Keine aktive Datenübertragung an Dritte während der Nutzung
✅ Keine serverseitige Protokollierung der Schlüssel- oder Passwortdaten
✅ Keine versteckten Funktionen – das Verhalten ist im Code nachvollziehbar
✅ Open-Source-Code (vollständig einsehbar und überprüfbar)
✅ Für unterwegs: Funktioniert auch auf Smartphones und Tablets
✅ Vollständig clientseitig und offline nutzbar (für maximale Privatsphäre)
✅ Plattformunabhängig: auf allen Systemen mit modernem Browser nutzbar
✅ Benutzerfreundliche Oberfläche: Erstellung und Konfiguration ohne Kommandozeile

Aber „lokal“ und „offen“ allein garantieren noch keine Sicherheit. Damit dein PGP-Schlüsselpaar wirklich nur dir gehört und deine Daten bestmöglich schützt, habe ich zusätzliche technische Schutzmechanismen implementiert – transparent dokumentiert, mit Codeauszügen und Schritt-für-Schritt-Erklärungen.

Funktionen des Generators – im Detail erklärt

Im Folgenden zeige ich dir Schritt für Schritt, wie der Generator aufgebaut ist und wie du damit in wenigen Aktionen dein eigenes PGP-Schlüsselpaar erstellst.

1. Name/Pseudonym und E-Mail-Adresse

Diese beiden Angaben werden in deiner OpenPGP-Benutzer-ID gespeichert und identifizieren dich als Absender verschlüsselter Nachrichten oder digitaler Signaturen – ähnlich einer Absenderadresse auf einem Brief.

Name oder Pseudonym: Hier kannst du deinen echten Namen (z. B. Max Mustermann), ein Pseudonym (z. B. SecuNinja), Initialen (z. B. A. D.) oder eine andere Bezeichnung eintragen. Diese Information dient ausschließlich zur Identifikation und wird im öffentlichen Schlüssel sichtbar angezeigt.
E-Mail-Adresse: Gib die E-Mail-Adresse an, die mit dem Schlüssel verknüpft werden soll. Sie wird ebenfalls in der Benutzer-ID hinterlegt und hilft Empfänger:innen, deinen Schlüssel eindeutig zuzuordnen.

Warum das wichtig ist: Ohne eine klare Benutzer-ID ist für andere schwer erkennbar, wem ein Schlüssel gehört. Die hier eingetragenen Daten werden dauerhaft mit dem Schlüssel verknüpft und erscheinen bei der Prüfung von Signaturen oder beim Import deines öffentlichen Schlüssels. Du kannst frei entscheiden, ob du deinen Klarnamen, ein Pseudonym oder eine Kombination daraus verwenden möchtest.

2. Passwort für den privaten Schlüssel

Dieses Passwort schützt deinen privaten Schlüssel: Ohne es kann niemand – auch du selbst nicht – den Schlüssel zum Entschlüsseln oder Signieren verwenden. Das Passwort wird ausschließlich im Browser für die Verschlüsselung des privaten Schlüssels genutzt; der Generator sendet es nicht an Server und protokolliert es nicht. Es sorgt dafür, dass dein Schlüssel auch bei Verlust oder Diebstahl des Geräts nicht ohne weiteres missbraucht werden kann.
Wähle ein starkes Passwort mit mindestens 16 Zeichen (empfohlen: 20+ Zeichen für höhere Sicherheit), idealerweise mit einer Mischung aus Groß- und Kleinbuchstaben, Zahlen und Sonderzeichen. Am besten merkst du dir das Passwort gut oder speicherst es sicher in einem Passwort-Manager wie KeePassXC – ohne dieses Passwort kannst du deinen privaten Schlüssel später nicht mehr verwenden.

3. Bitgröße des Schlüssels

Die gewählte Bitgröße bzw. Kurve bestimmt die kryptographische Stärke deines Schlüssels und wird fest im Schlüssel verankert. Je höher die Sicherheitsstufe, desto aufwendiger wird es für Angreifer, deine Kommunikation zu brechen – bei gleichzeitig höherem Rechenaufwand für Generierung und Nutzung.

RSA 4096 Bit: Aktueller, weit verbreiteter Sicherheitslevel mit guter Balance aus Sicherheit und Performance für die meisten Einsatzzwecke
RSA 8192 Bit: Deutlich höhere Sicherheitsmarge, dafür spürbar langsamer bei Generierung und Nutzung; eher für Spezialfälle geeignet
ECC – Curve25519: Moderne, schlanke Kurve. Bietet bei kurzer Schlüssellänge ein Sicherheitsniveau, das grob mit RSA-3072 vergleichbar ist, und ist gleichzeitig schnell und kompakt
ECC - brainpoolP384r1: Standardisierte elliptische Kurve mit hohem Sicherheitsniveau im Bereich aktueller Langzeitempfehlungen, bei geringerer Rechenlast und kleineren Schlüsseln als entsprechend starke RSA-Varianten

4. Öffentlicher und privater Schlüssel

Sobald du auf „PGP‑Schlüsselpaar generieren“ klickst, werden zwei asymmetrische Schlüssel erzeugt, die mathematisch miteinander verknüpft sind. Der öffentliche Schlüssel ist für andere bestimmt und wird verwendet, um Nachrichten an dich zu verschlüsseln oder deine digitalen Signaturen zu prüfen. Er beginnt mit -----BEGIN PGP PUBLIC KEY BLOCK----- und enthält deine Benutzer‑ID sowie einen eindeutigen Fingerprint (z. B. 3D4A 1272 6DDD 25DA), der wie eine digitale Seriennummer fungiert. Über diesen Fingerprint lässt sich dein Schlüssel eindeutig identifizieren – vergleichbar mit einem Fingerabdruck. Zusätzlich wird eine Long Key ID angezeigt (z. B. 0x00DE72418FC3A070). Sie ist eine verkürzte, praktische Darstellung des Fingerprints und wird häufig in Schlüsselverzeichnissen oder als Kurzreferenz verwendet.
Der private Schlüssel bleibt ausschließlich für dich bestimmt und wird genutzt, um Nachrichten zu entschlüsseln oder zu signieren. Er beginnt mit -----BEGIN PGP PRIVATE KEY BLOCK----- und ist durch das von dir gesetzte Passwort geschützt. Diesen Schlüssel darfst du unter keinen Umständen weitergeben.

Warum das wichtig ist:
Den öffentlichen Schlüssel kannst (und solltest) du verteilen, damit andere dir verschlüsselte Nachrichten schicken oder deine Signaturen prüfen können. Der private Schlüssel dagegen muss strikt geheim bleiben, weil er den Zugang zu all deinen verschlüsselten Daten ermöglicht. Geht er verloren, kannst du damit verschlüsselte Nachrichten nicht mehr entschlüsseln oder signieren – ein sicheres Backup des Schlüsselpaares ist daher unerlässlich. Fingerprint und Long Key ID helfen dir und anderen dabei, den richtigen Schlüssel zu verifizieren und Manipulationen zu erkennen, etwa wenn Angreifer versuchen, gefälschte Schlüssel unter deinem Namen zu verbreiten.

Technische Sicherheitsmaßnahmen – detailliert erklärt

Im nächsten Teil gehe ich Punkt für Punkt durch, welche sicherheitsrelevanten Maßnahmen in diesem PGP‑Schlüsselgenerator umgesetzt sind. Zu jedem Punkt zeige ich dir einen Ausschnitt aus dem tatsächlichen Code und erläutere kurz, warum diese Maßnahme wichtig ist.

1. Clickjacking-Schutz

X-Frame-Options: DENY

Diese Anweisung verbietet es anderen Websites, deine Seite in einem <iframe> oder ähnlichen Frame-Elementen anzuzeigen. Warum ist das wichtig? Clickjacking-Angriffe nutzen unsichtbare oder getarnte Frames, um Nutzer:innen dazu zu bringen, unbewusst Klicks oder Eingaben auf deiner Seite auszuführen – z. B. um heimlich Schlüssel zu generieren oder Formulare abzusenden. Mit DENY unterbindest du genau dieses Einbetten, sodass der Generator nicht in fremden Seiten „untergeschoben“ werden kann.

2. Schutz vor MIME-Sniffing

X-Content-Type-Options: nosniff

Moderne Browser versuchen manchmal, den Typ einer Datei (z. B. JavaScript vs. Bild) automatisch zu erraten – selbst wenn der Server einen anderen Typ angibt. Das kann gefährlich werden, wenn Angreifer schädlichen Code als scheinbar harmlose Datei tarnen. Mit nosniff wird dieses „Raten“ unterbunden: Der Browser hält sich strikt an die deklarierten Content‑Types und führt z. B. kein JavaScript aus, das als Bild ausgegeben wird.

→ Reduziert das Risiko, dass manipulierte Dateien als ausführbarer Code behandelt werden.

3. Keine Referrer-Leaks

referrer-policy: strict-origin-when-cross-origin

Wenn du von einer Website zu einer anderen Domain wechselst, sendet dein Browser normalerweise die vorherige Adresse als „Referrer“ mit. Enthält diese URL sensible Informationen (z. B. Session‑IDs oder Parameter), können sie so bei der Zielseite landen.
Mit der Richtlinie strict-origin-when-cross-origin wird bei Aufrufen zu anderen Domains nur noch die Herkunfts‑Domain (z. B. https://www.secunis.de) übertragen, nicht mehr der komplette Pfad wie https://www.secunis.de/pgp-generator?key=123.

→ Das schützt deine Privatsphäre gegenüber Drittseiten und reduziert das Risiko, dass sensible Pfade oder Parameter im Referrer auftauchen.

4. Blockierter Hardware-Zugriff

Permissions-Policy: geolocation=(), microphone=(), camera=()

Manche Websites versuchen, auf Kamera, Mikrofon oder Standortdaten zuzugreifen – teils ohne dass Nutzer:innen es bewusst mitbekommen. Diese Richtlinie schaltet diese Berechtigungen für die Seite komplett ab: Der Browser stellt den entsprechenden APIs für diese Seite keine Hardware‑Zugriffe zur Verfügung.

→ So stellt der Generator sicher, dass er selbst weder Kamera, Mikrofon noch Standortdaten anfragt oder nutzt.

5. Schutz vor Code-Injection – Content-Security-Policy und sichere DOM‑Nutzung

Die Content-Security-Policy (CSP) erlaubt Skripte und Styles ausschließlich aus der eigenen Anwendung (script-src 'self' 'unsafe-inline', style-src 'self' 'unsafe-inline') und blockiert externe Quellen sowie aktive Inhalte wie Plugins (object-src 'none'). Dadurch wird verhindert, dass fremde Skripte oder eingebettete Inhalte nachgeladen werden können.

Bei der Manipulation des DOM nutzt der Generator für dynamische Texte konsequent textContent anstelle von innerHTML. So werden Benutzereingaben als reiner Text behandelt und nicht als HTML interpretiert, was das Risiko klassischer Cross‑Site‑Scripting‑(XSS‑)Angriffe deutlich reduziert.

Sichere DOM-Manipulation: Statt innerHTML (das Code ausführen könnte) wird textContent verwendet, das Eingaben nur als Text behandelt. → Verhindert: Cross-Site Scripting (XSS), bei dem Angreifer:innen schädlichen Code in die Seite einschleusen

→ Die Kombination aus restriktiver CSP und sicherer DOM‑API-Nutzung erschwert es Angreifern erheblich, schädlichen Code in die Seite einzuschleusen.

6. Keine externen Verbindungen oder iframes

frame-src 'none' und connect-src 'none'

frame-src 'none': Verhindert, dass die Seite externe Inhalte in Frames lädt (z. B. Werbung, Tracking‑Elemente oder eingebettete Widgets)
connect-src 'none': Blockiert alle Netzwerkaufrufe der Seite zu externen Servern – auch dann, wenn ein Skript versuchen würde, Daten zu senden oder nachzuladen.

→ Ergebnis: Der Generator selbst baut keine Verbindungen zu Dritten auf, und alle kryptographischen Operationen laufen vollständig lokal im Browser ab

7. Erzwungene HTTPS-Verschlüsselung

HTTP Strict Transport Security (HSTS) mit Preload

Auf Serverebene ist HTTP Strict Transport Security (HSTS) aktiviert. Dadurch weist die Website den Browser an, diese Domain ausschließlich über verschlüsselte HTTPS‑Verbindungen aufzurufen – selbst dann, wenn Nutzer:innen manuell http:// eingeben.
Ist die Domain zusätzlich in der HSTS‑Preload‑Liste der Browserhersteller hinterlegt, erzwingt der Browser bereits beim ersten Aufruf automatisch HTTPS.

→ Das erschwert Downgrade‑Angriffe, bei denen ein Angreifer versucht, die Verbindung von HTTPS auf unsicheres HTTP herunterzustufen.

8. Schutz vor History Sniffing

history.pushState mit sauberer URL-Pflege

Beim Laden der Seite wird mit history.pushState ein eventuell vorhandenes URL‑Fragment (#…) entfernt. Das sorgt für eine saubere, stabile URL in der Adresszeile und verhindert, dass interne Anker dauerhaft mitgeschleppt werden.

9. Autovervollständigung bewusst eingeschränkt

Browser speichern standardmäßig Eingaben in Formularfeldern – inklusive Passwörtern. Das ist bequem, kann aber riskant sein, wenn ein Gerät gemeinsam genutzt wird. Für Felder wie Name und E‑Mail ist die Autovervollständigung daher deaktiviert (autocomplete="off"), damit hier keine alten Formulareinträge eingeblendet werden.
Die Passwortfelder sind mit autocomplete="new-password" gekennzeichnet, sodass der Browser sie nicht wie bestehende Login‑Passwörter behandelt, aber moderne Passwort‑Workflows (z. B. Generatoren) weiterhin funktionieren.

→ Dadurch wird das Risiko verringert, dass sensible Eingaben unbeabsichtigt wieder auftauchen oder mit falschen gespeicherten Werten befüllt werden.

10. Secure‑Wipe für DOM‑Felder

Browser halten Inhalte aus Formularfeldern und Textbereichen oft noch eine Zeit lang im Arbeitsspeicher, selbst wenn sie im sichtbaren DOM bereits gelöscht wurden. Deshalb überschreibt die Funktion secureWipe() sensible Inhalte zunächst mit kryptographisch zufälligen Daten über crypto.getRandomValues() und leert das Feld erst danach. Sie funktioniert nicht nur für input- und textarea-Felder, sondern auch für Textinhalte wie Fingerprint- oder Key-ID-Anzeigen.

→ Das reduziert das Risiko, dass sensible Daten im DOM oder in einfachen Speicherresten unbeabsichtigt wieder auftauchen. Eine vollständige forensische Speicherlöschung kann JavaScript jedoch nicht garantieren.

11. Überschreiben von Uint8Array-Puffern (RAM-Bereinigung)

OpenPGP.js verarbeitet Schlüsselmaterial intern in Byte-Puffern wie Uint8Array, die während der Laufzeit im Arbeitsspeicher verbleiben können. Die Funktion wipeArrayBuffer() überschreibt solche Puffer nach der Verwendung mit Zufallswerten. Anschließend werden beim eingelesenen privaten Schlüssel die über packetList erreichbaren Byte-Daten durchlaufen und – soweit verfügbar – zusätzlich mit clearPrivateParams() interne private Parameter bereinigt.
Dadurch wird das Risiko verringert, dass Schlüsselmaterial in einfachen Speicherresten oder auslesbaren Laufzeitobjekten im Klartext erhalten bleibt. Eine vollständige Löschung im forensischen Sinn kann JavaScript jedoch nicht garantieren, da Browser und Laufzeitumgebung die Speicherverwaltung selbst kontrollieren.

12. Warnung beim Verlassen der Seite mit generierten Schlüsseln

window.addEventListener('beforeunload', function(e) { if (document.getElementById('privateKey').value !== '') { const lang = document.getElementById("languageSelector").value; const t = translations[lang]; e.preventDefault(); e.returnValue = t.beforeUnloadWarning; return t.beforeUnloadWarning; } });

Nutzer:innen könnten die Seite versehentlich schließen, obwohl noch ein privater Schlüssel im Formular angezeigt wird. Deshalb registriert der Generator einen beforeunload-Handler, der beim Verlassen der Seite eine Warnung ausgibt, sobald das Feld für den privaten Schlüssel noch befüllt ist.
Die Meldung erinnert daran, vor dem Schließen den „Secure-Wipe“-Button zu verwenden und sensible Inhalte bewusst zu entfernen.

→ Das reduziert das Risiko, die Seite unachtsam mit noch sichtbaren Schlüsseldaten zu verlassen.

13. Nutzung nativer Kryptofunktionen des Browsers

if (window.openpgp && openpgp.config) { openpgp.config.use_native = true; }

In der aktuellen Version konfiguriert der Generator OpenPGP.js so, dass – sofern von der Bibliothek unterstützt – native Kryptofunktionen des Browsers bevorzugt werden. Dazu wird openpgp.config.use_native = true gesetzt.
Native Browser-Funktionen können kryptographische Operationen effizienter ausführen als reine JavaScript-Implementierungen und nutzen dafür die Sicherheitsmechanismen der jeweiligen Laufzeitumgebung.

→ Das verbessert die Performance und nutzt, soweit verfügbar, die nativen Krypto-Funktionen des Browsers.

14. Keine globalen Schlüssel-Objekte

const { privateKey, publicKey } = await openpgp.generateKey(options);

Die erzeugten Schlüssel werden innerhalb der Funktion generateKeyPair() zunächst in lokalen Variablen gehalten und nicht als globale Objekte wie window.privateKey oder window.publicKey abgelegt.
Dadurch entstehen keine dauerhaft global erreichbaren Referenzen, die von anderem JavaScript im selben Kontext leicht ausgelesen oder versehentlich weiterverwendet werden könnten.
→ Das reduziert das Risiko unnötig langlebiger Schlüssel-Referenzen im Browser-Kontext.

15. Bereinigung von OpenPGP.js-internen Speicherobjekten

function wipeOpenPGPObjects() {
if (window.openpgp) {
if (typeof openpgp.config.clearPrivateParams === 'function') {
openpgp.config.clearPrivateParams();
}
if (window.tmpPrivateKey) {
delete window.tmpPrivateKey;
}
}
}

function exportKey(id, defaultFilename) {
// ...
wipeOpenPGPObjects();
}

Sensible Daten liegen nicht nur in sichtbaren DOM-Feldern wie textarea oder input, sondern können während der Verarbeitung auch in internen JavaScript-Objekten der OpenPGP-Bibliothek vorhanden sein. Deshalb ergänzt wipeOpenPGPObjects() den DOM-basierten „Secure-Wipe“ um eine zusätzliche Bereinigung auf Bibliotheksebene.
Die Funktion ruft – soweit von OpenPGP.js unterstützt – clearPrivateParams() auf und entfernt temporäre globale Referenzen wie window.tmpPrivateKey, falls solche vorhanden sind. Sie wird nach Exporten sowie beim Zurücksetzen der Felder automatisch ausgeführt.

→ Dadurch wird das Risiko verringert, dass sensible Schlüsselparameter unnötig lange in erreichbaren JavaScript-Objekten verbleiben.

16. Sicherer Initialzustand beim Seitenaufruf

Beim Laden der Seite setzt der Generator alle relevanten Felder und Anzeigen in einen definierten, „sauberen“ Ausgangszustand:

Eingabefelder für Name, E‑Mail, Passwort und Passwortbestätigung werden überschrieben bzw. auf leer zurückgesetzt
Textbereiche für öffentlichen und privaten Schlüssel, Fingerprint und Long Key ID werden geleert und auf ihre Standardtexte zurückgesetzt
Export‑Buttons (öffentlicher Schlüssel, privater Schlüssel, Schlüsselpaar / ZIP) werden deaktiviert, solange noch kein neues Schlüsselpaar erzeugt wurde

→ So wird sichergestellt, dass beim ersten Aufruf oder nach einem Reload keine alten Formularreste oder Schlüsselanzeigen aus vorherigen Sitzungen im Interface verbleiben.

17. Erweiterte CSP-Härtung

Content-Security-Policy:

frame-ancestors 'none'; object-src 'none'; base-uri 'none'; form-action 'self'

Neben den bereits erwähnten Direktiven setzt der Generator weitere CSP-Regeln, um Angriffsflächen im Browser zu minimieren:

frame-ancestors 'none': Verhindert, dass die Seite in fremden Frames oder iframes angezeigt wird – selbst dann, wenn X-Frame-Options vom Browser ignoriert würde. Damit wird Clickjacking zusätzlich zur klassischen Header-Variante auf CSP-Ebene blockier
object-src 'none': Unterbindet den Einsatz von <object>, <embed> oder alten Plugin-Techniken (z. B. Flash), über die sonst aktive Inhalte eingeschleust werden könnten
base-uri 'none': Verhindert, dass ein Angreifer die Basis-URL der Seite manipuliert (z. B. per <base>-Tag), um relative Links oder Ressourcen unbemerkt auf andere Domains umzubiegen
form-action 'self': Erzwingt, dass Formulare – falls sie verwendet würden – nur an die eigene Origin gesendet werden dürfen und nicht an fremde Endpunkte umgeleitet werden können

→ Diese zusätzlichen Direktiven härten die Seite gegen eine Reihe klassischer Webangriffe ab, die über Frames, Plugins oder manipulierte Form- und Linkziele laufen.

18. Nutzung nativer Browser-Krypto

Wo es die Bibliothek unterstützt, konfiguriert der Generator OpenPGP.js so, dass bevorzugt die nativen Kryptofunktionen des Browsers genutzt werden (use_native). Das kann je nach Umgebung sowohl Performance- als auch Stabilitätsvorteile bringen, weil auf die geprüften Krypto-Implementierungen der jeweiligen Laufzeit zurückgegriffen wird, anstatt alles rein in JavaScript zu berechnen.

→ Dadurch profitieren Schlüsselerzeugung und kryptographische Operationen von den Sicherheits- und Optimierungsmechanismen der Browserplattform, ohne dass zusätzliche externe Abhängigkeiten eingeführt werden.

19. Keine externen Abhängigkeiten

Der Generator lädt alle benötigten Ressourcen lokal von der eigenen Website – ohne CDN, ohne Drittanbieter-Skripte und ohne externe Schriftarten. Dadurch entstehen beim Laden und bei der Nutzung keine unnötigen Verbindungen zu fremden Servern, die Tracking, Manipulationen oder zusätzliche Angriffsflächen mit sich bringen könnten.
Auch die verwendeten Bibliotheken wie OpenPGP.js und JSZip werden lokal eingebunden und nicht zur Laufzeit von externen Quellen nachgeladen. So bleibt die Anwendung transparent, nachvollziehbar und unabhängig von Drittanbietern.

20. Offline-Fähigkeit

Nach dem Laden der Seite arbeitet der Generator vollständig lokal im Browser und benötigt für die Schlüsselerzeugung keine weitere Serverkommunikation. Das bedeutet: Während der eigentlichen Nutzung werden keine Schlüssel- oder Passwortdaten an externe Systeme übertragen.
Alle benötigten Bibliotheken – darunter OpenPGP.js und JSZip – werden lokal von der Anwendung eingebunden und nicht erst zur Laufzeit von Drittservern nachgeladen. Dadurch bleibt der Generator auch dann funktionsfähig, wenn nach dem Laden keine Internetverbindung mehr besteht oder er in kontrollierten Offline-Umgebungen genutzt wird.

→ Das macht ihn besonders geeignet für datensensible Einsatzszenarien und für Nutzer:innen, die Schlüssel möglichst isoliert erzeugen möchten.

Post-Quantum-Kryptografie (PQC)

Aktuelle OpenPGP-Verfahren wie RSA und klassische elliptische Kurven (z. B. Curve25519) gelten nicht als quantenresistent. Sobald leistungsfähige Quantencomputer verfügbar wären, könnten solche Verfahren prinzipiell durch Shor’s Algorithmus gebrochen werden. Eine akute praktische Gefahr besteht derzeit jedoch nicht, da heutige Quantencomputer dafür noch nicht annähernd leistungsfähig genug sind.
In der OpenPGP-Community wird bereits an standardisierten Post-Quantum-Erweiterungen gearbeitet. Der aktuelle IETF-Entwurf Post-Quantum Cryptography in OpenPGP beschreibt entsprechende Verfahren und befindet sich im Standardisierungsprozess. Dabei spielen moderne PQC-Verfahren wie ML-KEM und ML-DSA sowie hybride Kombinationen mit klassischen Algorithmen eine wichtige Rolle.archive.
Sobald diese Standards final verfügbar und in OpenPGP.js stabil umgesetzt sind, kann der Generator um Unterstützung für post-quantum-sichere Verfahren erweitert werden.

Fazit – Kontrolle behalten, nicht blind vertrauen

Mit diesem Generator behältst du ein hohes Maß an Kontrolle über deine digitale Privatsphäre: Die Schlüsselerzeugung erfolgt lokal im Browser, ohne dass Schlüssel- oder Passwortdaten an Dritte übertragen werden, und die zentralen Abläufe bleiben im Code nachvollziehbar.
Du musst also nicht blind vertrauen, sondern kannst selbst prüfen, wie der Generator arbeitet und welche Schutzmechanismen umgesetzt wurden.
Besonders wichtig bleibt: Erst durch echte Ende-zu-Ende-Verschlüsselung – ob für E-Mails oder für Dateien im Ruhezustand – behältst du die Vertraulichkeit deiner Daten in der eigenen Hand.

Probiere ihn direkt aus: PGP-Keygenerator