XTS-AES schützt keine Echtheit – NIST schärft die Einsatzgrenzen

Das US-amerikanische National Institute of Standards and Technology (NIST) veröffentlichte am 3. September 2026 den ersten öffentlichen Entwurf von SP 800-38E Revision 1. Die Ankündigung des NIST bestätigt den Entwurfsstatus und nennt den 16. Oktober 2026 als Ende der Kommentierungsfrist.
Der am 3. September veröffentlichte Entwurf schärft den von NIST gebilligten Einsatzrahmen für XTS-AES auf blockorientierten Speichergeräten. Ein Bericht des Digital Forensics Magazine bestätigt unabhängig die Veröffentlichung und den Fokus auf IEEE 1619-2025 sowie präzisierte Anforderungen an Dateneinheiten und Schlüsselbereiche. Unverändert bleibt die entscheidende Grenze: XTS-AES schützt die Vertraulichkeit, authentifiziert aber weder die Daten noch ihre Herkunft.
Die Billigung gilt nur für blockorientierte Speicher
NIST billigt XTS-AES nicht als universellen Verschlüsselungsmodus. Der Entwurf begrenzt den Anwendungsbereich auf den Vertraulichkeitsschutz von Daten auf blockorientierten Speichergeräten, bei denen Daten innerhalb eines Schlüsselbereichs in Einheiten fester Länge organisiert und ohne Vergrößerung verschlüsselt werden.
Außerhalb dieses Rahmens liegen ausdrücklich Datenübertragung, Nachrichtenverschlüsselung, Key Wrapping und Anwendungen, die authentifizierte Verschlüsselung voraussetzen. Eine Implementierung kann XTS-AES daher für Laufwerkssektoren konform einsetzen, ohne damit zugleich eine geeignete Lösung für Nachrichten oder den manipulationssicheren Nachweis gespeicherter Inhalte bereitzustellen.
Für Sicherheitsarchitekturen und Prüfberichte ist diese Trennung materiell: Die Konformität einer Speicherverschlüsselung belegt nur die im Dokument gebilligte Schutzleistung. Sie erweitert den Modus weder um Integrität noch um eine Bestätigung, von welcher Quelle die entschlüsselten Daten stammen.
IEEE-Verweis und quantitative Grenzen werden konkreter

Die Fassung von 2010 billigte XTS-AES durch einen Verweis auf IEEE Std. 1619-2007. Revision 1 verweist stattdessen auf IEEE Std. 1619-2025 und behandelt diese datierte Ausgabe als maßgebliche technische Spezifikation. Eine spätere Revision oder Ergänzung des IEEE-Standards wäre nicht automatisch eingeschlossen; dafür müsste auch die NIST-Empfehlung aktualisiert werden.
Der offizielle Entwurfstext legt fest, dass eine Dateneinheit mindestens 128 Bit umfasst und höchstens 2 hoch 20 Blöcke zu jeweils 128 Bit enthalten darf. Die Dateneinheiten innerhalb eines Schlüsselbereichs sind gleich groß. Für den gesamten Schlüsselbereich gilt eine Obergrenze von 2 hoch 44 solcher Blöcke; als Wert für optimale Sicherheit nennt der Entwurf höchstens 2 hoch 36 Blöcke.
Auch die Schlüsselprüfung ist eindeutig formuliert. Ein XTS-AES-Schlüssel ist 256 oder 512 Bit lang und setzt sich aus zwei gleich langen AES-Schlüsseln zusammen: dem Schlüssel für die Datenverschlüsselung und dem Tweak-Schlüssel. Beide dürfen nicht identisch sein, und eine Implementierung muss ihre Ungleichheit vor der Ver- oder Entschlüsselung ausdrücklich prüfen. Eingeschränkte Unterstützung nur einer Schlüssellänge oder bestimmter Dateneinheitslängen bleibt möglich, kann aber die Interoperabilität begrenzen.
Warum Verschlüsselung hier keine Echtheit belegt

Mit „Echtheit“ ist in diesem Zusammenhang der kryptografische Nachweis gemeint, dass Daten unverändert sind und aus der behaupteten Quelle stammen. Genau diese Zusicherung gibt XTS-AES nicht. Der Modus schützt gespeicherte Klartexte vor dem unmittelbaren Lesen, erzeugt aber allein keinen Authentifizierungsnachweis und keinen Integritätsschutz.
Ein bedrohungsorientiertes, ausdrücklich hypothetisches Szenario zeigt die Folge: Ein Angreifer mit Schreibzugriff verändert den Chiffretext eines Speicherbereichs. Bei der späteren Entschlüsselung prüft XTS-AES kein Authentifizierungsmerkmal, das eine solche Änderung zuverlässig als Manipulation ausweist. Welche Auswirkungen die Änderung auf den Klartext hat, hängt von den veränderten Daten ab; aus der erfolgreichen Entschlüsselung lässt sich jedenfalls keine Unverändertheit ableiten.
Ein Audit darf die Aussage „mit XTS-AES verschlüsselt“ deshalb nicht mit gesicherter Provenienz oder Beweiskraft gleichsetzen. Benötigt ein System solche Eigenschaften, sind zusätzliche Mechanismen außerhalb von XTS-AES erforderlich. Welche Konstruktion dafür passt, hängt vom jeweiligen System und Bedrohungsmodell ab; der Revisionsentwurf schreibt keine allgemeingültige Ergänzung vor.
Ciphertext Stealing wird an der externen Schnittstelle festgemacht

Ciphertext Stealing erlaubt die Verarbeitung einer Dateneinheit, deren Länge kein ganzzahliges Vielfaches des 128-Bit-AES-Blocks ist, ohne den Chiffretext zu vergrößern. Die Einheit besteht dabei aus vollständigen Blöcken und einem abschließenden, nicht leeren Teilblock.
Der Entwurf präzisiert, woran Konformität in diesem Fall gemessen wird. Eine Implementierung darf den letzten vollständigen Chiffretextblock und den Teilblock intern in der umgekehrten physischen Reihenfolge speichern. Jede externe Schnittstelle muss sie jedoch in der von IEEE Std. 1619-2025 vorgegebenen Reihenfolge ausgeben, damit die Interoperabilität nicht beeinträchtigt wird.
Implementierungen dürfen sich außerdem auf Dateneinheiten aus vollständigen 128-Bit-Blöcken beschränken. Dann werden die Komponenten für Ciphertext Stealing nicht benötigt. Entscheidend ist, dass der unterstützte Umfang klar abgegrenzt und die extern sichtbare Verarbeitung mit den beanspruchten Konformitätsanforderungen vereinbar bleibt.
Bis zum 16. Oktober bleibt der Text veränderbar
SP 800-38E Revision 1 ist noch keine verabschiedete Endfassung. Zur öffentlichen Prüfung stehen insbesondere der neue normative Bezug, die Obergrenzen für Dateneinheiten und Schlüsselbereiche, die Prüfung der beiden Teilschlüssel sowie die Schnittstellenregel für Ciphertext Stealing.
Fest steht bereits, welche Sicherheitsleistung NIST dem Modus zuschreibt: Vertraulichkeit in einem eng definierten Speicherrahmen, nicht Authentifizierung oder Integrität. Offen bleibt bis zur Auswertung der Kommentare, welche Formulierungen und Anforderungen NIST in die spätere Endfassung übernimmt.
Lesen Sie auch:
Newsletter abonnieren
Erhalten Sie die neuesten Nachrichten zu Web3, KI und Krypto direkt in Ihren Posteingang.