Die Kladde benutzt Kryptografie schon an mehreren Stellen: TLS am Rand (Lektion 3.0.4), Data Protection für Anmeldung und Formulare (K2) und
seit Lektion 3.3.2 eine eigene Signatur für die Links in den Buchungsmails, mit einem Schlüssel aus dem Key Vault. Dort stand die Klasse
BookingLinks mit HMACSHA256 und CryptographicOperations.FixedTimeEquals, ohne dass erklärt wurde, warum gerade diese beiden. Das holt
diese Lektion nach. Sie lernen die fünf Werkzeuge kennen, die in fast jeder Anwendung vorkommen, wann welches passt, und woran Sie im Review
einen Fehler erkennen. Am Ende prüfen Sie die Signatur der Buchungslinks gegen einen Wert, der außerhalb von .NET gerechnet wurde.
Alles in dieser Lektion steckt in System.Security.Cryptography und damit in .NET selbst; kein Paket kommt dazu. Legen Sie für die Beispiele
einen Ordner k3-uebungen/3-3 an. Jedes Beispiel ist eine einzelne Datei, die Sie mit dotnet run <datei>.cs starten.
Fünf Fragen, fünf Werkzeuge
Bevor Sie ein Verfahren auswählen, stellen Sie die Frage, die es beantworten soll:
| Frage | Werkzeug | in .NET |
|---|---|---|
| Hat sich dieser Inhalt verändert? | Hash (SHA-256) | SHA256.HashData |
| Stammt er von jemandem, der den gemeinsamen Schlüssel kennt? | HMAC (HMAC-SHA256) | HMACSHA256.HashData |
| Ist das das richtige Kennwort? | Kennwort-Hash (PBKDF2) | Rfc2898DeriveBytes.Pbkdf2 |
| Darf das nur lesen, wer den Schlüssel hat? | Verschlüsselung (AES-GCM) | AesGcm |
| Darf jeder prüfen, aber nur einer erzeugen? | Signatur (ECDSA, RSA) | ECDsa, RSA |
Dazu kommt eine sechste Regel, die für alle gilt: Jeder Schlüssel, jedes Salz und jede Nonce kommt aus RandomNumberGenerator.
Die häufigsten Fehler entstehen, wenn ein Werkzeug die Frage eines anderen beantworten soll: ein Hash als Beweis der Herkunft, ein schneller Hash für Kennwörter, eine Verschlüsselung ohne Prüfung der Echtheit.