JavaScript-Verschlüsselungsbibliotheken: Top-Auswahl für Entwickler

Die besten JavaScript-Verschlüsselungsbibliotheken für Dateiübertragungsarbeit 2026 sind libsodium.js für breite Abdeckung und WASM-Geschwindigkeit, @noble/ciphers und @noble/curves für reines JS mit modernen Audits, tweetnacl für kleine Bundle-Größe mit NaCl-kompatiblen Primitiven, crypto-js für Legacy-Kompatibilität (für neuen Code vermeiden) und die native Web Crypto API für alles, was sie unterstützt. Dieser Guide vergleicht sie nach Algorithmenabdeckung, Bundle-Größe, Audit-Geschichte, Browser- vs. Node-Kompatibilität und realer Leistung bei Dateiverschlüsselung. Die richtige Wahl hängt davon ab, ob Sie für Browser entwickeln, auf Node aufbauen, ChaCha20-Poly1305 oder Argon2 benötigen oder innerhalb der Web-Crypto-Grenzen leben können.

Vergleichstabelle

| Bibliothek | Größe (gzip) | Backend | Schlüssel-Algorithmen | Auditiert | Modern? | |---|---|---|---|---|---| | Web Crypto API | 0 KB (nativ) | Browser-nativ | AES-GCM, PBKDF2, RSA, ECDH, HMAC | Ja (durch Browser-Anbieter) | Ja, aber kein ChaCha/Argon2 | | libsodium.js | 200 KB WASM / 400 KB JS | WASM + JS-Fallback | Alles in libsodium | Ja (mehrfach) | Ja | | @noble/ciphers | 8 KB | Reines JS | AES, ChaCha20, Poly1305, GCM-SIV | Ja (Cure53 2023) | Ja | | @noble/curves | 35 KB | Reines JS | Ed25519, X25519, secp256k1, BLS | Ja (Trail of Bits, Cure53) | Ja | | tweetnacl | 15 KB | Reines JS | Curve25519, Ed25519, XSalsa20-Poly1305 | Ja (ursprüngliches NaCl-Audit) | Größtenteils, kein ChaCha20 | | crypto-js | 50 KB | Reines JS | AES-CBC, SHA, HMAC, PBKDF2 | Kein aktuelles Audit | Nein, seit 2023 nicht mehr gepflegt | | node:crypto | 0 KB (Node-nativ) | Node-nativ (OpenSSL) | Umfassend | Ja (OpenSSL) | Ja |

libsodium.js: Das Schweizer Taschenmesser

libsodium.js (der Emscripten-kompilierte Build von libsodium) ist die Standardwahl, wenn Web Crypto nicht ausreicht. Es deckt XChaCha20-Poly1305, Ed25519, X25519, Argon2id, BLAKE2b und die crypto_secretstream-API für Streaming-AEAD ab. Der WASM-Build läuft auf typischer Hardware mit etwa 50–70 % der nativen libsodium-Geschwindigkeit.

import _sodium from 'libsodium-wrappers';
await _sodium.ready;
const sodium = _sodium;

const key = sodium.crypto_secretstream_xchacha20poly1305_keygen();
const { state, header } = sodium.crypto_secretstream_xchacha20poly1305_init_push(key);
const chunk = sodium.crypto_secretstream_xchacha20poly1305_push(
  state, new Uint8Array([1,2,3]), null,
  sodium.crypto_secretstream_xchacha20poly1305_TAG_MESSAGE
);

Die Streaming-API ist das Killerfeature für große Dateiübertragungen. Eine 5-GB-Datei kann Chunk für Chunk verschlüsselt werden, ohne sie vollständig in den Speicher zu laden, und jeder Chunk trägt sein eigenes Authentifizierungs-Tag, sodass Korruption per Chunk erkannt wird, nicht nur am Ende.

Kompromisse: 200 KB WASM sind viel zum Ausliefern. Dynamische Imports verwenden (await import('libsodium-wrappers')), damit die Bibliothek nur lädt, wenn Verschlüsselung tatsächlich benötigt wird. Der Sumo-Build (enthält alle Algorithmen) ist 600 KB+; beim Standard-Build bleiben, sofern die Extras nicht gebraucht werden.

@noble: Klein, auditiert, modern

Paul Millers @noble-Familie (@noble/ciphers, @noble/curves, @noble/hashes) ist derzeit das Beste in seiner Klasse für reines JavaScript. Auditiert von Cure53 (ciphers, 2023) und Trail of Bits (curves, 2022), keine Abhängigkeiten, tree-shakeable, TypeScript-nativ.

import { gcm } from '@noble/ciphers/aes';
import { randomBytes } from '@noble/ciphers/webcrypto';

const key = randomBytes(32);
const nonce = randomBytes(12);
const ciphertext = gcm(key, nonce).encrypt(plaintext);

@noble verwendet kein WASM, daher ist der Bundle-Einfluss gering (8 KB für ciphers). Die Leistung ist 30–50 % langsamer als libsodiums WASM für AES-GCM in Masse, aber für die meisten Transferszenarien ausreichend. Der reine JS-Ansatz bedeutet auch, dass es in Browsern, Node, Deno, Bun und React Native ohne native Modulprobleme identisch funktioniert.

@noble verwenden, wenn die Bundle-Größe wichtig ist, eine tree-shakeable reine JS-Bibliothek gewünscht wird oder auf einer Plattform gearbeitet wird, auf der WASM Tücken hat.

tweetnacl: Der Minimalist

tweetnacl-js portiert Daniel J. Bernsteins TweetNaCl C-Bibliothek nach JavaScript. 15 KB gzip. Deckt Curve25519-Schlüsselaustausch, Ed25519-Signaturen und XSalsa20-Poly1305-authentifizierte Verschlüsselung ab. Als Teil des ursprünglichen NaCl-Vorhabens auditiert, wenn auch nicht kürzlich.

import nacl from 'tweetnacl';

const key = nacl.randomBytes(32);
const nonce = nacl.randomBytes(24);
const ciphertext = nacl.secretbox(plaintext, nonce, key);

Die API ist absichtlich winzig: Wenn mehr als das gebraucht wird, was NaCl bietet (z. B. AES-GCM für Interop mit Nicht-JS-Systemen), woanders schauen. Für reine NaCl-Protokoll-Apps ist tweetnacl noch eine vernünftige Wahl, obwohl @noble/ciphers plus @noble/curves dasselbe Terrain mit aktuellerer Pflege abdeckt.

crypto-js: Für neuen Code nicht verwenden

crypto-js dominierte Browser-Krypto 2015. 2026 ist es eine Haftung. Letzter bedeutender Release war 2021 (4.1.1); das Repository wurde 2023 effektiv archiviert. Es verwendet standardmäßig AES-CBC mit einer unsicheren Schlüsselableitung aus Passwörtern (OpenSSLs EVP_BytesToKey-ähnliches Schema), das Schlüssel über wenige MD5-Runden ableitet. CVE-2023-46233 markierte schwache PBKDF2-Standards.

Bei der Pflege von Legacy-Code, der crypto-js verwendet, ist die Migration zu @noble/ciphers oder Web Crypto einfach und den Aufwand wert. Beim Start von neuem Code 2026 crypto-js vollständig übergehen.

node:crypto für Server-Code

Nodes eingebautes crypto-Modul umhüllt OpenSSL und hat die breiteste Algorithmenabdeckung von allem auf dieser Liste. Ab Node 18 stellt require('crypto').webcrypto eine Web-Crypto-kompatible API bereit, sodass isomorpher Code auf Server und Client funktioniert.

import { createCipheriv, randomBytes } from 'crypto';

const key = randomBytes(32);
const iv = randomBytes(12);
const cipher = createCipheriv('aes-256-gcm', key, iv);
const ct = Buffer.concat([cipher.update(plaintext), cipher.final()]);
const tag = cipher.getAuthTag();

Für serverseitige Entschlüsselung von Web-Crypto-verschlüsselten Dateien ist das der sauberste Weg. Wenn der Dateiübertragungsdienst serverseitig entschlüsselt (selten bei Zero-Knowledge-Designs, aber üblich bei Legacy-Systemen, die auf Verschlüsselung migrieren), node:crypto verwenden.

Leistung bei realer Dateiverschlüsselung

Benchmarks auf einem MacBook Air M2 beim Verschlüsseln eines 100-MB-Buffers mit AES-256-GCM:

• Web Crypto API (Chrome 120): 340 ms (hardware-beschleunigt)
• Web Crypto API (Safari 17): 280 ms (hardware-beschleunigt auf Apple Silicon)
• libsodium.js WASM: 420 ms
• @noble/ciphers: 1.850 ms (keine Hardware-Beschleunigung in reinem JS)
• tweetnacl (XSalsa20): 1.200 ms
• node:crypto: 180 ms (natives OpenSSL)

Fazit: Web Crypto gewinnt bei großen Dateien, weil es AES-NI verwendet. Reines JS ist für kleine Payloads in Ordnung, fügt aber bei Multi-Gigabyte-Transfers Sekunden hinzu. Bei einem 5-GB-Upload könnte der Unterschied zwischen Web Crypto und @noble/ciphers 2 Minuten versus 10 Minuten Verschlüsselungszeit betragen.

Passwort-Hashing: Argon2 oder besser

PBKDF2 ist das Minimum, Argon2id ist besser. Optionen:

• argon2-browser: WASM-kompilierte Referenzimplementierung, 200 KB
• @noble/hashes: reines JS Argon2id, 15 KB, langsamer aber rein
• libsodium.js: Argon2id via crypto_pwhash, 200 KB — aber schon vorhanden, wenn libsodium genutzt wird

Argon2id mit mindestens 3 Iterationen, 64 MiB Speicher und 4 Parallelität für passwortabgeleitete Verschlüsselungsschlüssel in Browser-Kontexten verwenden (OWASP-Leitfaden 2024).

Für Ihren Stack wählen

• Einfacher Dateitransfer mit AES-GCM-Verschlüsselung: Web Crypto direkt verwenden, keine Bibliothek. HexaTransfer folgt diesem Muster.
• ChaCha20-Poly1305 oder Streaming-AEAD benötigt: libsodium.js.
• Vorsicht bei WASM oder Auslieferung an eingeschränkte Bundler: @noble/ciphers + @noble/curves.
• NaCl-Protokoll-Schlüssel verwendet (z. B. versiegelte Boxen für verschlüsselten Dateiempfang): @noble oder libsodium, nicht crypto-js.
• Migration von crypto-js: zu @noble wechseln, wenn Bundle-Größe wichtig ist, sonst libsodium.js.
• Post-Quanten-Signaturen oder KEM benötigt: noch keine ausgereifte JS-Bibliothek; @noble/post-quantum (Pre-Release Stand Anfang 2026) prüfen.

Audit- und Wartungssignale

Vor der Übernahme einer Krypto-Bibliothek prüfen:

• Datum des letzten Commits (alles über 18 Monate veraltet ist riskant)
• Öffentliche Auditberichte (Cure53, Trail of Bits, NCC Group)
• Issue-Tracker auf ungelöste Sicherheitsprobleme
• Anzahl der Abhängigkeiten (weniger = kleinere Angriffsfläche)
• Wöchentliche npm-Downloads (höher = mehr Augen auf dem Code)

Das JavaScript-Ökosystem hatte Supply-Chain-Vorfälle (event-stream, ua-parser-js, colors), die minimale Abhängigkeiten zu einer Sicherheitseigenschaft machen. Krypto-Bibliotheken ohne Laufzeitabhängigkeiten (@noble-Familie, tweetnacl) sind einfacher von Ende zu Ende zu prüfen als solche, die Polyfills und Utilities nachladen.

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