Verschluesselungs-Berater
Verschluesselungsstrategien waehlen und implementieren — at-rest, in-transit, Schluesselverwaltung und Algorithmusauswahl fuer die Anwendung.
Das Problem
Verschluesselungsentscheidungen sind leicht falsch zu treffen und katastrophal, wenn es passiert. Die Verwendung des ECB-Modus legt Datenmuster offen. Selbstentwickelte Kryptografie fuehrt zu subtilen Fehlern. Verschluesselungsschluessel neben den verschluesselten Daten zu speichern macht den gesamten Zweck zunichte. Und die Wahl zwischen symmetrisch vs. asymmetrisch, AES-GCM vs. ChaCha20, RSA vs. ECDSA erfordert ein Verstaendnis von Trade-offs, auf die die meisten Entwickler erst stossen, wenn etwas schiefgeht.
Der Prompt
Du bist ein Kryptografie-Ingenieur. Hilf mir, die richtige Verschluesselungsstrategie fuer meine Anwendung zu waehlen und zu implementieren.
ANWENDUNGSFALL:
- Zu schuetzende Daten: [z.B. personenbezogene Daten, Zahlungsdaten, medizinische Akten, API-Tokens]
- Bedrohungsmodell: [z.B. Datenbankeinbruch, Man-in-the-Middle, Insider-Bedrohung, regulatorische Compliance]
- Plattform: [z.B. Node.js, Python, Java, Browser, Mobile]
- Performance-Anforderungen: [z.B. hoher Durchsatz, niedrige Latenz, Batch-Verarbeitung]
AKTUELLE IMPLEMENTIERUNG (falls vorhanden):
[aktuellen Verschluesselungs-/Hashing-Code einfuegen]
Beratung zu:
1. **Verschluesselung at rest**: Algorithmus, Modus, Schluesselgroesse fuer gespeicherte Daten
2. **Verschluesselung in transit**: TLS-Konfiguration, Certificate Pinning
3. **Passwort-Hashing**: Algorithmuswahl (argon2/bcrypt/scrypt), Parameter
4. **Schluesselverwaltung**: Generierung, Speicherung, Rotation, Vernichtung
5. **Datenklassifizierung**: Welche Felder Verschluesselung vs. Hashing vs. Tokenisierung brauchen
6. **Implementierung**: Sicherer Code mit den nativen Krypto-Bibliotheken meiner Plattform
Fuer jede Empfehlung erlaeutern:
- Warum dieser Algorithmus/Modus gegenueber Alternativen
- Haeufige Implementierungsfehler, die zu vermeiden sind
- Schluesselgroesse und Parameterwahl mit Begruendung
- Geschaetzte Performance-AuswirkungBeispielausgabe
## Verschluesselungsstrategie fuer personenbezogene Daten (Node.js)
### At Rest: AES-256-GCM
Warum: Authentifizierte Verschluesselung verhindert Manipulation + Entschluesselung. GCM statt CBC, weil CBC separates HMAC benoetigt.
Schluessel: 256-Bit via crypto.randomBytes(32), in AWS KMS gespeichert, alle 90 Tage rotiert.
### Passwort-Hashing: Argon2id
Warum: Memory-Hard, resistent gegen GPU/ASIC-Angriffe. argon2id statt bcrypt fuer neue Projekte.
Parameter: memoryCost=65536, timeCost=3, parallelism=4Wann verwenden
Vor der Implementierung jeglichen Datenschutzes konsultieren — Nutzerregistrierung, Zahlungsverarbeitung, medizinische Daten oder API-Authentifizierung. Unverzichtbar bei der Wahl zwischen Verschluesselungsalgorithmen, Migration von veralteter Kryptografie oder Vorbereitung auf Compliance-Audits (DSGVO, HIPAA, PCI-DSS).
Profi-Tipps
- Niemals eigene Kryptografie bauen — kampferprobte Bibliotheken verwenden (libsodium, Web Crypto API, Node.js crypto). Eigene Implementierungen werden Schwachstellen haben.
- Immer authentifizierte Verschluesselung — AES-GCM oder ChaCha20-Poly1305 verwenden, nie AES-CBC ohne separates HMAC. Unauthentifizierte Verschluesselung erlaubt Ciphertext-Manipulation.
- Schluessel und Daten muessen getrennt sein — Daten verschluesseln und den Schluessel in derselben Datenbank speichern ist wie eine Tuer abschliessen und den Schluessel an den Rahmen kleben.
- Passwoerter hashen, Daten verschluesseln — Passwoerter sollten mit argon2id gehasht (Einweg) werden, nie verschluesselt (Zweiweg). Wenn man ein Passwort entschluesseln kann, ist das Design falsch.