Zusammenfassung

  • RFC 2104 legte zwei unterschiedlich gepolsterte Schlüsseldurchläufe um eine bestehende Hashfunktion und musste deren Kompressionscode dafür nicht verändern.
  • Hashverfahren und Ausgabelänge konnten wechseln; deshalb gehören Algorithmus, Schlüssel, exakte Nachrichtendarstellung und Taglänge zum prüfbaren Kontext.
  • Ein übereinstimmender HMAC beweist weder einen eindeutigen Absender noch Berechtigung, Frische, Kanonisierung, Vertraulichkeit, Zustellung oder korrekten Betrieb.

Die dauerhafte Neuerung von HMAC war keine weitere Hashfunktion. Sie war eine belastbare Fassung für bereits vorhandene Hashfunktionen. 1997 standen schnelle Implementierungen von MD5 und SHA-1 bereit, doch eine naive Verkettung von Geheimnis und Nachricht war keine hinreichend verstandene Grundlage für Nachrichten-Authentisierung.

RFC 2104 machte aus kryptografischer Analyse einen kleinen, ausführbaren Vertrag. Gerade weil dieser Vertrag wenig versprach, ließ er sich breit einsetzen.

Zwei getrennte Bereiche, dieselbe Hashfunktion

Der RFC 2104 nennt die Hashfunktion H, ihre Blocklänge B und ihre Ausgabelänge L. Schlüssel mit mehr als B Byte werden zunächst gehasht; kürzere Schlüssel werden mit Nullen auf B erweitert. Zwei feste Blöcke trennen die Rollen: ipad besteht aus wiederholtem 0x36, opad aus wiederholtem 0x5c.

Berechnet wird H((K xor opad) || H((K xor ipad) || text)). Im inneren Durchlauf folgt die Nachricht auf einen schlüsselabhängigen Block. Der äußere Durchlauf verarbeitet eine andere Schlüsselableitung und das innere Ergebnis. Die Implementierung von H bleibt unverändert.

So konnten vorhandener Code und Leistung erhalten, Schlüssel einfach behandelt und das Hashverfahren später ersetzt werden. Was text fachlich bedeutete, wie es kodiert wurde und welche Handlung eine erfolgreiche Prüfung erlaubte, blieb bewusst außerhalb dieser Ebene.

Auch vorberechnete Zustände sind Geheimnisse

Für kurze Nachrichten dürfen Implementierungen die Zustände nach dem inneren und äußeren Schlüsselblock vorberechnen. Pro Nachricht entfallen dann zwei Kompressionsschritte; die Interoperabilität ändert sich nicht.

RFC 2104 verlangt, diese Zustände wie Schlüssel zu schützen. Ein abgeleiteter Wert verliert seine operative Macht nicht dadurch, dass er anders aussieht als K. Wer den Originalschlüssel sichert, aber wiederverwendbare Zwischenzustände offenlegt, schützt den Namen des Geheimnisses statt seiner Fähigkeit.

Zufällige Schlüsselwahl, sicherer Austausch, Schutz und Erneuerung bleiben ebenfalls äußere Pflichten. Die Formel standardisiert die Rechnung. Sie erzeugt weder Entropie noch verlässliche Verwahrung.

Ein Tag erhält Bedeutung erst durch seinen Kontext

Anwendungen können die Ausgabe auf die linken t Bits kürzen. Diese Wahl verändert den Aufwand eines Rateangriffs und muss im Protokoll feststehen. Ein Befund „HMAC gültig“ ist ohne Algorithmus, Schlüsselkennung und -epoche, authentisierte Bytes und Taglänge unvollständig.

HMAC sieht Bytes, keine Semantik. Zwei gleichbedeutende JSON-Darstellungen oder Unicode-Folgen können verschiedene Tags erzeugen. Umgekehrt können beide Seiten zuverlässig die falschen Felder authentisieren und dennoch übereinstimmen. Kanonisierung ist eine eigene Protokollregel vor der MAC-Berechnung.

Der symmetrische Schlüssel begrenzt außerdem die Zuschreibung. Jeder berechtigte Inhaber kann ein gültiges Tag erstellen. Die Prüfung unterscheidet nicht zwischen Personen, Diensten oder Rechnern, die dasselbe Geheimnis teilen. Sie ist keine digitale Signatur und schafft keine eigenständige Nichtabstreitbarkeit.

Testvektoren machten den Vertrag messbar

Der RFC 2202 veröffentlichte noch 1997 bekannte Schlüssel, Nachrichten und Ergebnisse für HMAC-MD5 und HMAC-SHA-1. Unabhängige Implementierungen konnten dadurch ihre Bytebehandlung unmittelbar vergleichen.

Ein bestandener Vektor belegt genau diesen bekannten Pfad. Er erfasst nicht jede Länge, jeden Fehlerfall, zeitkonstante Vergleiche, Parallelität, produktive Schlüsselauswahl oder Replay-Zustände. Konformität der Kernrechnung ist ein wertvoller Beleg, aber kein Zertifikat für die ganze Anwendung.

Austauschbarkeit musste organisatorisch eingelöst werden

MD5 und SHA-1 waren Beispiele ihrer Zeit; H blieb absichtlich abstrakt. RFC 4868 definierte später HMAC-SHA-256, -384 und -512 für IPsec. RFC 6151 bewertete MD5 neu und riet von HMAC-MD5 in neuen Protokollen ab.

Die Komposition überlebte ihre frühen Instanzen. Der Wechsel brauchte trotzdem Kennungen, Aushandlung, Implementierungen, Richtlinien, Tests und Schlüsselwechsel. Algorithmische Agilität ist eine Eigenschaft der Schnittstelle; Migration bleibt eine Entscheidung mit Kosten und Besitzern.

Die spätere Aufnahme in NIST FIPS 198-1 zeigt die institutionelle Reichweite. Sie macht die anfänglichen Hashverfahren nicht dauerhaft gültig.

Nach der Prüfung beginnt die Vertrauensentscheidung

Eine alte Nachricht mit altem Tag kann erneut gültig sein. Frische erfordert Nonce, Zähler, Zeitfenster oder anderen Zustand. Berechtigung erfordert eine Regel für den authentisierten Kontext. Vertraulichkeit erfordert Verschlüsselung. Zustellung und dauerhafte Wirkung brauchen spätere Belege. Korrektheit verlangt mehr als bekannte Testwerte.

RFC 2104 gab dem Internet einen strengen, dünnen Baustein. Zwei Hash-Durchläufe machten den MAC wiederverwendbar. Vertrauen musste weiterhin um ihn herum aufgebaut werden.

Quellen