Jedes verschlüsselte Dateiformat muss eine stille Frage beantworten: Was hindert einen Angreifer daran, die Teile zu bearbeiten, die nicht geheim sind? StenVaults Dateiformat, CVEF, hat die Antwort auf die harte Tour gelernt — und v1.4 ist die Behebung.
Eine CVEF-Datei besteht aus einem kleinen Header, einem Block JSON-Metadaten und der verschlüsselten Nutzlast. Die Metadaten deklarieren die kryptografische Suite: den Algorithmus, den umschlossenen Dateischlüssel und — ab v1.3 — eine hybride Signatur (Ed25519 + ML-DSA-65), die belegt, wer die Datei versiegelt hat.
Die Lücke: Metadaten, die niemand authentifizierte
Bis v1.3 waren diese JSON-Metadaten weder verschlüsselt noch authentifiziert. Das AES-256-GCM-Tag deckte die Nutzlast ab, nicht den Header darum herum. Bei den meisten Feldern scheitert das sicher — ändert man den umschlossenen Schlüssel, erzeugt die Entschlüsselung schlicht Müll und bricht ab. Ein Feld scheiterte nicht sicher: die version.
Signaturen in CVEF sind reine Metadaten — sie werden zum Entschlüsseln der Datei nicht benötigt. Ein Angreifer mit Schreibzugriff auf eine gespeicherte Datei konnte also eine signierte v1.3-Datei nehmen, das Feld `signatureParams` entfernen und `version` von `1.3` auf `1.2` ändern. Das Ergebnis ist eine vollkommen gültige v1.2-Datei. Sie entschlüsselt korrekt. Und sie trägt keine Signatur — ohne dass der Empfänger erfahren könnte, dass jemals eine vorhanden war.
Das ist die klassische Form eines Downgrade: Brechen Sie nicht die Krypto, reden Sie den Leser einfach in einen schwächeren Modus herab. Es ist dieselbe Familie wie das Signatur-Stripping bei TLS, und es hebt still die Unabstreitbarkeit auf, die die v1.3-Signaturen bieten sollten.
Die Behebung: die Version in den Chiffretext binden
v1.4 schließt die Lücke, indem es die Metadaten selbst authentifiziert. Der serialisierte Header — einschließlich der version und der Signaturparameter — wird der AEAD als Additional Authenticated Data (AAD) zugeführt. Das GCM-Tag deckt nun sowohl die Nutzlast als auch die Metadaten ab, die sie beschreiben.
AES-256-GCM(
key: fileKey,
iv: iv,
plaintext: fileBytes,
aad: canonical(metadata) ← new in v1.4
)Kippen Sie ein einziges Byte des Headers — die Version herabstufen, die Signatur entfernen, einen Algorithmusnamen austauschen — und das Tag verifiziert nicht mehr. Die Entschlüsselung bricht ab, bevor irgendein Klartext erzeugt wird. Der Downgrade wird nicht im Nachhinein erkannt; es ist strukturell unmöglich, ihn als gültig auszugeben.
Es ist dieselbe Verteidigung, die Age (HMAC über den Header), JWE (geschützter Header als AAD) und COSE allesamt verwenden: Die Beschreibung des Chiffretexts an den Chiffretext zu binden, ist der einzige Weg, das Manipulieren daran scheitern zu lassen.
Abwärtskompatibilität, ohne den Schuss ins eigene Knie
CVEF ist genau aus diesem Grund versioniert. Neue Dateien werden als v1.4 geschrieben; der Reader akzeptiert weiterhin v1.2, v1.3 und v1.4, damit bestehende Vaults sich weiter öffnen lassen. Was er nicht tut, ist still eine v1.3-Datei zu akzeptieren, deren Signatur abgeschält wurde — die AAD-Bindung macht die Version zum Teil des Beweises und nicht zu einem Hinweis, dem der Reader vertrauen muss.
Gute Kryptografie dreht sich selten um einen clevereren Algorithmus. Häufiger geht es darum, keine unauthentifizierte Fläche zu lassen, auf die sich ein Angreifer stützen kann. v1.4 entfernt die letzte, die CVEF hatte.