Browser-Verschlüsselungsfähigkeiten: was moderne Browser können

Moderne Browser liefern native Kryptografie, die dedizierten Sicherheitsbibliotheken ebenbürtig ist. Chrome, Firefox, Safari und Edge stellen alle die Web Crypto API (crypto.subtle) bereit, implementieren TLS 1.3 mit Zertifikat-Pinning-Mechanismen als HPKP-Nachfolger, unterstützen WebAuthn/Passkeys für phishing-resistente Authentifizierung, isolieren jeden Ursprung mit Site Isolation und bieten hardware-gesicherter Schlüsselspeicherung über das Trusted Platform Module unter Windows und die Secure Enclave unter macOS/iOS. Für Entwickler von verschlüsselten Dateiübertragungstools bedeutet das: AES-256-GCM-Verschlüsselung, PBKDF2-Schlüsselableitung und FIDO2-Authentifizierung sind kostenlos verfügbar, ohne externe Bibliothek. Was jeder Browser 2026 tatsächlich kann, folgt hier.

Web Crypto API: Die gemeinsame Basis

Alle vier großen Browser unterstützen die W3C Web Cryptography API mit nahezu identischer Oberfläche. Die Kernalgorithmen:

• Symmetrisch: AES-GCM, AES-CBC, AES-CTR, AES-KW (128, 192, 256-Bit)
• Asymmetrisch: RSA-OAEP, RSA-PSS, RSASSA-PKCS1-v1_5 (bis 4096-Bit), ECDSA und ECDH (P-256, P-384, P-521)
• Hashing: SHA-1, SHA-256, SHA-384, SHA-512
• Schlüsselableitung: PBKDF2, HKDF
• MAC: HMAC

Was fehlt: ChaCha20-Poly1305 (kein Browser-Support), Argon2 (kein Browser-Support), Ed25519/X25519 (Safari 17+ und Firefox 129+ haben es, Chrome holt auf). Dafür sind weiterhin JavaScript- oder WASM-Bibliotheken wie libsodium.js oder @noble/curves nötig.

Chrome und Edge teilen dieselbe Krypto-Implementierung (BoringSSL via V8). Firefox verwendet NSS. Safari nutzt CoreCrypto, Apples FIPS-validierte Bibliothek. Die Leistung variiert: Firefoxs PBKDF2-Iterationen laufen auf vergleichbarer Hardware etwa 20 % langsamer als Chrome; Safaris AES-GCM mit Hardware-Beschleunigung auf Apple Silicon ist auf demselben Mac etwa doppelt so schnell wie Chrome.

TLS 1.3 und Certificate Transparency

Jeder große Browser verwendet standardmäßig TLS 1.3 auf unterstützten Ursprüngen und fällt nur bei Legacy-Servern auf 1.2 zurück. Chrome entfernte TLS-1.0- und TLS-1.1-Unterstützung in Chrome 84 (Juli 2020). Firefox entfernte sie in Firefox 78. Safari gab sie in macOS 11 / iOS 14 auf.

Certificate Transparency wird durchgesetzt: Zertifikate, die nach April 2018 ausgestellt wurden, müssen in mindestens zwei CT-Protokollen erscheinen, sonst lehnen Chrome und Safari sie ab. Das fing DigiNotar-ähnliche Angriffe früh ab, indem CA-Fehlausstellungen öffentlich prüfbar gemacht wurden. Mozilla Firefox begann mit der CT-Durchsetzung in Firefox 117 (2023).

Public-Key-Pinning über den HPKP-Header wurde abgekündigt (Chrome 72 entfernte die Unterstützung), weil es Sperrangriffe ermöglichte. Expect-CT-Header dienten demselben Überwachungszweck und werden selbst schrittweise abgelöst, da CT nun verpflichtend ist. Unternehmen, die Pinning benötigen, können es noch über vertrauenswürdige Root-Pinning in verwalteten Konfigurationen (MDM unter macOS, Chrome Enterprise-Richtlinien) nutzen.

Ursprungsisolation und Sandboxing

Chromes Site Isolation legt jeden Ursprung seit 2018 (Desktop) und 2019 (Android) in seinen eigenen OS-Prozess. Firefoxs Fission erreicht dasselbe seit Firefox 94. Safari verwendet WebKits Pro-Prozess-Modell. Was das für Verschlüsselung bedeutet: Ein bösartiges Cross-Origin-Skript kann Ihre entschlüsselte Datei nicht aus dem Speicher eines benachbarten Tabs lesen, weil dieser in einem anderen Prozess mit eigenem Heap lebt.

Cross-Origin-Opener-Policy (COOP), Cross-Origin-Embedder-Policy (COEP) und Cross-Origin-Resource-Policy (CORP) lassen Seiten sich für noch strengere Isolation entscheiden. Das Setzen von Cross-Origin-Opener-Policy: same-origin und Cross-Origin-Embedder-Policy: require-corp aktiviert Cross-Origin-Isolation, die wiederum SharedArrayBuffer und hochauflösende Timer freischaltet. Relevant für Krypto, weil Spectre-ähnliche Timing-Angriffe gegen AES-Implementierungen gemildert werden, wenn der Angreifer keinen SAB in Ihrem Ursprung öffnen kann.

WebAuthn und Passkeys für Authentifizierung

FIDO2 WebAuthn wird in Chrome 67+, Firefox 60+, Safari 14+ und Edge 18+ unterstützt. Es ermöglicht Anwendungen, Nutzende über Hardware-Schlüssel (YubiKey, Titan), Plattform-Authenticatoren (Face ID, Windows Hello, Android Biometrie) oder Passkeys zu authentifizieren, die über iCloud Keychain, Google Password Manager oder 1Password zwischen Geräten synchronisiert werden.

Für eine Dateiübertragungsanwendung ersetzt WebAuthn Passwörter als Faktor, der den Zugang zu einem gespeicherten Share-Link schützt. Entscheidend ist: WebAuthn ist phishing-resistent, da die Signatur an den Ursprung gebunden ist und eine Look-alike-Domain keine Zugangsdaten abfangen kann. Chrome und Safari wechselten 2023–2024 zu Passkey-first-Flows und ließen die Anforderung eines physischen Schlüssels für die meisten Verbraucheranwendungen fallen.

Hardware-gesicherter Schlüsselspeicher

Unter Windows kann der TPM-2.0-Chip (verpflichtend unter Windows 11) Web-Crypto-Schlüssel speichern, die als nicht extrahierbar über die Windows-CNG-Bridge erzeugt wurden. Unter macOS und iOS hält die Secure Enclave Schlüssel für Face ID, Touch ID und Passkeys. Unter Android bietet der Keystore, gestützt durch StrongBox (Hardware) oder TEE (Trusted Execution Environment), ähnlichen Schutz.

Was das praktisch bedeutet: Ein über Web Crypto als extractable: false erzeugter Schlüssel auf einem modernen Laptop kann im TPM oder der Secure Enclave leben, nicht im Hauptspeicher. Selbst ein vollständiger Browser-Exploit, der JavaScript-Speicher ausgibt, liefert die rohen Schlüsselbytes nicht. Für Dateiübertragungstools ist das am nützlichsten für langlebige Empfängerschlüssel; ephemere Datei-AES-Schlüssel brauchen diesen Schutz nicht.

Content Security Policy als Krypto-Multiplikator

Verschlüsselung ist wertlos, wenn ein bösartiges Skript den Klartext lesen kann, bevor er verschlüsselt wird. Content-Security-Policy-Header lassen eine Seite erklären, welche Skripte ausgeführt werden dürfen. Eine strenge Richtlinie wie:

Content-Security-Policy: default-src 'self'; script-src 'self' 'strict-dynamic' 'nonce-abc123';

blockiert Inline-Skripte und Drittanbieter-Code und lässt keine Angriffsfläche für eingeschleuste krypto-stehlende Payloads. Alle wichtigen Browser unterstützen CSP Level 3. Für Dateiübertragungsanwendungen CSP mit Subresource Integrity (SRI) auf externen Skripten kombinieren, um sicherzustellen, dass auch erlaubtes Drittanbieter-JS nicht manipuliert wurde.

File System Access und OPFS

Die File System Access API (Chrome 86+, Edge 86+, partiell Safari 15.2+ via Origin Private File System) erlaubt Web-Apps das Lesen und Schreiben lokaler Dateien mit Nutzerberechtigung. Das Origin Private File System ist besonders relevant für Verschlüsselung: Es ist ein privates Dateisystem pro Ursprung, browserverwaltet, zum Staging großer verschlüsselter Payloads vor dem Upload — ohne alles in den Speicher zu laden.

Firefox war bei der Einführung von FSA langsamer, unterstützt aber OPFS seit Firefox 111. Safari unterstützt OPFS durchgehend, verhält sich aber bei der breiteren File System Access API restriktiver.

Was Browser noch nicht gut können

Einige Lücken bleiben:

• Argon2-Schlüsselableitung fehlt in Web Crypto. WASM-Bibliotheken für Passwort-Hashing über PBKDF2 hinaus verwenden.
• ChaCha20-Poly1305 ist nicht verfügbar. AES-GCM deckt die meisten Anforderungen ab, ChaCha würde auf Geräten ohne AES-NI (älteres ARM) helfen.
• Schlüsselattestierung für hardware-gesicherte Schlüssel ist begrenzt. WebAuthn bietet Attestierung; die breitere Web Crypto API nicht.
• Streaming-AEAD ist noch nicht Teil der Spec. Große Dateiverschlüsselung erfordert Chunking-Logik oder WASM.
• Post-Quanten-Algorithmen (Kyber, Dilithium) sind noch nicht im Browser. Google hat Kyber in TLS-Handshakes ausgeliefert (Chrome 116+), aber JavaScript-exponierte Post-Quanten-Krypto ist noch Bibliotheksgebiet.

Was heute für Dateitransfer verwenden

Ein glaubwürdiger browserbasierterer Dateiübertragungsstack 2026:

• AES-256-GCM via crypto.subtle.encrypt für Dateiinhalte
• PBKDF2-SHA-256 mit 600.000 Iterationen für passwortabgeleitete Schlüssel
• crypto.getRandomValues() für Salts und Nonces (niemals Math.random)
• URL-Fragmente (#key=...) zum clientseitigen Schlüsseltransport ohne Serveroffenlegung
• HTTPS mit TLS 1.3 Minimum, HSTS aktiviert, COOP/COEP zur Isolation
• Strikte CSP, keine Inline-Skripte
• WebAuthn Passkeys für gespeicherte Kontofunktionen
• OPFS für Large-File-Staging auf Chrome/Edge/Safari 16+

HexaTransfer betreibt im Wesentlichen diesen Stack. Ebenso SwissTransfer, Tresorit Send, Cryptpad und Proton Drive Share. Die Primitive sind ausgereift und konsistent über Browser hinweg.

Testen über alle Browser

Immer in allen vier testen. Echte Fehler: Firefox wirft OperationError auf PBKDF2-Eingaben, die Chrome stillschweigend akzeptiert. Safaris FileReader ist bei Dateien über 2 GB langsamer. Chromes OPFS-Schreibvorgänge werden in einigen Versionen über 4 GB ge-chunked. WebAuthn-Benutzerverifizierungsaufforderungen unterscheiden sich deutlich (Face ID vs. Touch ID vs. Windows Hello vs. Android Biometrie). BrowserStack, Sauce Labs oder eine lokale Matrix physischer Geräte für Vorab-Tests verwenden.

Browser sind still zu einer der umfangreichsten verfügbaren Krypto-Plattformen geworden. Dieselben standardbasierten Primitive, die Banking-Apps, Passwortmanager und Messaging-Clients antreiben, sind für jeden, der verschlüsselte Dateiübertragungstools entwickelt, mit einem einzigen JavaScript-Aufruf erreichbar.

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