Von Veröffentlicht am

Clientseitiger PGP-Keygen

Warum dieser PGP-Keygen?

Jeden Tag verschicken wir E-Mails – doch selten sind sie wirklich sicher. Pretty Good Privacy (PGP) ist ein Verschlüsselungssystem, das sowohl zum Senden verschlüsselter E-Mails als auch zum Verschlüsseln von Dateien im Ruhezustand verwendet wird. Die meisten Anbieter verschlüsseln zwar die Übertragung (z. B. mit TLS), aber nicht die Inhalte selbst – deine Nachrichten und Anhänge liegen also unverschlüsselt auf ihren Servern. Nur Ende-zu-Ende-Verschlüsselung (E2EE) schützt wirklich, doch viele PGP-Tools sind undurchsichtige Blackboxes: Wie kannst du sicher sein, dass die von dir erstellten PGP-Schlüsselpaare – die deine E-Mails und Dateien verschlüsseln – nicht heimlich protokolliert oder weitergegeben werden? Zudem erfordern sie oft eine lästige Software-Installation und laufen nicht auf allen Geräten – ein echtes Problem, wenn du nur ein Smartphone nutzt.

Mein PGP-Schlüsselgenerator bietet die Lösung:

✅ Keine Protokollierung
✅ Keine Datenübertragung
✅ Kein Tracking, keine Werbung
✅ Keine undokumentierten Prozesse
✅ Offline-fähig (für maximale Privatsphäre)
✅ Keine Installation nötig: Sofort einsatzbereit
✅ Plattformunabhängig: auf allen Systemen nutzbar
✅ Für unterwegs: Funktioniert auch nur mit dem Smartphone
✅ Open-Source-Code (vollständig einsehbar) → Quellcode anzeigen
✅ Einfache GUI: Schnelle Erstellung und Konfiguration ohne Kommandozeile

Doch „lokal“ und „offen“ allein garantieren noch keine Sicherheit. Damit dein PGP-Schlüsselpaar wirklich nur dir gehört und deine Daten zuverlässig schützt, habe ich eingebaut – transparent erklärt mit Codebeispielen und Schritt-für-Schritt-Erläuterungen.

Funktionen im Generator – im Detail erklärt

Jetzt möchte ich dir meinen Generator vorstellen – ein Werkzeug, mit dem du in wenigen Schritten dein eigenes PGP-Schlüsselpaar erstellst.

1. Name/Pseudonym und E-Mail-Adresse

Diese beiden Angaben werden und identifizieren dich als Absender von verschlüsselten Nachrichten oder digitalen 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 beliebige Bezeichnung eingeben. Diese Angabe dient zur Identifikation und wird angezeigt.
  • E-Mail-Adresse: Gib hier die E-Mail-Adresse ein, die mit dem Schlüssel verknüpft werden soll. Diese wird ebenfalls im Schlüssel hinterlegt und hilft Empfänger:innen, dich eindeutig zuzuordnen.

Warum das wichtig ist: Ohne eine klare Identifikation wissen andere nicht, wem der Schlüssel gehört. Die eingegebenen Daten werden und in allen verschlüsselten Nachrichten oder digitalen Signaturen angezeigt. Du kannst hier frei wählen, ob du deinen echten Namen, ein Pseudonym oder eine Kombination aus beidem verwendest – ganz nach Bedarf.

2. Passwort für den privaten Schlüssel

Dieses Passwort schützt deinen privaten Schlüssel und wird untrennbar mit ihm verknüpft. Ohne dieses Passwort kann niemand – nicht einmal du selbst – deinen Schlüssel nutzen, um Nachrichten zu entschlüsseln oder zu signieren. Warum das wichtig ist: Das Passwort wird ausschließlich in deinem Browser verwendet, nie übertragen oder gespeichert. Es stellt sicher, dass dein Schlüssel auch bei Verlust des Geräts oder Diebstahl geschützt bleibt. Wähle ein sicheres Passwort mit mindestens 16 Zeichen (empfohlen: 20+ Zeichen für maximale Sicherheit). Eine Kombination aus Groß-/Kleinschreibung, Zahlen und Sonderzeichen bietet den besten Schutz. Wähle ein Passwort, das du dir gut merken kannst – oder speichere es sicher extern (z. B. in einem Passwort-Manager wie KeePassXC). Ohne es kannst du deinen privaten Schlüssel nicht mehr nutzen!


3. Bitgröße des Schlüssels

Die Bitgröße bestimmt die und wird fest in deinem Schlüssel verankert. Sie legt fest, wie schwer es für Angreifer ist, deine Nachrichten zu knacken – ähnlich wie die Dicke eines Tresors. Warum das wichtig ist: Eine größere Bitgröße bietet , erfordert aber etwas mehr Rechenleistung.

  • RSA 4096 Bit: Aktueller Standard (empfohlen von EFF und GnuPG) –
  • RSA 8192 Bit: (Generierung/Nutzung)
  • ECC – Curve25519: Moderne Alternative. Schneller, kompakter und robuster gegen Implementierungsfehler – bei vergleichbarer Sicherheit ()
  • ECC - brainpoolP384r1: Standardisierte elliptische Kurve – hohe Sicherheit () bei deutlich geringerer Rechenlast und kompakteren Schlüsseln. Ideal für effiziente, .

4. Öffentlicher und privater Schlüssel

Sobald du auf „PGP-Schlüsselpaar generieren“ klickst, werden zwei asymmetrische Schlüssel erstellt, die mathematisch miteinander verknüpft sind. Der öffentliche Schlüssel wird für andere sichtbar sein und dient dazu, 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 (z. B. 3D4A 1272 6DDD 25DA), der wie eine digitale Seriennummer fungiert. Dieser Fingerprint ermöglicht es, deinen Schlüssel eindeutig zu identifizieren – ähnlich wie ein Fingerabdruck für Menschen. Daneben gibt es die Long Key ID (z. B. 0x00DE72418FC3A070), eine gekürzte, praktische Darstellung des Fingerprints, die oft in Schlüsselverzeichnissen oder zur schnellen Referenz verwendet wird. Der private Schlüssel bleibt geheim und ist nur für dich bestimmt, um Nachrichten zu entschlüsseln oder zu signieren.
Dieser Schlüssel darf auf KEINEN FALL weitergegeben werden! Er beginnt mit -----BEGIN PGP PRIVATE KEY BLOCK----- und ist .

Warum das wichtig ist: Der öffentliche Schlüssel kann und sollte geteilt werden, damit andere dir sicher verschlüsselte Nachrichten schicken können. Der private Schlüssel hingegen muss absolut sicher aufbewahrt werden, da er den Zugang zu deinen verschlüsselten Daten ermöglicht. Ohne ihn kannst du keine Nachrichten entschlüsseln oder signieren. Ein sicheres Backup ist daher unerlässlich. Fingerprint und Long Key ID dienen dazu, deinen Schlüssel eindeutig zuzuordnen und sicherzustellen, dass er nicht manipuliert wurde – etwa durch Angreifer, die versuchen, zu verbreiten.


Technische Sicherheitsmaßnahmen – detailliert erklärt

Hier gehe ich Punkt für Punkt durch, welche sicherheitsrelevanten Vorkehrungen in meinem PGP-Schlüsselgenerator umgesetzt wurden – inklusive Codebeispiel direkt aus dem Projekt und jeweils einer kurzen Erklärung, warum das wichtig ist.

1. Clickjacking-Schutz

X-Frame-Options: DENY

Diese Anweisung verbietet es jeder anderen Website, deine Seite in einem <iframe> anzuzeigen. Warum ist das wichtig? , 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 wird das komplett blockiert. Selbst wenn eine böswillige Seite versucht, deinen Generator einzubetten, wird er nicht angezeigt.

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 etwas anderes angibt. Das kann gefährlich sein, wenn Angreifer:innen . Mit nosniff wird dieses „Raten“ unterbunden. Der Browser hält sich strikt an die vom Server angegebenen Dateitypen und führt z. B. kein JavaScript aus, das als Bild getarnt ist. → Verhindert: Das Einschleusen von Schadcode durch manipulierte Dateien.

3. Keine Referrer-Leaks

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

Wenn du von einer Website zu einer anderen wechselst, sendet dein Browser normalerweise die vollständige URL der vorherigen Seite mit (der „Referrer“). Das kann Privatsphäre-Probleme verursachen – besonders, wenn die URL sensible Daten enthält (z. B. Session-IDs). Diese Richtlinie sorgt dafür, dass nur die Domain (z. B. secunis.de) weitergegeben wird, nicht der gesamte Pfad (z. B. secunis.de/pgp-generator?key=123).
→ Schützt deine Privatsphäre und verhindert, dass Dritte nachvollziehen können, welche Unterseiten du besucht hast.
→ Es werden also keine sensiblen Pfade oder Parameter (z. B. ?key=123) preisgegeben

4. Blockierter Hardware-Zugriff

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

Manche Websites versuchen, auf Kamera, Mikrofon oder Standortdaten zuzugreifen – oft ohne dass Nutzer:innen es merken. Diese Richtlinie deaktiviert diese Berechtigungen komplett. Selbst wenn eine Schwachstelle im Browser existieren würde: Keine Hardware wird angefragt oder genutzt. → Garantiert: Dass dein Generator niemals auf persönliche Gerätedaten zugreift.

5. Schutz vor Code-Injection

Restriktive Content-Security-Policy (CSP) + Input-Sanitization

  • Die Content-Security-Policy (CSP) erlaubt Inline-Skripte und -Styles (unsafe-inline) ausschließlich für die Benutzeroberfläche (z. B. Dropdown-Menüs), blockiert aber jede externe Skript-Quelle script-src 'self'. Alle Benutzereingaben werden bereinigt, und DOM-Manipulationen nutzen textContent statt innerHTML, um XSS-Angriffe zu verhindern
  • Input-Sanitization: Alle Benutzereingaben (z. B. dein Name oder E-Mail-Adresse) werden kontextsensitiv bereinigt (z. B. HTML-Sonderzeichen für XSS-Schutz), bevor sie verarbeitet werden. Sonderzeichen wie <, >, oder " – die für XSS-Angriffe genutzt werden könnten – werden entfernt
  • 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

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 oder Tracking-Tools)
  • connect-src 'none': Blockiert jeden Versuch, Daten an externe Server zu senden – selbst wenn ein Skript es versuchen würde. → Ergebnis: Der Generator kommuniziert mit niemandem – alle Prozesse laufen ausschließlich lokal ab

7. Erzwungene HTTPS-Verschlüsselung

HTTP Strict Transport Security (HSTS) mit Preload

  • HSTS zwingt den Browser, nur verschlüsselte HTTPS-Verbindungen zu nutzen – selbst wenn Nutzer:innen manuell http:// eingeben
  • Preload: Die Domain ist in einer globalen Liste (der „“) hinterlegt, sodass auch der erste Besuch automatisch verschlüsselt wird. → Schützt vor: Downgrade-Angriffen, bei denen ein Angreifer die Verbindung auf unsicheres HTTP umleitet

8. Schutz vor History Sniffing

history.pushState mit sauberer URL-Pflege

  • Verhindert, dass die Seite im Browserverlauf sichtbar bleibt – Angreifer können nicht erkennen, ob du den Keygen genutzt hast
  • Löscht URL-Fragmente (z. B. #section), die sonst für Sniffing-Attacken genutzt werden könnten
  • Schützt vor Tracking durch bösartige Websites, die prüfen, welche Seiten du besucht hast (z. B. durch )

Schützt vor: Tracking deiner Aktivitäten, z. B. wenn Angreifer versuchen, Rückschlüsse auf deine Nutzung von Sicherheits-Tools (wie PGP-Keygen) zu ziehen.

9. Keine Autovervollständigung sensibler Daten

autocomplete="off"

Browser speichern standardmäßig Eingaben in Formularfeldern – inklusive Passwörtern. Das ist praktisch, aber riskant, wenn der Rechner gemeinsam genutzt wird. Hier wird die Autovervollständigung explizit deaktiviert, sodass keine Passwörter oder Schlüssel-Phrasen im Browser-Cache landen.
→ Sichert: Dass deine Geheimnisse nie gespeichert werden.

10. Secure-Wipe für DOM-Input-Felder

function secureWipe(target) {
  if (target instanceof HTMLElement) {
    const length = target.value.length;
    let randomText = '';
    for (let i = 0; i < length; i++) {
      randomText += String.fromCharCode(Math.floor(Math.random() * 256));
    }
    target.value = randomText;  // Überschreiben mit Zufallsdaten
    target.value = '';          // Leeren
  }
}

Browser speichern Formulardaten temporär im Arbeitsspeicher – selbst nach einem Seitenwechsel oder Reset. Diese Funktion überschreibt Passwort- und Schlüssel-Felder vor dem Leeren mit Zufallsdaten, um zu verhindern, dass:

  • Session-Restore-Funktionen (z. B. nach einem Browser-Crash) alte Werte wiederherstellen.
  • Autofill-Systeme oder Erweiterungen die Daten auslesen.
    → Schützt vor: Unbeabsichtigtem Wiederauftauchen sensibler Daten durch Browser-Features.

(RAM-Bereinigung)

function wipeArrayBuffer(buffer) {
  if (!(buffer instanceof Uint8Array)) return;
  for (let i = 0; i < buffer.length; i++) {
    buffer[i] = Math.floor(Math.random() * 256);
  }
}

const privateKeyObj = await openpgp.readPrivateKey({ armoredKey: privateKey });
privateKeyObj.packetList.forEach(packet => {
  if (packet.getBytes) {
    wipeArrayBuffer(packet.getBytes());
  }
});

OpenPGP.js arbeitet intern mit rohen Schlüssel-Daten in Uint8Array-Puffern, die im Arbeitsspeicher (RAM) verbleiben können. Diese Funktion:

  • Überschreibt die Puffer nach der Nutzung mit Zufallsdaten, um 'Memory Scraping'-Angriffe zu erschweren. Da JavaScript keinen direkten Zugriff auf den physischen Speicher hat und der Browser die Speicherverwaltung kontrolliert, ist ein vollständiges Löschen nicht garantiert. Die Maßnahme erhöht jedoch die Hürden für Angreifer:innen deutlich.
  • Nutzt die offizielle OpenPGP.js-API (packetList, getBytes), um alle internen Schlüssel-Fragmente zu bereinigen.
    → Schützt vor: Auslesen von Schlüssel-Daten aus dem RAM durch Malware oder forensische Analysen.

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 versehentlich die Seite schließen, ohne den "Secure-Wipe"-Button zu nutzen. Diese Warnung:

  • Erinnert daran, sensible Daten explizit zu löschen.
  • Verhindert, dass Schlüssel-Daten im Browser-Cache oder Session-Speicher verbleiben.
    → Schützt vor: Unachtsamem Verlassen der Seite mit aktiven Schlüssel-Daten.

13. für OpenPGP.js

openpgp.configure({
  enableWorker: false,
  useWebCrypto: true,
});

Web Worker laufen in separaten Threads und könnten theoretisch:

  • Schlüssel-Daten länger im Speicher halten (auch nach einem Reset).
  • Schwerer zu bereinigen sein als der Haupt-Thread. Durch die Deaktivierung:
  • Laufen alle kryptografischen Operationen im Haupt-Thread ab.
  • Die Kontrolle über den Speicher wird zentralisiert und Secure-Wipe-Maßnahmen sind effektiver.
    → Schützt vor: Unkontrollierter Speicherung von Schlüssel-Daten in Worker-Threads.

14. Keine globalen Schlüssel-Objekte

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

Globale Variablen (z. B. window.privateKey) bleiben bis zum Schließen des Tabs im Speicher. Durch lokale Speicherung:

  • Werden Schlüssel-Daten automatisch bereinigt, sobald die Funktion endet.
  • Ist der Code weniger anfällig für Memory-Leaks oder Angriffe, die globale Variablen auslesen. → Schützt vor: Langfristigem Verbleiben von Schlüssel-Daten im Browser-Speicher.

15. Bereinigung von OpenPGP.js-internen Speicherpuffern

OpenPGP.js speichert sensible Daten nicht nur in sichtbaren DOM-Elementen (wie <textarea>-Feldern), sondern auch in internen JavaScript-Objekten und Puffern, die für Nutzer:innen unsichtbar bleiben. Diese müssen explizit bereinigt werden, um . Hier die Umsetzung:

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(); // Bereinigung nach dem Export
}

Die Funktion wird automatisch aufgerufen:

  • Nach jedem Export (öffentlich/privat/ZIP),
  • Beim Zurücksetzen der Felder ("Secure-Wipe").

OpenPGP.js speichert sensible Daten nicht nur im DOM (z. B. in <textarea>-Feldern), sondern auch in internen JavaScript-Objekten und Puffern, die für Nutzer:innen unsichtbar sind. Dazu gehören:

  • privateKeyObj.packetList: Enthält die rohen Schlüsseldaten im Arbeitsspeicher (RAM) – selbst wenn das <textarea> bereits geleert wurde.
  • openpgp.config: Kann Passwort-Fragmente oder Schlüsselparameter zwischenspeichern, die bei der Generierung oder Entschlüsselung verwendet wurden.
  • Globale Variablen: Falls temporäre Objekte wie window.tmpPrivateKey existieren, bleiben sie bis zum Schließen des Tabs im Speicher – selbst nach einem Seitenwechsel.

Risiko ohne Bereinigung:

Ein Angreifer könnte über eine XSS-Schwachstelle oder ein Browser-Exploit (z. B. ) auf diese JavaScript-Objekte zugreifen und:

  • Private Schlüssel aus den internen Puffern von OpenPGP.js extrahieren,
  • ,
  • Globale Objekte auslesen, die versehentlich sensible Daten enthalten.

Wie die Bereinigung funktioniert:

Die Funktion wipeOpenPGPObjects() wird automatisch aufgerufen:

  • Nach jedem Export (öffentlich/privat/ZIP): Sobald der Nutzer einen Schlüssel herunterlädt, werden alle internen Puffer und Caches gelöscht – selbst wenn die Seite weiter genutzt wird.
  • Beim Zurücksetzen der Felder ("Secure-Wipe"): Wenn der Nutzer auf "Felder zurücksetzen" klickt, wird sowohl das DOM als auch der OpenPGP.js-Speicher bereinigt.

Ergänzung zu secureWipe:

Deine bestehende secureWipe-Funktion löscht nur DOM-Elemente (z. B. <textarea> oder <input>). Die neue Funktion ergänzt dies, indem sie auch die unsichtbaren OpenPGP.js-internen Daten bereinigt – für eine .

16. Keine externen Abhängigkeiten

100% lokale Ressourcen – kein CDN, keine Third-Party-Skripte. Viele Websites laden Bibliotheken (z. B. jQuery) oder Schriften (z. B. Google Fonts) von externen Servern. Das ist ein Sicherheitsrisiko:

  • Externe Server könnten manipuliert werden
  • Verbindungen zu Dritten könnten Tracking oder Datenleaks ermöglichen. Dieser Generator lädt nichts von außen – selbst die verwendete PGP-Bibliothek (OpenPGP.js) ist eine lokal eingebettete, unveränderte Version von openpgpjs.org, die du selbst prüfen kannst. So bleibt alles transparent und nachvollziehbar.

17. Offline-Fähigkeit

Der Generator arbeitet – ohne Internetverbindung oder Serverkommunikation. Das bedeutet:

  • Keine Daten werden übertragen (weder beim Laden noch während der Nutzung)
  • Alle Abhängigkeiten (PGP-Bibliothek OpenPGP.js, ZIP-Funktionalität JSZip.js) sind direkt im Code eingebettet und werden nicht nachgeladen
  • Keine Abhängigkeit von externen Servern – funktioniert auch bei einem globalen Netzausfall oder in . → Ideal für Nutzer:innen mit höchsten Sicherheitsanforderungen oder ohne Internetzugang

Post-Quantum-Kryptografie (PQC)

Aktuelle PGP-Verfahren (RSA und ECC wie Curve25519) gelten als nicht quantenresistent, da sie durch gebrochen werden können – sobald . Es besteht momentan : Aktuelle Quantencomputer haben nicht die nötige Rechenleistung, um PGP-Schlüssel zu knacken. ECC (z. B. Curve25519) und RSA-4096 bieten jedoch eine höhere Sicherheitsmarge als ältere Verfahren (z. B. RSA-2048).

Die OpenPGP-Community standardisiert derzeit post-quantum-sichere Algorithmen (z. B. Kyber-768 für Schlüsselvereinbarung, Dilithium3 für Signaturen) im IETF-Draft: OpenPGP mit PQC. Diese bieten Sicherheit gegen Quantencomputer und sind .

Sobald die Standards verfügbar und in OpenPGP.js implementiert sind, werde ich diesen Generator umgehend aktualisieren, um post-quantum-sichere Schlüssel zu unterstützen.

Fazit – Kontrolle behalten, nicht blind vertrauen

Mit diesem Generator übernimmst du die volle Kontrolle über deine digitale Privatsphäre: Dein Schlüsselpaar entsteht lokal, ohne Server oder Datenabfluss – und jeder Schritt ist transparent nachprüfbar. Du musst nicht blind vertrauen, sondern kannst selbst prüfen, was passiert. Besonders wichtig: Nur durch Verschlüsselung – ob für E-Mails oder Dateien im Ruhezustand – bleibst du .

Probiere ihn direkt aus: PGP-Keygen