Schlüsselableitungsfunktionen: PBKDF2, Argon2 und scrypt verglichen

Für passwortbasierte Verschlüsselung ist Argon2id im Jahr 2026 die empfohlene Wahl (PHC-Gewinner, OWASP-Top-Pick, aktiv abgesichert gegen GPU- und ASIC-Angreifer), scrypt ist eine solide zweite Option (speicher-hart, weit verbreitet in Kryptowährungen), und PBKDF2-SHA-256 mit 600.000+ Iterationen bleibt aus Kompatibilitätsgründen akzeptabel, bietet jedoch minimalen GPU-Widerstand. Für Dateiübertragungsdienste, bei denen Nutzer ein Passwort zum Schutz einer geteilten Datei eingeben, ist Argon2id mit 3 Iterationen, 64 MiB Arbeitsspeicher und Parallelität 4 die moderne Ausgangsbasis. PBKDF2 überlebt, weil es in der Web Crypto API integriert ist und keine WASM-Abhängigkeit erfordert. So unterscheiden sich die drei Funktionen — und wann jede davon sinnvoll ist.

Vergleichstabelle

| Eigenschaft | PBKDF2 | scrypt | Argon2id | |---|---|---|---| | Jahr eingeführt | 2000 (RFC 2898) | 2009 (RFC 7914) | 2015 (PHC-Gewinner) | | Speicher-hart | Nein | Ja | Ja | | Parameter-Flexibilität | Nur Iterationen | N, r, p | Zeit, Speicher, Parallelität | | GPU-Widerstand | Schwach | Mittel | Stark | | ASIC-Widerstand | Sehr schwach | Mittel | Stark | | Browser-nativ (Web Crypto) | Ja | Nein | Nein | | OWASP-Empfehlung 2024 | Akzeptabler Fallback | Akzeptabel | Bevorzugt | | Typische Browser-Kosten (moderne Hardware) | 600.000 Iter ≈ 500 ms | N=2^17 ≈ 800 ms | 3 Iter, 64 MiB ≈ 1 s |

Warum Speicher-Härte entscheidend ist

Das Bedrohungsmodell für passwortbasierte Verschlüsselung ist Offline-Brute-Force. Ein Angreifer holt sich den Chiffretext mitsamt Salt, durchläuft ein Passwort-Wörterbuch und versucht, einen Schlüssel abzuleiten, der erfolgreich entschlüsselt. Die Abwehr besteht darin, jeden Versuch teuer zu machen.

PBKDF2 macht jeden Versuch ausschließlich in Bezug auf CPU-Zeit teuer (SHA-256-Iterationen). Moderne GPUs führen Milliarden von SHA-256-Operationen pro Sekunde aus; eine Gaming-GPU kann täglich 10–100 Millionen PBKDF2-SHA-256-600000-Versuche durchführen. ASIC-Angreifer erzielen um Größenordnungen bessere Werte.

Speicher-harte Funktionen (scrypt, Argon2) erfordern pro Versuch eine feste Menge Arbeitsspeicher. GPUs und ASICs haben begrenzte Speicherbandbreite, weshalb die Parallelität pro Gerät begrenzt ist. Eine 64-MiB-Speicheranforderung bedeutet, dass eine GPU mit 16 GB VRAM höchstens 256 parallele Versuche ausführen kann, nicht Millionen. Die wirtschaftlichen Kosten von Brute-Force steigen um 2–3 Größenordnungen.

PBKDF2: Der Legacy-Standard

PBKDF2 (RFC 2898) iteriert eine pseudozufällige Funktion — typischerweise HMAC-SHA-256 oder HMAC-SHA-512 — über das Passwort und den Salt. Die Iterationsanzahl ist der einzige einstellbare Parameter.

const passwordKey = await crypto.subtle.importKey(
  "raw", new TextEncoder().encode(password),
  "PBKDF2", false, ["deriveKey"]
);
const aesKey = await crypto.subtle.deriveKey(
  {
    name: "PBKDF2",
    salt,  // 16 Zufalls-Bytes
    iterations: 600000,
    hash: "SHA-256",
  },
  passwordKey,
  { name: "AES-GCM", length: 256 },
  false,
  ["encrypt", "decrypt"]
);

OWASP 2023 empfiehlt mindestens 600.000 Iterationen für PBKDF2-SHA-256. NIST SP 800-132 ist älter und weniger spezifisch. Einige Spezifikationen (z. B. LastPass' Standard von 100.100 aus 2018) gelten im Jahr 2026 als zu niedrig.

Vorteile: in Web Crypto integriert, kein WASM, FIPS-validiert, unterstützt in der TLS-1.3-Sitzungswiederaufnahme, funktioniert identisch in Node und Browsern.

Einschränkungen: keine Speicher-Härte, anfällig für GPU- und ASIC-Beschleunigung. Eine Verdopplung der Iterationen verdoppelt die Kosten des Angreifers — aber auch die des legitimen Nutzers. Ab einem gewissen Punkt weigern sich Nutzer zu warten, und die Iterationen werden gedeckelt.

scrypt: Die erste speicher-harte Implementierung

scrypt (RFC 7914) wurde 2009 von Colin Percival für Tarsnap entwickelt. Es mischt Passwort-Material durch einen großen Speicherpuffer und zwingt den Angreifer, diesen Puffer während jedes Versuchs zu halten.

Drei Parameter:

N: Kostenfaktor (typisch 2^14 bis 2^20). Speichernutzung beträgt grob 128 × N × r Bytes.
r: Blockgröße (typisch 8). Beeinflusst Speicher und GHASH-Iterationsanzahl.
p: Parallelisierung (typisch 1). Höhere Werte beschleunigen legitime Berechnungen, aber auch Angreifer; üblicherweise bei 1 belassen.

OWASP empfiehlt N=2^17, r=8, p=1 als Ausgangsbasis, was ~128 MiB verbraucht und auf moderner Hardware etwa 800 ms läuft.

scrypt ist nicht in der Web Crypto API enthalten. In JavaScript nutzen Sie scrypt-js, @noble/hashes oder libsodium.js. Litecoin und Dogecoin verwenden scrypt als Proof-of-Work, was ASIC-Entwicklung speziell für scrypt angereizt und den ursprünglichen asymmetrischen Vorteil gegen ASICs etwas vermindert hat.

Argon2id: Der Standard für 2026

Argon2 gewann 2015 den Password Hashing Competition. Drei Varianten: Argon2d (schnellste, datenabhängig, seitenkanal-anfällig), Argon2i (datenunabhängig, langsamer), Argon2id (hybrid, für die meisten Anwendungen empfohlen). RFC 9106 standardisierte es 2021.

Drei Parameter:

t (Zeit): Iterationen durch den Speicher. Typisch 2–3.
m (Speicher): Speicher in KiB. Typisch 65536 (64 MiB) oder höher.
p (Parallelität): Grad der Parallelität. Typisch 1–4.

OWASP-2024-Ausgangsbasis: t=2, m=19456 (19 MiB), p=1 als Minimum, und t=3, m=65536 (64 MiB), p=4 für stärkeren Schutz.

import { argon2id } from '@noble/hashes/argon2';
import { utf8ToBytes } from '@noble/hashes/utils';

const derivedKey = argon2id(utf8ToBytes(password), salt, {
  t: 3, m: 65536, p: 4, dkLen: 32
});

Oder via argon2-browser (WASM):

import argon2 from 'argon2-browser';
const hash = await argon2.hash({
  pass: password, salt,
  type: argon2.ArgonType.Argon2id,
  time: 3, mem: 65536, parallelism: 4, hashLen: 32
});

Argon2id schlägt GPU-Angreifer wirksamer als scrypt, weil sein Speicherzugriffsmuster weniger für Bulk-Speicher-Designs geeignet ist. ASICs für Argon2 existieren in der Forschung, sind aber noch nicht im wirtschaftlich relevanten Maßstab bei Angreifern eingesetzt.

Parameter für Ihre Anwendung festlegen

Die Kalibrierungsmethode: Wählen Sie die längste Wartezeit, die Ihre Nutzer tolerieren (üblicherweise 500 ms bis 2 Sekunden), messen Sie auf dem langsamsten Zielgerät, und legen Sie die Parameter so fest, dass dieses Budget eingehalten wird.

Für passwortgeschützte Dateifreigaben im HexaTransfer-Stil — bei denen die Ableitung einmal beim Upload und einmal beim Download stattfindet — sind 1–2 Sekunden akzeptabel. Parameter:

PBKDF2-SHA-256: 600.000–1.200.000 Iterationen
scrypt: N=2^17, r=8, p=1
Argon2id: t=3, m=65536, p=4

Für Anmeldesysteme, bei denen der Nutzer nach der Passworteingabe wartet, liegt die UX-Grenze bei 300–500 ms. Die Parameter halbieren sich grob. Für Batch-Szenarien, in denen Nutzer nicht warten (z. B. Hintergrund-Neuverschlüsselung), können Sie auf 3–5 Sekunden hochgehen.

Salt-Verwaltung

Alle drei KDFs benötigen einen Salt. Regeln:

Mindestens 16 Zufalls-Bytes
Erzeugt via crypto.getRandomValues(), niemals Math.random()
Eindeutig pro Passwort (wenn zwei Personen dasselbe Passwort verwenden, sollten ihre Salts unterschiedlich sein, damit abgeleitete Schlüssel sich unterscheiden)
Kein Geheimnis — zusammen mit dem Chiffretext speichern

Pepper (ein Geheimnis, das allen Ableitungen hinzugefügt wird) wird gelegentlich diskutiert. Für Dateiübertragungen, bei denen der „Server" ein einfacher Blob-Store ist, fügt Pepper keinen Mehrwert hinzu, da es kein serverseitiges Geheimnis gibt. Bei kontobasierten Systemen macht ein serverseitiger Pepper, der getrennt von der Passwortdatenbank gespeichert wird, Datenbankabzüge für Angreifer weniger nützlich.

Migration zwischen KDFs

Wenn Sie eine bestehende PBKDF2-Implementierung auf Argon2id umstellen möchten:

Speichern Sie den KDF-Bezeichner in den Chiffretext-Metadaten ("kdf": "pbkdf2-sha256-600000" oder "kdf": "argon2id-3-65536-4")
Verwenden Sie bei neuen Uploads Argon2id
Lesen Sie beim Entschlüsseln den KDF-Bezeichner und nutzen Sie die entsprechende Funktion
Aktualisieren Sie alte Chiffretexte niemals blind; dazu würden Sie das Passwort zur Neuableitung benötigen

LastPass, 1Password und Bitwarden haben diese Migration alle durchgeführt. Alle drei verwenden jetzt standardmäßig PBKDF2 mit 600.000+ Iterationen, mit Argon2id in neueren Versionen. Selbst Passwort-Manager haben sich mit Argon2 Zeit gelassen — der Rollout erfolgte schrittweise, weil das Ökosystem-Tooling reifen musste.

Was ist mit bcrypt?

bcrypt (1999) ist eine solide Passwort-Hash-Funktion mit moderater Speicher-Härte. Sie begrenzt die Eingabe auf 72 Bytes (ein bekanntes Fallstrick — lange Passwörter werden stillschweigend abgeschnitten). Es ist der historische Standard in Ruby on Rails und vielen PHP-Frameworks. Für neuen Code im Jahr 2026 bevorzugen Sie Argon2id; bcrypt ist für die Pflege bestehender Systeme in Ordnung.

Die realistische Empfehlung

Für einen neuen Dateiübertragungsdienst im Jahr 2026:

Wenn Sie eine 15–200 KB Abhängigkeit einsetzen können: Argon2id via @noble/hashes oder libsodium.js
Wenn Sie null Abhängigkeiten und minimale Bundle-Größe benötigen: PBKDF2-SHA-256 mit 600.000 Iterationen via Web Crypto
Wenn Sie ein Kryptowährungs-Wallet oder etwas mit Legacy-scrypt entwickeln: scrypt mit N=2^17

Für Produktionsanwendungen, die sensible Dateien verarbeiten, ist Argon2id die WASM-Abhängigkeit wert. Für einfache passwortgeschützte Freigaben, bei denen Nutzer ohnehin ein zufälliges Passwort generieren, ist PBKDF2 ausreichend, da die Entropie im Passwort liegt, nicht in der KDF.

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