Message Authentication Code (MAC).

Ein Message Authentication Code (MAC) ist ein Tag fester Länge, das mit einem symmetrischen Geheimschlüssel über eine Nachricht berechnet wird, sodass die Verifikation denselben Schlüssel benötigt. Er liefert Integrität und Authentizität, aber keine Nichtabstreitbarkeit, da beide Parteien den Schlüssel besitzen. Gebräuchliche Konstruktionen sind HMAC (hashbasiert, RFC 2104), CMAC (CBC-MAC, NIST SP 800-38B), GMAC (in GCM verwendet), Poly1305 (zusammen mit ChaCha20 in ChaCha20-Poly1305, RFC 8439) und KMAC (auf Basis von Keccak/SHA-3, NIST SP 800-185).

Der Grund, warum HMAC statt eines naiven MAC = H(key ‖ message) existiert, liegt darin, dass Merkle–Damgård-Hashes wie MD5, SHA-1 und SHA-256 anfällig für Length-Extension-Angriffe sind: Ein Angreifer, der ein gültiges Tag kennt, kann Daten anhängen und ohne den Schlüssel ein gültiges Tag für die längere Nachricht berechnen. Die verschachtelte Struktur H(key ⊕ opad ‖ H(key ⊕ ipad ‖ msg)) von HMAC vereitelt dies und besitzt einen formalen Sicherheitsbeweis.

MACs müssen in konstanter Zeit verifiziert werden — ein byteweiser Tag-Vergleich mit vorzeitigem Abbruch verrät über das Timing ihre Länge, was 2009 die Fälschung gegen Keyczar ermöglichte. Sie bilden die Grundlage der TLS-Record-Authentifizierung, von IPsec AH, JWT HS256, der Signierung von API-Anfragen und jedes AEAD-Modus. Ein MAC über dem Chiffretext (Encrypt-then-MAC) ist gegenüber MAC-then-Encrypt vorzuziehen, das zu Padding-Oracle-Angriffen wie Lucky Thirteen beitrug.

flowchart LR
  subgraph Sender
    M1[Nachricht] --> T1["MAC(key, message)"]
    K1[Gemeinsamer Geheimschlüssel] --> T1
    T1 --> S[Nachricht + Tag senden]
  end
  subgraph Empfänger
    S --> R["MAC(key, message) neu berechnen"]
    K2[Gemeinsamer Geheimschlüssel] --> R
    R --> C{"Vergleich in konstanter<br/>Zeit mit gesendetem Tag"}
    C -->|Gleich| OK[Akzeptieren: authentisch & unversehrt]
    C -->|Unterschiedlich| NO[Ablehnen: gefälscht oder verändert]
  end