Zusammenfassung

  • Das Salt von HKDF ist üblicherweise nicht geheim. Es kann die Unabhängigkeit und die Analyse der Extraktion stärken, aber keine fehlende Entropie erzeugen, den Eingang authentifizieren oder Passwortversuche verlangsamen.
  • info wirkt erst bei der Expansion und bindet Ausgaben an Protokoll, Version, Rolle oder Zweck. Eine belastbare Ableitung dokumentiert daher IKM-Herkunft, Salt-Herkunft, exakt kodierten Kontext und Lebenszyklus jeder Ausgabe getrennt.

Ein erfolgreicher Test mit der falschen Aussage

Zwei Endpunkte leiten dieselben 32 Byte ab. Der Interoperabilitätstest ist grün. Im Sicherheitsbericht steht anschließend, die Schlüsselableitung sei verifiziert. Doch wenn nicht festgehalten wurde, ob die Ausgabe als AEAD-Schlüssel, IV, Header-Schutzschlüssel oder Exportgeheimnis gedacht war, belegt der Test nur die Übereinstimmung der Berechnung. Der Zweck bleibt unbewiesen.

Genau hier hilft die Zweiteilung von HKDF. Zuerst wird aus anfänglichem Schlüsselmaterial ein pseudorandomisierter Zwischenschlüssel gewonnen. Danach werden aus diesem Zwischenschlüssel zweckgebundene Ausgaben erzeugt. Hugo Krawczyk entwickelte die formale Begründung dieses Modells; RFC 5869 wurde von ihm gemeinsam mit Pasi Eronen verfasst. Sein IETF-Profil führt außerdem RFC 2104 zu HMAC, auf dem HKDF aufbaut. Das ACM-Preisjahrbuch 2025 würdigt seine Beiträge zu den theoretischen und praktischen Grundlagen sicherer Kommunikation.

Die Person steht hier für eine Grenze, nicht für eine Alleinautorenschaft: Ein Zwischengeheimnis ist noch kein betriebsfertiger Schlüssel.

Extract sortiert vorhandene Ungewissheit

HKDF-Extract berechnet:

PRK = HMAC-Hash(salt, IKM)

Das Input Keying Material kann ungleich verteilt sein oder eine dem Angreifer teilweise bekannte Struktur haben. Extract konzentriert die vorhandene Entropie in einem pseudorandomisierten Schlüssel fester Länge. Die Operation vergrößert den tatsächlichen Kandidatenraum nicht. Stammt das IKM aus einem menschlichen Passwort, kann ein Angreifer weiterhin alle plausiblen Eingaben mit derselben schnellen Funktion prüfen.

Ob Extract entfallen darf, hängt deshalb von der Eingabeklasse ab. Ein bereits hochwertiger pseudorandomisierter Schlüssel kann in bestimmten Anwendungen direkt expandiert werden. Ein Diffie-Hellman-Wert ist dagegen nicht einfach eine gleichverteilte HMAC-Schlüsselrepräsentation; RFC 5869 rät ausdrücklich davon ab, hier die Extraktion zu überspringen.

NIST SP 800-56C Rev. 2 ordnet Verfahren für die Schlüsselvereinbarung ebenfalls nach Extraktion, Expansion und Extraktion mit anschließender Expansion. Die Stufengrenze ist kein Bibliotheksdetail. Sie macht sichtbar, welche Annahme über die Quelle erfüllt wurde, bevor Ausgaben für konkrete Algorithmen entstehen.

Öffentlich ist nicht beliebig kontrollierbar

RFC 5869 beschreibt das Salt als optional und nicht geheim. Fehlt es, wird eine Nullfolge in Hashlänge eingesetzt. Ein Protokoll darf einen Saltwert offen übertragen, aus authentifizierten öffentlichen Nonces bilden oder unter passenden Voraussetzungen einen festen Wert wiederverwenden.

Der Nutzen kommt nicht vom Verstecken. Ein geeignetes Salt kann Verwendungen der Hashfunktion voneinander unabhängiger machen, quellunabhängige Extraktion unterstützen und die Sicherheitsanalyse stärken. Dennoch gilt eine Provenienzanforderung: Das Salt soll unabhängig vom IKM sein. Wird es aus Beiträgen der Kommunikationspartner gebildet, muss das Protokoll verhindern, dass ein Angreifer diese Beiträge unbemerkt auswählt.

Ein boolesches Logfeld salted ist daher wertlos. Mindestens vier Zustände gehören auseinandergehalten: kein Salt und damit der definierte Nullwert, versionsgebundenes Protokoll-Salt, frisches authentifiziertes öffentliches Salt und von einer nicht authentifizierten Partei beeinflussbares Salt.

RFC 8188 zeigt die Aufgabenteilung in einer realen Anwendung. Beim verschlüsselten HTTP Content-Encoding fließt ein übertragener Saltwert in HKDF-Extract. Eine feste Zeichenfolge für das Content-Encoding dient als info der Expansion. Beide Werte können offenliegen, weil Sichtbarkeit nicht ihre Funktion bestimmt.

Das Salt eines Passworts braucht einen Preis

Bei Passwortspeicherung verhindert ein eindeutiges Salt, dass vorberechnete Tabellen bequem über viele Konten wiederverwendet werden, und trennt gleiche Passwörter. Es beseitigt jedoch nicht die geringe Entropie menschlicher Wahl. Gegen Offline-Raten braucht jeder Versuch absichtlich Zeit- oder Speicheraufwand.

HKDF besitzt weder einen Arbeitsfaktor noch eine speicherharte Phase. RFC 5869 stellt klar, dass Extract vorhandene Entropie konzentrieren, aber nicht verstärken kann; eine Verzögerung für Passwortableitung gehört nicht zur Konstruktion. PBKDF2 führt eine Iterationszahl als Parameter. Argon2 bindet Speicherbedarf, Durchläufe und Parallelität ein. Auch diese Verfahren verwandeln ein schlechtes Passwort nicht in ein gutes Geheimnis, erhöhen aber die Kosten einer Wörterbuchkampagne.

„Wir haben gesalzen“ ist somit keine vollständige Kontrollaussage. Entscheidend sind die verwendete Konstruktion, die Klasse des Ausgangsmaterials, der Preis eines Rateversuchs, die geforderte Eigenschaft des Salts und die Stelle, die diese Eigenschaft erzwingt.

info gibt der Ausgabe ihren Beruf

HKDF-Expand nimmt PRK, info und die gewünschte Länge entgegen. info kann Protokollnummer, Algorithmus, Identität, Rolle oder Länge kodieren. Der Wert bindet das Ergebnis an Anwendung und Kontext, sodass dasselbe IKM nicht ununterscheidbares Material für verschiedene Domänen erzeugt.

Salt ist kein Ersatz dafür. RFC 5869 empfiehlt auch bei kurzer gewünschter Ausgabe nicht, PRK direkt als Endergebnis zu verwenden, weil dann info umgangen wird. Kontextdaten stattdessen in Extract zu schieben, wird ebenfalls nicht empfohlen. PRK ist ein generisches Ableitungsgeheimnis, noch kein Sende-, IV- oder Exportwert.

TLS 1.3 setzt diese Trennung in ein Datenformat um. HKDF-Expand-Label kodiert den Präfix tls13 , ein Label und einen Kontext, der den Handshake-Transkript-Hash enthalten kann. Bezeichnungen wie finished, key und iv sind echte kryptografische Eingaben.

QUIC verwendet quic key, quic iv und quic hp, um AEAD-Schlüssel, Initialisierungsvektor und Header-Schutzschlüssel zu trennen. RFC 9001 nennt dies zugleich als Trennung zwischen QUIC- und TLS-Schlüsseln. Ein Logeintrag „HKDF erfolgreich“ verwirft damit die wichtigste nicht geheime Spur.

HPKE nimmt HPKE-v1, die Cipher-Suite-Kennung und ein Zwecklabel in LabeledExtract und LabeledExpand auf. Das bindet Geheimnisse an Schema, Version und Algorithmuswahl. MLS nutzt den eigenen Präfix MLS 1.0 in einem mehrstufigen Schlüsselplan für Gruppenepochen. Lesbarer Text allein schafft keine Domäne; erst eindeutige Kodierung und konsequente Prüfung durch alle Implementierungen tun es.

Vier Nachweise statt eines Schlüssel-Fingerabdrucks

Erstens braucht es den Herkunftsnachweis des IKM. Authentifiziertes Diffie-Hellman, Zufallsschlüssel, vorab geteiltes Geheimnis, Passwort und KDF-Ausgabe dürfen trotz gleicher Länge nicht in dieselbe Beweisklasse fallen.

Zweitens braucht es die Salt-Provenienz: Erzeugungsregel, Version, Authentifizierungsstatus, Wiederverwendungsregeln und die Begründung der Unabhängigkeit vom IKM. „Nicht geheim“ sagt nichts über Integrität der Herkunft.

Drittens ist der tatsächlich kodierte Kontext zu belegen. Protokollpräfix, Version, Suite, Label, Richtung, Transkript und Längenformat können als nicht geheimer Fingerabdruck gespeichert werden. Ein Anzeigename erkennt weder mehrdeutige Konkatenation noch unterschiedliche Zeichencodierung.

Viertens ist die Verwahrung der Ausgabe zu benennen: Schlüssel, IV, PRK, Export- oder Wiederaufnahmegeheimnis, zulässige Operation, Epoche und Löschzeit. Eine korrekte Ableitung heilt keine Nonce-Wiederverwendung und keine überlange Aufbewahrung.

Erst diese vier Nachweise begrenzen die Aussage eines übereinstimmenden Ergebnisses richtig. Gleichheit beweist reproduzierte Berechnung, nicht automatisch Authentifizierung, Quellenqualität, Zweck oder Löschung.

Quellen