XAES-256-GCM: AEAD mit erweitertem Nonce

Einführung in XAES-256-GCM

• XAES-256-GCM ist ein Algorithmus für authentifizierte Verschlüsselung (AEAD), der einen 256-Bit-Schlüssel und einen 192-Bit-Nonce verwendet.
• Hauptziele:
  • sichere Unterstützung für zufällig erzeugte Nonces
  • FIPS-140-Konformität
  • einfache Implementierung in gängigen Kryptografie-Bibliotheken

Designziele von XAES-256-GCM

• Verwendung großer Nonces, damit sie für unbegrenzt viele Nachrichten sicher zufällig erzeugt werden können
• Einsetzbarkeit in unterschiedlichen Umgebungen durch FIPS-140-Konformität
• geringer Aufwand für Nutzer durch eine einfache Implementierung

Funktionsweise von XAES-256-GCM

• verwendet eine erweiterte Nonce-Struktur auf Basis von AES-256-GCM
• berechnet einen abgeleiteten Schlüssel aus Eingabeschlüssel und Nonce
• verarbeitet Nachrichten mit drei AES-256-Aufrufen

Implementierung und Optimierung

• Die Go-Referenzimplementierung umfasst weniger als 100 Zeilen Code.
• Verwendet nur crypto/cipher und crypto/aes aus der Standardbibliothek.
• Lässt sich mit NIST SP 800-108r1 KDF und NIST AES-256-GCM AEAD beschreiben.

Implementierungen von Drittanbietern und Kompatibilität

• Es gibt Implementierungen von Drittanbietern für .NET 8+, pyca/cryptography und die Web Cryptography API.
• Für FIPS-140-Konformität darf die Anzahl der Runden nicht verändert werden.

Alternativen und Testvektoren

• Es gibt verschiedene Alternativen wie AES-GCM-SIV.
• Enthält Testvektoren für wichtige Codepfade.

Zusammenfassung

• XAES-256-GCM ist als sicheres, konformes und interoperables AEAD konzipiert.
• Es ergänzt XChaCha20Poly1305 und AES-GCM-SIV.
• Es besteht die Hoffnung, dass es in die Go-Standardbibliothek aufgenommen wird.

Meinung von GN⁺

• Bemerkenswert an XAES-256-GCM ist die höhere Sicherheit durch die Verwendung großer Nonces.
• Durch FIPS-140-Konformität ist es in unterschiedlichen Umgebungen einsetzbar.
• Die einfache Implementierung in Sprachen wie Go macht es für Entwickler nützlich.
• Auch Alternativen wie AES-GCM-SIV sind eine Überlegung wert.
• Bei der Einführung neuer Technologien sollten Leistung und Kompatibilität sorgfältig geprüft werden.

[GN⁺]

Hacker-News-Kommentare

• Das Design ist sehr clever: CMAC-basiert, sodass sich der Schlüssel mit AES-CBC ableiten lässt, wenn Low-Level-Primitiven nicht verfügbar sind

  • In AES-CBC-Terminologie ausgedrückt:

    1. L = AES-CBC-256ₖ(iv = 0¹²⁸, plaintext = 0¹²⁸)[:16]
    2. MSB₁(L) = 0이면, K1 = L << 1;
       그렇지 않으면 K1 = (L << 1) ⊕ 0¹²⁰10000111
    3. M1 = 0x00 || 0x01 || X || 0x00 || N[:12]
    4. M2 = 0x00 || 0x02 || X || 0x00 || N[:12]
    5. Kₓ = AES-CBC-256ₖ(iv = K1, plaintext = M1)[:16] || AES-CBC-256ₖ(iv = K1, plaintext = M2)[:16]
    6. Nₓ = N[12:]
    

  • AES-CBC-256 gibt den ersten 128-Bit-Block zurück, der gepaddete Block wird verworfen
  • Nach der Schlüsselableitung wird es mit standardmäßigem AES-GCM verwendet
  • Beispiel einer JS-Implementierung auf Basis der WebCrypto API: GitHub-Link
  • Akzeptiert ein passendes für AES-CBC vorgesehenes CryptoKey und kann in IndexedDB gespeichert werden

• Filippos Arbeit ist hervorragend: Sie löst das Problem, dass bei der Verwendung zufälliger Nonces der Schlüssel etwa alle 2^32 Nachrichten rotiert werden muss

  • Nonce-Kollisionen sind bei AES-GCM fatal (der Angreifer kann dadurch beliebige Nachrichten signieren)
  • Es ist nicht nötig, zufällige Nonces zu verwenden, aber das wird im Allgemeinen empfohlen
  • Sehr clever, das FIPS-konform zu machen, indem zwei Primitiven verwendet werden (ein zählerbasierter KDF und normales GCM)

• Ich wünschte, das hätte es schon vor ein paar Jahren gegeben, als ich ein verschlüsseltes Dateisystem geschrieben habe

  • Nonce-Kollisionen sind ein großes Problem bei Dateisystem-Deployments im großen Maßstab
  • 2^32 klingt groß, aber in einem PB-Array mit 100k IOPS ist eine Kollision bei Abhängigkeit von PRNG-Zufälligkeit fast garantiert

• Ich hoffe, dass dies in einer FIPS-konformen Variante von age[1] für die Verschlüsselung von Archivdateien verwendet wird

  • Auditoren in der Bankenbranche waren gegen age, weil statt AES ChaCha verwendet wurde (der öffentliche X25519-Schlüsselteil wurde kürzlich von NIST genehmigt)
  • Ich habe keine Erfahrung mit Golang, aber gemäß der age-Spezifikation scheint es sich leicht anwenden zu lassen
  • Wenn die Zeit es erlaubt, werde ich es ausprobieren
  • Ich würde es "cage" nennen (kurz für "compliant actually good encryption")

• Frage eines Nicht-Kryptografen: Ich frage mich, warum ein 192-Bit-Nonce verwendet wird und nicht 256 Bit

  • In praktischen Anwendungen scheinen zusätzliche Bits nicht besonders teuer zu sein

• (Kollisionsrisiko von 2⁻³² bei 2⁸⁰ Nachrichten)

  • Da die AES-Blockgröße 128 Bit beträgt, frage ich mich, ob es davor zu Problemen kommen könnte