Was ist clientseitige Verschlüsselung? Ihr Browser erledigt die Arbeit

Clientseitige Verschlüsselung bedeutet: Ihr Browser oder Ihre App verschlüsselt Dateien auf Ihrem Gerät, bevor ein einziges Byte das Netz berührt. Der Server empfängt ausschließlich Chiffretext — AES-256-GCM-Ausgabe, die von zufälligem Rauschen nicht zu unterscheiden ist — und der Entschlüsselungsschlüssel verlässt den Client niemals. Das ist das Gegenteil von serverseitiger Verschlüsselung, bei der der Anbieter die Schlüssel hält und Ihre Dateien technisch gesehen lesen könnte. Die Web Crypto API (window.crypto.subtle) macht das in jedem modernen Browser ohne Plugins möglich und erreicht auf AES-NI-Hardware etwa 2–3 GB/s. Dienste wie HexaTransfer, SwissTransfer, Tresorit Send und Proton Drive nutzen dieses Modell, um zu garantieren, dass Dateien privat bleiben — auch wenn der Dienst selbst kompromittiert wird.

Der Browser als kryptografische Engine

Vor fünf Jahren erforderte echte Verschlüsselung eine Desktop-App oder PGP auf der Kommandozeile. Die Web Crypto API, 2017 vom W3C standardisiert, hat das verändert. Sie stellt AES-GCM, RSA-OAEP, ECDH, HMAC, PBKDF2 und SHA-256 direkt für JavaScript bereit — in allen gängigen Browsern: Chrome, Firefox, Safari, Edge.

Performance ist kein Engpass mehr. Intel AES-NI-Instruktionen erreichen 3–5 GB/s pro Kern für AES-256-GCM. ARMs Cryptography Extensions auf Apple-M-Chips und Qualcomm-Snapdragon-Prozessoren liefern vergleichbaren Durchsatz. Eine 1-GB-Datei im Browser zu verschlüsseln dauert auf einem mittleren Laptop etwa 300–500 ms.

Die verbleibende Herausforderung ist das Verarbeiten von Dateien, die größer als der Browser-Arbeitsspeicher sind. Die Streams API und ReadableStream erlauben es, Dateien in 4-MB-Blöcken zu verarbeiten und jeden Block mit einem eindeutigen Counter-Mode-IV zu verschlüsseln. So schieben Dienste die Grenze auf 10 GB und mehr.

Ein minimaler clientseitiger Verschlüsselungsablauf

So sieht eine typische browserbasierte Implementierung aus:

// 1. Zufälligen 256-Bit-AES-Schlüssel generieren
const key = await crypto.subtle.generateKey(
  { name: "AES-GCM", length: 256 }, true, ["encrypt", "decrypt"]
);

// 2. Datei in Blöcken einlesen
const file = fileInput.files[0];
const chunkSize = 4 * 1024 * 1024;

// 3. Jeden Block mit einem eindeutigen 12-Byte-IV verschlüsseln
for (let offset = 0; offset < file.size; offset += chunkSize) {
  const chunk = file.slice(offset, offset + chunkSize);
  const iv = crypto.getRandomValues(new Uint8Array(12));
  const ciphertext = await crypto.subtle.encrypt(
    { name: "AES-GCM", iv }, key, await chunk.arrayBuffer()
  );
  // 4. [iv || ciphertext] zum Server hochladen
}

// 5. Schlüssel exportieren und im Share-URL-Fragment einbetten
const keyBytes = await crypto.subtle.exportKey("raw", key);
const shareUrl = `https://example.com/d/${fileId}#k=${base64url(keyBytes)}`;

Der Server sieht zufällig wirkende Bytes, eine Datei-ID — und nichts weiter. Der Schlüssel existiert nur im Browser-Speicher und im URL-Fragment.

Warum das serverseitige Verschlüsselung übertrumpft

Serverseitige Verschlüsselung bedeutet, dass der Anbieter auf Anfrage entschlüsselt — für Miniaturbilder, Virenscans, Suchanfragen oder Behördenzugriffe. Eine Apple-Offenlegung von 2023 zeigte, dass iCloud-Backups (bis zur Einführung von Advanced Data Protection ohne Ende-zu-Ende-Verschlüsselung) für Apple und damit für US-Strafverfolgungsbehörden mit gültigen Beschlüssen zugänglich waren.

Clientseitige Verschlüsselung dreht das um. Da der Schlüssel den Anbieter nie erreicht:

• Mitarbeiter sehen nichts. Wer Datenbankzugriff hat, erhält nur Chiffretext.
• Durchsuchungsbeschlüsse liefern Chiffretext. Der Anbieter kann Beschlüssen entsprechen, indem er das verschlüsselte Blob herausgibt — ohne den Schlüssel nutzlos.
• Datenlecks geben Chiffretext preis. Der LastPass-Vorfall 2021 zeigt das: Gestohlene Vaults waren verschlüsselt, und nur Nutzer mit schwachen Master-Passwörtern trugen echtes Risiko.
• Anbieterausfälle gefährden keine Daten. Selbst wenn das Unternehmen schließt, entschlüsselt Ihr lokaler Schlüssel (die URL) die Datei noch immer.

Was der Server noch sehen kann

Clientseitige Verschlüsselung schützt den Dateiinhalt, aber nicht alles. Der Server beobachtet typischerweise:

• Dateigröße — die Chiffretext-Länge entspricht annähernd der Klartextlänge (AES-GCM fügt 16 Bytes Overhead plus 12-Byte-IV hinzu).
• Upload- und Download-IP-Adressen mit Zeitstempeln.
• Sitzungs-Metadaten aus TLS-Handshakes einschließlich des TLS-Fingerabdrucks des Clients.
• Verschlüsselte Dateinamen — sofern Dateinamen nicht im verschlüsselten Payload enthalten sind, können sie durchsickern.

Gute clientseitige Dienste verschlüsseln Dateinamen als Teil des Chiffretext-Headers und füllen auf Bucket-Größen auf (1 MB, 10 MB, 100 MB), um die Größe zu verschleiern. Tresorit und Proton Drive dokumentieren ihre Metadaten-Offenlegung explizit.

Passwortgeschützte clientseitige Verschlüsselung

Viele Dienste erlauben das Hinzufügen eines Passworts zusätzlich zum URL-Fragment. Der Ablauf:

1. Der Browser generiert einen zufälligen 128-Bit-Salt und leitet einen Schlüssel via PBKDF2-HMAC-SHA-256 mit 600.000 Iterationen (OWASP-Empfehlung 2023) oder Argon2id mit memory=64 MB, iterations=3 ab.
2. Die Datei wird mit dem abgeleiteten Schlüssel verschlüsselt.
3. Der Salt kommt ins URL-Fragment; das Passwort wird auf einem anderen Kanal übermittelt.
4. Der Empfänger gibt das Passwort ein, der Schlüssel wird lokal neu abgeleitet.

Das verwandelt eine Single-Channel-Freigabe (URL reicht aus) in Zwei-Faktor-Sicherheit: Der Angreifer benötigt sowohl den Link als auch das Passwort. PBKDF2 mit 600.000 Iterationen macht Offline-Brute-Force etwa 10 Sekunden pro Versuch auf einer modernen GPU — Passwörter benötigen über 40 Bit Entropie, um entschlossenen Angreifern standzuhalten.

Der Vertrauenswechsel: vom Dienst zum Client-Code

Clientseitige Verschlüsselung verschiebt die Vertrauensgrenze. Bisher vertrauten Sie dem Dienst beim Umgang mit Ihrem Klartext. Jetzt vertrauen Sie dem JavaScript, das der Dienst bei jedem Seitenaufruf in Ihren Browser liefert. Ein bösartiges Update könnte den Schlüssel vor oder während der Verschlüsselung exfiltrieren.

Drei Gegenmaßnahmen existieren, unterschiedlich in ihrer Strenge:

• Subresource Integrity (SRI) für Script-Tags stellt sicher, dass der JS-Hash einem bekannten Wert entspricht.
• Code-Audits durch Firmen wie Cure53, NCC Group oder Trail of Bits prüfen die Korrektheit der Verschlüsselungslogik.
• Reproduzierbare Builds ermöglichen es unabhängigen Parteien zu bestätigen, dass der ausgelieferte Code mit dem veröffentlichten Quellcode übereinstimmt.
• Content Security Policy (CSP) blockiert Drittanbieter-Scripts, die Verschlüsselung manipulieren könnten.

Der strengste Ansatz — genutzt von Proton Mails pmcrypto und einigen Electron-Clients — liefert signierte Binärdateien statt frischem JavaScript bei jedem Besuch. Browserbasierte Dienste tauschen einen Teil dieser Strenge gegen die Bequemlichkeit ohne Installation.

Szenarien, in denen clientseitige Verschlüsselung überzeugt

Einige Fälle, in denen der leicht langsamere erste Ladevorgang gerechtfertigt ist:

• Rechtliche und medizinische Dokumente. HIPAA 45 CFR § 164.312 und das anwaltliche Berufsgeheimnis profitieren stark von anblinderblinden Architekturen. Die DSGVO Art. 32 schreibt geeignete technische Maßnahmen vor.
• Journalismus und Quellenschutz. Versenden nicht geschwärzter Dokumente, bei denen selbst Metadaten-Offenlegung ein Risiko darstellt.
• Unternehmens-IP. Aufsichtsrats-Unterlagen, Finanzmodelle, M&A-Materialien, bei denen Insider-Bedrohungen beim Dateiübertragungsanbieter realistisch sind.
• Persönliche Unterlagen. Steuerdokumente, Reisepässe, medizinische Befunde — Dateien, die Sie in keiner Datenverletzungs-Schlagzeile sehen wollen.

Für wenig sensible Dateien (ein Meeting-Foto, ein Rezept) ist herkömmliche serverseitige Verschlüsselung ausreichend.

Echte clientseitige Verschlüsselung erkennen

Vier Merkmale, dass ein Dienst tatsächlich clientseitige Verschlüsselung einsetzt:

1. URL-Fragmente enthalten einen Schlüssel. Die Share-URL enthält Text nach #, der wie base64-kodierte Zufallsbytes aussieht.
2. Uploads sind Chiffretext. DevTools → Netzwerk während des Uploads öffnen; der Request-Body sollte wie zufällige Bytes aussehen, nicht wie Ihr Dateiname.
3. Große Dateien funktionieren trotzdem schnell. Ein echter clientseitiger Flow streamt Blöcke; er leitet nicht zu einem serverseitigen Verschlüsselungs-Gateway um.
4. Die Datenschutzrichtlinie sagt: „Wir können Ihre Dateien nicht entschlüsseln." Gepaart mit einem technischen Whitepaper, nicht nur Marketing.

Dienste, die bestehen: SwissTransfer E2EE-Tier, Tresorit Send, Proton Drive Shared Links, Mega.nz und HexaTransfer. Dienste, die nicht bestehen: WeTransfer (Standard), Google Drive, Dropbox-Freigabelinks.

Ausprobieren

Wenn Sie clientseitige Verschlüsselung selbst testen möchten: Öffnen Sie DevTools und beobachten Sie den Netzwerk-Tab während eines Datei-Uploads. Sie sollten ein verschlüsseltes Blob zum Server sehen und einen Schlüssel in Ihrer URL-Leiste, der in keiner Anfrage erscheint. Das ist das vollständige Versprechen.

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