Zusammenfassung

  • RFC 9861 definiert vier XOFs; ein konkretes Ergebnis hängt zusätzlich von Eingabebytes, Domänenbyte oder Anpassungsstring und der gewünschten Länge ab.
  • Bei KT128 und KT256 entscheidet die vollständig codierte Eingabe über den Wechsel zum Baumverfahren oberhalb von 8192 Bytes.
  • IRTF-Informational-Status und IANA-Einträge schaffen gemeinsame Bezeichnungen, aber keine lokale Implementierungs- oder Einsatzfreigabe.

Die Migration kannte den Algorithmus, aber nicht mehr den Aufruf. Im Archiv stand KT256; daneben lag ein Wert. Ob die alte Anwendung eine leere Anpassung, 64 Ausgabebytes oder eine besondere Serialisierung verwendet hatte, war nicht dokumentiert. Das neue System konnte den Namen wiederholen, nicht jedoch das Ergebnis.

RFC 9861 definiert TurboSHAKE128, TurboSHAKE256, KT128 und KT256. Das Dokument erschien im Oktober 2025 als Informational RFC im IRTF-Strom. Es trägt den Konsens der Crypto Forum Research Group, ist aber kein IETF Internet Standard. Damit liefert es eine stabile gemeinsame Spezifikation, nicht die Entscheidung eines Betreibers, sie einzusetzen.

Die Länge gehört zur kryptografischen Frage

TurboSHAKE verarbeitet Nachricht M, Domänentrennbyte D und positive Ausgabelänge L. Gültige D-Werte reichen von 01 bis 7F; Standard ist 1F. Bei gleichem M und D ist eine kürzere Ausgabe Präfix der längeren.

Das macht Längen nicht austauschbar. Ein Protokollfeld mit 32 Bytes und eines mit 64 Bytes haben unterschiedliche Verträge, auch wenn der kurze Wert am Anfang des langen steht. Wer L nicht speichert, kann später nicht unterscheiden, ob die Länge beabsichtigt, von einer API erzwungen oder in der Datenbank abgeschnitten wurde.

Bei inkrementeller Eingabe müssen die Teile dasselbe Resultat liefern wie ihre Verkettung in Anlieferungsreihenfolge. Inkrementell gelesene Ausgabe muss zusammengesetzt der einmaligen Anfrage nach der Gesamtlänge entsprechen. Puffergrenzen sind lokal; die Bytefolge ist Teil der gemeinsamen Wahrheit.

Anpassung ist Eingabe, nicht Kommentar

KT128 und KT256 nehmen den optionalen String C. Sie bilden reversibel S = M || C || length_encode(|C|). Ein URI, Mandantenwert oder Protokollname in C beeinflusst damit direkt die Ausgabe.

Die zuständige Stelle sitzt möglicherweise außerhalb der Kryptobibliothek. Ändert ein Serializer Unicode, URI-Normalisierung oder Großschreibung, entstehen andere Werte bei unverändertem Funktionsnamen. Ein Inventar, das nur KT128 meldet, verschweigt diese Steuerungsfläche.

Auch „leer“ braucht Herkunft: ausdrücklich leer, durch eine API ohne Anpassungsparameter erzwungen oder während einer Migration verloren. Heute kann der Aufruf gleich aussehen; morgen unterscheidet sich seine Rekonstruierbarkeit.

Die 8192-Byte-Grenze gilt für S

KangarooTwelve zerlegt S in Stücke zu 8192 Bytes. Bis einschließlich dieser Größe bleibt ein einzelner Knoten. Darüber erzeugen spätere Stücke Verkettungswerte, die mit dem ersten Stück und der Baumcodierung im Endknoten zusammenlaufen. KT128 nutzt 32-Byte-, KT256 64-Byte-Verkettungswerte.

Da S auch C und dessen Längencodierung enthält, kann allein eine geänderte Anpassung den internen Modus wechseln. Konformitätstests sollten unmittelbar unter, auf und über der Grenze laufen – jeweils mit leerem und nichtleerem C.

Parallele Verarbeitung ist erlaubt; abweichende Endwerte sind es nicht. SIMD, Prozessor und Hardwarebackend können die Laufzeit verändern, nicht den Beleg. Dieser Bericht misst keine Leistung und bestätigt kein Produkt.

Registrierte Profile schließen nur einen Teil der Lücke

Im IANA-Register Named Information bezeichnet k12-256 fest KT128 mit leerem C und 32 Bytes Ausgabe. k12-512 bezeichnet KT256 mit leerem C und 64 Bytes. Solche Profile sind enger als die bloßen Familiennamen.

Das IANA-Register COSE Algorithms weist allen vier Funktionen Zahlen zu. Ein Codepunkt koordiniert Bedeutung. Er zeigt weder Eingabebytes noch Protokollparameter, Bibliotheksbuild, Teststatus oder Schlüsselschutz.

RFC 9861 beansprucht je nach Variante 128 oder 256 Bit Sicherheit und stützt dies auf Analyse des auf zwölf Runden reduzierten Keccak sowie Sakura-Codierung. NIST FIPS 202 beschreibt Keccak/SHA-3; SP 800-185 verwandte abgeleitete Funktionen. Diese Herkunft ist keine Zertifizierung eines lokalen Binaries oder eines Seitenkanalschutzes.

Ein gemeldetes Erratum zeigt den Wert vollständiger Argumente

Die RFC enthält Vektoren über Varianten, Längen, Nachrichten, Anpassungen und Baumgrenzen. Im Errata-Register steht der technische Eintrag 8997 weiterhin auf Reported. Er weist darauf hin, dass bei mehreren KT-Aufrufen die Bezeichnung M= vor dem ersten Positionsargument fehlt. Die vorgeschlagene Änderung vereinheitlicht die Beschriftung; die ausgegebenen Bytes werden nicht ersetzt.

Reported ist nicht Verified. Ein Prüfbeleg muss diesen Status ebenso speichern wie Vektor, vollständige Argumente, Soll- und Istwert, Build, Hardwarepfad und Zeitpunkt. „Tests bestanden“ ist keine reproduzierbare Aussage.

Übereinstimmende Bytes entscheiden keine Handlung

RFC 9861 definiert HopMAC und erlaubt weitere reversible Schlüsselplatzierungen. Daher legt „KT128 MAC“ Konstruktion, Schlüsselverwahrung, Anpassung und Taglänge nicht fest. Selbst perfekte Übereinstimmung beweist nur die Ausführung des deklarierten Bytevertrags, nicht Urheberschaft, Aktualität, Freigabe oder Geschäftsergebnis.

Spezifikation, Profil, Serialisierung, Ausführung, Vergleich, Protokollannahme und reale Wirkung bleiben getrennte Nachweise. Ihre Verbindung schafft Verantwortlichkeit; ihre Vermischung macht aus einem Namen eine Autorität, die er nie hatte.

Quellen