Wie Verschlüsselungsschlüssel funktionieren: Basis der Sicherheit

Ein Verschlüsselungsschlüssel ist eine Zeichenkette zufälliger Bits, die Daten sperrt und entsperrt. Bei modernen Dateiübertragungen ist das typischerweise ein 256-Bit-AES-Schlüssel — 32 Bytes Zufallsdaten, generiert von einem kryptografisch sicheren Zufallszahlengenerator (CSPRNG). Derselbe Algorithmus, der ein 10-GB-Video in Chiffretext verwandelt, kann es nur mit dem exakt gleichen Schlüssel entschlüsseln. Schlüsselsicherheit ist der Kern jeder Verschlüsselung: Eine perfekte AES-256-Chiffre ist wertlos, wenn der Schlüssel schwach, vorhersehbar oder kompromittiert ist. Dieser Artikel erläutert, wie Schlüssel in echten Diensten wie HexaTransfer, Tresorit und Proton Drive erzeugt, ausgetauscht, gespeichert und vernichtet werden.

Schlüssel sind einfach Zufallszahlen

Ein 256-Bit-Schlüssel sind 32 Bytes. Im Browser generiert sieht er so aus:

const key = crypto.getRandomValues(new Uint8Array(32));
// Uint8Array(32) [183, 45, 201, 77, ...]

Was ihn zu einem „Schlüssel" macht, ist die Art, wie ein Algorithmus ihn verwendet. AES-256-GCM nimmt einen 256-Bit-Schlüssel, erweitert ihn über einen Key-Schedule zu 15 Rundenschlüsseln und nutzt diese, um 128-Bit-Blöcke über 14 Runden zu verschlüsseln. Die Mathematik interessiert sich nicht für die Herkunft der Bits — sie verlangt nur, dass sie geheim und nicht vorhersehbar sind.

„Nicht vorhersehbar" ist die schwierigere Hälfte. Wenn ein Angreifer den Zustand Ihres Zufallszahlengenerators erraten kann, kann er Ihren Schlüssel reproduzieren. Der Debian-OpenSSL-Fehler von 2006 reduzierte die Schlüssel-Entropie zwei Jahre lang auf 15 Bit — ein Lehrbuchbeispiel dafür, was passiert, wenn Zufälligkeit versagt.

Kryptografisch sichere Zufälligkeit

Browser stellen crypto.getRandomValues() bereit, das vom OS-CSPRNG zieht: /dev/urandom unter Linux, BCryptGenRandom unter Windows, SecRandomCopyBytes unter macOS. Diese mischen wiederum mehrere Entropiequellen — Interrupt-Timings, Festplatten-Seek-Zeiten, Hardware-RNG-Chips wie Intels RDRAND.

Verwenden Sie Math.random() nicht für Schlüssel. Es handelt sich um einen vorhersehbaren Mersenne-Twister, dessen Zustand oft aus wenigen Ausgaben rekonstruiert werden kann.

Serverseitig sind crypto.randomBytes() in Node.js und secrets.token_bytes() in Python sichere Wrapper um den OS-CSPRNG. Die NIST-Standards SP 800-90A und SP 800-90B definieren CSPRNG-Anforderungen; der Linux-Kernel ab Version 5.17 nutzt ein BLAKE2s-basiertes Design, das diese erfüllt.

Symmetrische Schlüssel: ein Schlüssel, zwei Richtungen

Symmetrische Algorithmen wie AES verwenden einen einzigen Schlüssel für Ver- und Entschlüsselung. Die Schlüsselgrößen im Überblick:

128 Bit — 2^128 mögliche Werte, für die meisten Zwecke sicher, von der NSA für SECRET zugelassen.
192 Bit — selten, in bestimmten Regierungskontexten genutzt.
256 Bit — 2^256 Werte, für TOP SECRET zugelassen, aktueller Standard bei Dateiübertragungsdiensten.

Eine Verdopplung der Schlüsselgröße verdoppelt die Brute-Force-Schwierigkeit nicht — sie quadriert sie. 2^128 liegt bereits jenseits jeder Reichweite (das Alter des Universums mal zehn Milliarden mit allen Computern der Erde). 256 Bit ist eine Absicherung gegen Quantencomputer, bei denen Grovers Algorithmus die effektive Stärke symmetrischer Schlüssel halbiert.

Das eigentliche Problem symmetrischer Schlüssel: den gleichen Schlüssel an beide Parteien zu übertragen, ohne dass jemand ihn abfängt.

Asymmetrische Schlüssel: der Schlüsselpaar-Trick

Public-Key-Kryptografie löst das Schlüsselverteilungsproblem. Jede Partei generiert ein mathematisch verknüpftes Schlüsselpaar: einen öffentlichen Schlüssel (frei teilbar) und einen privaten Schlüssel (geheim). Alles, was mit dem öffentlichen Schlüssel verschlüsselt wurde, kann nur mit dem privaten Schlüssel entschlüsselt werden.

Gängige asymmetrische Schlüsseltypen:

RSA-2048 — 2048-Bit-Modulus, weit verbreitet, langsam. Wird in TLS-Zertifikaten verwendet.
RSA-4096 — stärker, noch langsamer.
Curve25519 (X25519) — 256-Bit-Elliptik-Kurven-Schlüssel, schnell, genutzt von Signal und WireGuard.
Ed25519 — 256-Bit-Signaturschlüssel, verwendet von SSH und Git-Commit-Signierung.

Der private Schlüssel allein umfasst 32–512 Bytes je nach Algorithmus. RSA-Private-Keys sind größer, da sie mehrere Primzahlen enthalten; Curve25519-Private-Keys sind nur 32 zufällige Bytes.

Hybridverschlüsselung: das Beste aus beiden Welten

Kein praktisches System verschlüsselt große Dateien direkt mit RSA. Stattdessen nutzen alle ernstzunehmenden Protokolle — TLS, PGP, Age, Signal, jeder seriöse Dateiübertragungsdienst — hybride Verschlüsselung:

Einen zufälligen 256-Bit-AES-Schlüssel generieren („Sitzungsschlüssel" oder „Dateischlüssel").
Die Datei mit AES-256-GCM verschlüsseln.
Den Sitzungsschlüssel mit dem öffentlichen Schlüssel des Empfängers verschlüsseln.
Beides übertragen.

Der Empfänger entschlüsselt den Sitzungsschlüssel mit seinem privaten Schlüssel und nutzt ihn dann zur Dateienschlüsselung. Sie erhalten die Geschwindigkeit symmetrischer Verschlüsselung und den Schlüsselverteilungskomfort asymmetrischer Kryptografie.

Bei browserbasierten Dateiübertragungen ersetzt das URL-Fragment oft den „öffentlichen Schlüssel": Der Sender generiert einen Sitzungsschlüssel, bettet ihn nach # in die URL ein, und der Browser des Empfängers liest ihn lokal. Einfacher — und funktioniert ohne ein Schlüsselpaar beim Empfänger.

Schlüssel aus Passwörtern ableiten

Nutzer tippen Passwörter; Algorithmen benötigen gleichmäßige Zufallsbits. Eine Key Derivation Function (KDF) überbrückt das:

PBKDF2-HMAC-SHA-256 — iteriert eine Hash-Funktion. OWASP 2023 empfiehlt 600.000 Iterationen. In der Web Crypto API verfügbar.
scrypt — speicherintensiv, widersteht GPU-Angriffen. Parameter: N=2^17, r=8, p=1.
Argon2id — aktuelle Best Practice, Gewinner des Password Hashing Competition 2015. Parameter: memory=64 MB, iterations=3, parallelism=4.

Eine KDF fügt einen Salt (zufällig, neben dem Chiffretext gespeichert) und einen Arbeitsfaktor (Iterationen) hinzu, um Brute Force zu verlangsamen. Ein 12-stelliges Zufallspasswort durch Argon2id mit 64 MB Speicher dauert eine GPU-Farm Tausende von Jahren, um es zu erschöpfen. Ein schwaches Passwort wie Sommer2024 fällt unabhängig von der KDF in Sekunden — die KDF kann keine Entropie hinzufügen, die nicht vorhanden war.

Schlüsselspeicherung: wo Schlüssel leben

Schlüssel müssen irgendwo existieren, und dieser Ort ist eine sicherheitskritische Entscheidung:

Browser-Arbeitsspeicher (nur Sitzung). Standard für flüchtige Dateiübertragungen. Schlüssel wird generiert, verwendet und beim Schließen der Seite verworfen.
URL-Fragment. Über den Link geteilt, im Browser-Verlauf des Empfängers gespeichert. Begrenzte Lebensdauer ist wichtig.
Local Storage / IndexedDB. Persistent, aber für jedes JavaScript auf dem Origin zugänglich. Riskant ohne weitere Verschlüsselung.
OS-Schlüsselbund — macOS Keychain, Windows DPAPI, Linux libsecret. Auf manchen Plattformen hardware-gestützt.
Hardware Security Module (HSM) — YubiKey, Cloud-HSM (AWS CloudHSM, Azure Dedicated HSM). Schlüssel verlassen die Hardware nie.
Key Management Service (KMS) — AWS KMS, Google Cloud KMS, HashiCorp Vault. Zentral, auditierbar, etwa 1 $/Schlüssel/Monat.

Bei Zero-Knowledge-Dateiübertragungen lebt der Schlüssel im URL-Fragment und im Browser des Senders. Der Server speichert ihn nie.

Schlüsselrotation und -vernichtung

Langlebige Schlüssel häufen Risiko an. Best Practice ist Rotation:

TLS-Zertifikate: 90-Tage-Rotation (Let's Encrypt Standard), maximal 398 Tage für öffentliche CAs seit 2020.
Datenverschlüsselungsschlüssel: typischerweise alle 90 Tage bis 1 Jahr in konformen Systemen (PCI DSS 4.0 Anforderung 3.6).
Master-Schlüssel: jährlich oder bei Personalwechsel rotiert.

Vernichtung ist ebenfalls entscheidend. Das einfache Löschen von Schlüsseldateien reicht nicht — SSDs können Daten in Wear-Leveling-Bereichen aufbewahren. Sichere Vernichtung erfordert Überschreiben oder dedizierte HSM-Löschbefehle. Kryptografische Löschung — den Schlüssel wegwerfen, sodass die verschlüsselten Daten dauerhaft unlesbar werden — ist für Massendaten oft der sauberste Ansatz.

Dateiübertragungsdienste nutzen typischerweise dateispezifische Schlüssel, die nur für die Lebensdauer der Übertragung existieren (24 Stunden bis 7 Tage) und zusammen mit dem Chiffretext beim Ablauf verworfen werden.

Schwache Schlüsselpraktiken erkennen

Drei häufige Fehler, auf die Sie achten sollten:

Im Client-Code fest hinterkodierte Schlüssel. Wenn der Schlüssel für jeden Nutzer gleich ist, ist er kein Schlüssel — es ist Verschleierung.
Schlüssel neben dem Chiffretext auf demselben Server oder in derselben Datenbank gespeichert. Eine Datenverletzung legt beides offen.
Keine Schlüsselrotation. Legacy-Systeme mit jahrzehntealten Verschlüsselungsschlüsseln tragen etwa ein Jahrzehnt angesammeltes Verletzungsrisiko.

Ein seriöser Dienst veröffentlicht ein kryptografisches Whitepaper zu Schlüsselgenerierung, -speicherung, -rotation und -vernichtung — und lässt sich von Drittparteien wie Cure53 oder Trail of Bits prüfen.

In der Praxis anwenden

Für sensible Dateifreigaben: Wählen Sie einen Dienst, der 256-Bit-Schlüssel clientseitig via crypto.getRandomValues() generiert, sie ausschließlich im URL-Fragment einbettet (nie an den Server sendet), passwortabgeleitete Schlüssel via PBKDF2 oder Argon2id unterstützt und sowohl Schlüssel als auch Chiffretext innerhalb von 24 Stunden automatisch ablaufen lässt.

Auf hexatransfer.com testen — kostenlos, ohne Konto, bis 10 GB.