2. Grundbegriffe

Bevor es um konkrete Algorithmen geht, müssen ein paar Begriffe sicher sitzen. Ihr werdet sie in Prüfungen, in der täglichen Arbeit und in jedem Sicherheitsdokument wiederfinden – es lohnt sich, sie präzise zu kennen und nicht durcheinanderzubringen.

Nach diesem Block könnt ihr:

  • die Begriffe Klartext, Geheimtext und Schlüssel erklären
  • Authentifizierung, Autorisierung und Authentizität unterscheiden
  • das Kerckhoffs’sche Prinzip erklären und begründen, warum „Security through Obscurity” nicht funktioniert
  • Schlüssellängen und ihre Sicherheit einordnen
  • erklären, warum Hashing keine Verschlüsselung ist und wofür es eingesetzt wird
  • den Unterschied zwischen SHA-256 und bcrypt/Argon2 für Passwortspeicherung benennen
  • erklären, was Entropie ist und warum kryptografisch sichere Zufallsquellen wichtig sind

Klartext und Geheimtext

  • Klartext (Plaintext): Die ursprüngliche, lesbare Information
  • Geheimtext (Ciphertext): Die verschlüsselte, unleserliche Version
  • Verschlüsseln (Encrypt): Klartext → Geheimtext
  • Entschlüsseln (Decrypt): Geheimtext → Klartext
  • Schlüssel (Key): Der geheime Parameter, der das Ver- und Entschlüsseln steuert

Authentifizierung, Autorisierung, Authentizität

Drei Begriffe, die in der IT-Sicherheit ständig auftauchen und klar unterschieden werden müssen:

Authentifizierung (Authentication): Der Prozess, die Identität zu überprüfen. „Wer bist du?” – und der Nachweis, dass die Behauptung stimmt. Beispiele: Passwort eingeben, SSH-Schlüssel vorlegen, Fingerabdruck scannen.

Autorisierung (Authorization): Der Prozess, nach erfolgter Authentifizierung zu prüfen, was jemand darf. „Was darfst du?” – also Zugriffsrechte und Berechtigungen. Beispiel: Ein eingeloggter Nutzer darf Dateien lesen, aber nicht löschen.

Authentizität (Authenticity): Die Eigenschaft, dass etwas wirklich von der angegebenen Quelle stammt. „Kommt das wirklich von dir?” – wird durch digitale Signaturen sichergestellt. Beispiel: Ein TLS-Zertifikat beweist, dass bank.de wirklich die Bank ist und kein Angreifer.

Authentifizierung: Ich bin Max Mustermann. → Passwort / Schlüssel beweist es.
Autorisierung:     Max darf Ordner A lesen, aber nicht Ordner B schreiben.
Authentizität:     Diese E-Mail stammt wirklich von max@techwerk.de. → Signatur beweist es.

Merke: Verschlüsselung allein stellt keine Authentizität sicher – sie macht Daten nur unlesbar. Erst eine digitale Signatur beweist, wer der Absender ist.


Nonce

Eine Nonce (Number used once) ist eine zufällige oder fortlaufende Zahl, die nur ein einziges Mal verwendet wird. Sie verhindert, dass aufgezeichnete Nachrichten zu einem späteren Zeitpunkt erneut gesendet werden können (Replay-Angriff).

Nonces tauchen in vielen Protokollen auf: beim Verbindungsaufbau (beide Seiten schicken eine zufällige Zahl), bei Challenge-Response-Authentifizierung und bei AEAD-Verschlüsselung (GCM benötigt eine eindeutige Nonce pro Verschlüsselungsvorgang). Konkrete Beispiele folgen in den jeweiligen Blöcken.


Kerckhoffs’sches Prinzip

Ein fundamentales Grundprinzip der modernen Kryptografie:

„Die Sicherheit eines Verschlüsselungsverfahrens darf nur vom Schlüssel abhängen, nicht vom geheim gehaltenen Algorithmus.”

Bedeutet: Der Algorithmus selbst darf öffentlich bekannt sein. Trotzdem muss das Verfahren sicher sein – weil die Sicherheit allein im Schlüssel liegt. „Security through obscurity” (Sicherheit durch Geheimhalten des Verfahrens) gilt als unsicher.

Beispiel: AES ist ein öffentlich dokumentierter Algorithmus. Trotzdem ist AES mit einem 256-Bit-Schlüssel praktisch unknackbar – weil der Schlüssel geheim ist, nicht der Algorithmus.

Schlüssellänge und Sicherheit

Die Schlüssellänge wird in Bit angegeben. Je länger der Schlüssel, desto mehr mögliche Kombinationen, desto aufwändiger der Brute-Force-Angriff.

SchlüssellängeMögliche SchlüsselSicherheit (Stand 2024)
56 Bit (DES)2⁵⁶ ≈ 72 BilliardenUnsicher, in Stunden knackbar
128 Bit (AES)2¹²⁸Sicher
256 Bit (AES)2²⁵⁶Sehr sicher, quantenresistenter
1024 Bit (RSA)Unsicher, veraltet
2048 Bit (RSA)Aktuell sicher (Minimum)
4096 Bit (RSA)Sehr sicher

Wichtig: Symmetrische und asymmetrische Schlüssellängen sind nicht vergleichbar. Ein 128-Bit-AES-Schlüssel bietet vergleichbare Sicherheit wie ein 3072-Bit-RSA-Schlüssel – wegen grundlegend verschiedener mathematischer Angriffsmethoden.

Hashing – kein Verschlüsseln

Hashing wird oft mit Verschlüsselung verwechselt. Es ist aber grundlegend verschieden:

  • Verschlüsselung: Umkehrbar – mit dem Schlüssel kommt man zurück zum Klartext
  • Hash: Einwegfunktion – aus dem Hash kann man den Klartext nicht zurückrechnen
Klartext → Hash-Funktion → Hash-Wert (immer gleiche Länge, nicht umkehrbar)
"Hallo" → SHA-256 → 185f8db32921bd46d35cc6347...

Hashes werden verwendet für: Passwort-Speicherung, Datei-Integrität prüfen (Checksums), digitale Signaturen (der Hash wird signiert, nicht die Nachricht).

Wichtige Hash-Algorithmen:

AlgorithmusAusgabelängeSicherheit
MD5128 BitUnsicher, nur für Checksums
SHA-1160 BitUnsicher, nicht mehr verwenden
SHA-256256 BitSicher, weit verbreitet
SHA-512512 BitSehr sicher
bcrypt / Argon2variabelFür Passwörter (langsam by design)

Salt – Zufallswert beim Hashing:

Ein Salt ist ein zufälliger Wert, der vor dem Hashing an die Eingabe angehängt wird. Er wird zusammen mit dem Hash gespeichert und muss kein Geheimnis sein.

Ohne Salt:
  SHA-256("geheim") → immer derselben Hash → angreifbar durch vorberechnete Tabellen

Mit Salt:
  Salt = "x7k2m9q1" (zufällig generiert, pro Eintrag verschieden)
  SHA-256("geheim" + "x7k2m9q1") → völlig anderer Hash
  Gespeichert: Hash + Salt

Warum relevant: Ohne Salt haben zwei Nutzer mit demselben Passwort denselben Hash — ein Angreifer erkennt das sofort. Mit Salt ist jeder Hash einzigartig, selbst bei identischen Passwörtern. Außerdem macht Salt vorberechnete Angriffstabellen wertlos — wie genau, erklärt Block 09. bcrypt und Argon2 generieren den Salt automatisch — das ist einer der Gründe, warum sie für Passwörter verwendet werden sollen.


Passwörter sicher speichern

Eine typische Prüfungsfrage: „Wie speichert man Passwörter sicher?” – hier die vollständige Antwort.

1. Niemals Klartext. Passwörter werden nie im Klartext in einer Datenbank gespeichert. Ein einziger Datenbank-Leak würde sonst alle Zugänge offenlegen.

2. Nicht einfach hashen. SHA-256(passwort) allein reicht nicht. Gleiche Passwörter erzeugen gleiche Hashes, und SHA-256 ist extrem schnell – Angreifer können mit einer GPU Milliarden Kombinationen pro Sekunde durchprobieren.

3. Salt verwenden. Ein zufälliger Wert wird vor dem Hashen an das Passwort angehängt. Jeder Nutzer bekommt einen eigenen Salt. Dadurch erzeugen gleiche Passwörter unterschiedliche Hashes. Der Salt wird zusammen mit dem Hash gespeichert – er ist kein Geheimnis.

4. Langsame Hash-Funktionen nutzen. bcrypt, Argon2 oder scrypt sind absichtlich langsam (Tausende Iterationen). Das macht Brute-Force-Angriffe unpraktikabel – statt Milliarden nur wenige Hundert Versuche pro Sekunde.

5. Der richtige Workflow:

Registrierung: Passwort + zufälliger Salt → bcrypt/Argon2 → Hash in DB speichern
Login:         Passwort + gespeicherter Salt → bcrypt/Argon2 → Vergleich mit DB-Hash

Merke: SHA-256 ist ein guter Hash-Algorithmus – aber nicht für Passwörter. Für Passwörter braucht man absichtlich langsame Funktionen wie bcrypt oder Argon2.

Wie Salt speziell gegen Rainbow-Table-Angriffe schützt, erklärt Block 09 im Detail.


Entropie und Zufallszahlen

Was ist Entropie? Entropie beschreibt den Grad an Unvorhersehbarkeit in einem Wert. Ein AES-256-Schlüssel braucht 256 Bit Entropie – jedes einzelne Bit muss zufällig und unvorhersehbar sein. Weniger Entropie bedeutet: Ein Angreifer muss weniger Möglichkeiten durchprobieren.

Warum ist das wichtig? Wenn ein Schlüssel, IV oder Salt vorhersehbar generiert wird, kann ein Angreifer den Raum aller möglichen Werte drastisch einschränken. Ein „zufälliger” Schlüssel aus rand() oder Math.random() ist nicht kryptografisch sicher – diese Funktionen nutzen vorhersehbare Algorithmen (Pseudozufall), deren Ausgabe sich rekonstruieren lässt.

Kryptografisch sichere Zufallsquellen:

QuelleBeschreibung
/dev/urandom (Linux)Empfohlen – sammelt Entropie aus Hardware-Ereignissen (Tastatureingaben, Mausbewegungen, Interrupt-Timing)
openssl rand -hex 32Generiert 32 Byte = 256 Bit kryptografisch sicheren Zufall
secrets (Python)Kryptografisch sicheres Modul – statt random verwenden
crypto.getRandomValues() (JS)Sicher – nicht Math.random() verwenden

Merke: Jeder kryptografische Schlüssel, IV und Salt muss aus einer kryptografisch sicheren Zufallsquelle stammen. rand(), Math.random() oder vorhersehbare Seeds sind keine sicheren Quellen.

Zusammenfassung

  • Klartext → Verschlüsselung → Geheimtext: Der Schlüssel bestimmt die Sicherheit, nicht der Algorithmus (Kerckhoffs’sches Prinzip)
  • Authentifizierung ≠ Autorisierung ≠ Authentizität – drei verschiedene Konzepte, die oft verwechselt werden
  • Hashing ist keine Verschlüsselung – Hashes sind Einwegfunktionen, es gibt keinen Weg zurück
  • Passwörter sicher speichern: Salt + bcrypt/Argon2, niemals SHA-256 allein, niemals Klartext
  • Entropie und Zufallszahlen: Kryptografische Schlüssel brauchen echten Zufall (/dev/urandom, openssl rand), nicht Math.random()

Selbsttest

  1. Erklärt den Unterschied zwischen Authentifizierung und Autorisierung an einem Alltagsbeispiel.
  2. Warum ist SHA-256 allein nicht geeignet, um Passwörter in einer Datenbank zu speichern? Nennt zwei Gründe.
  3. Ein Kollege argumentiert: „Unser Verschlüsselungsalgorithmus ist sicher, weil niemand weiß, wie er funktioniert.” Was antwortet ihr?

Wie geht es weiter?

Mit den Grundbegriffen im Gepäck geht es an die erste konkrete Technik: Block 02 erklärt symmetrische Verschlüsselung – das Arbeitstier hinter jeder HTTPS-Verbindung, jeder VPN-Verbindung und jeder verschlüsselten Festplatte.