XAES-256-GCM AEAD à nonce étendu

Présentation de XAES-256-GCM

• XAES-256-GCM est un algorithme de chiffrement authentifié (AEAD) utilisant une clé de 256 bits et un nonce de 192 bits
• Objectifs principaux :
  • prendre en charge en toute sécurité des nonces générés aléatoirement
  • conformité FIPS 140
  • mise en œuvre facile dans les bibliothèques de chiffrement courantes

Objectifs de conception de XAES-256-GCM

• utilisation d’un grand nonce permettant une génération aléatoire sûre pour un nombre illimité de messages
• possibilité d’utilisation dans divers environnements grâce à la conformité FIPS 140
• mise en œuvre simple afin de réduire la charge pour les utilisateurs

Principe de fonctionnement de XAES-256-GCM

• utilisation d’une structure de nonce étendue basée sur AES-256-GCM
• calcul d’une clé dérivée à partir de la clé d’entrée et du nonce
• traitement du message avec trois appels à AES-256

Mise en œuvre et optimisation

• l’implémentation de référence en Go tient en moins de 100 lignes de code
• utilise uniquement crypto/cipher et crypto/aes de la bibliothèque standard
• peut être décrit à l’aide de NIST SP 800-108r1 KDF et de NIST AES-256-GCM AEAD

Implémentations tierces et compatibilité

• des implémentations tierces existent pour .NET 8+, pyca/cryptography et l’API Web Cryptography
• impossible de modifier le nombre de rounds pour respecter la conformité FIPS 140

Alternatives et vecteurs de test

• il existe diverses alternatives, dont AES-GCM-SIV
• inclut des vecteurs de test pour les principaux chemins de code

Résumé

• XAES-256-GCM est conçu comme un AEAD sûr, conforme et interopérable
• il complète XChaCha20Poly1305 et AES-GCM-SIV
• espoir de le voir ajouté à la bibliothèque standard de Go

Avis de GN⁺

• l’usage d’un grand nonce par XAES-256-GCM pour renforcer la sécurité mérite l’attention
• la conformité FIPS 140 permet son utilisation dans divers environnements
• sa facilité d’implémentation dans des langages comme Go le rend utile aux développeurs
• des alternatives comme AES-GCM-SIV méritent aussi d’être prises en compte
• lors de l’adoption d’une nouvelle technologie, il faut examiner avec soin les performances et la compatibilité

[GN⁺]

Commentaire Hacker News

• Le design est très ingénieux : basé sur CMAC, il permet de dériver une clé avec AES-CBC lorsqu’on ne dispose pas de primitives de bas niveau

  • En termes AES-CBC :

    1. L = AES-CBC-256ₖ(iv = 0¹²⁸, plaintext = 0¹²⁸)[:16]
    2. Si MSB₁(L) = 0, alors K1 = L << 1;
       sinon 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 renvoie le premier bloc de 128 bits, et le bloc paddé est ignoré
  • À utiliser ensuite avec l’AES-GCM standard une fois la clé dérivée
  • Exemple d’implémentation JS basé sur l’API WebCrypto : lien GitHub
  • Accepte un CryptoKey approprié prévu pour AES-CBC et pouvant être stocké dans IndexedDB

• Le travail de Filippo est excellent : il résout le problème qui impose de faire tourner la clé toutes les ~2^32 messages lorsqu’on utilise des nonces aléatoires

  • En AES-GCM, une collision de nonce est catastrophique (elle permet à un attaquant de signer des messages arbitraires)
  • Il n’est pas obligatoire d’utiliser des nonces aléatoires, mais c’est généralement recommandé
  • C’est très malin d’avoir rendu cela conforme FIPS en s’appuyant sur deux primitives (une KDF à base de compteur et le GCM classique)

• J’aurais aimé que cela existe il y a quelques années quand j’écrivais un système de fichiers chiffré

  • Les collisions de nonce sont un vrai problème dans les déploiements de systèmes de fichiers à grande échelle
  • 2^32 paraît grand, mais sur des baies de plusieurs PB écrivant à 100k IOPS, les collisions sont quasiment garanties si l’on dépend du caractère aléatoire du PRNG

• J’espère que cela sera utilisé pour une variante conforme FIPS de age[1] pour le chiffrement de fichiers d’archive

  • Des auditeurs du secteur bancaire se sont opposés à age parce qu’il n’utilise pas AES à la place de ChaCha (la partie clé publique X25519 a récemment été approuvée par le NIST)
  • Je n’ai pas d’expérience avec golang, mais cela semble facile à adapter d’après la spécification de age
  • J’essaierai peut-être si j’ai le temps
  • Je l’appellerais « cage » (abréviation de « compliant actually good encryption »)

• Question de non-cryptographe : pourquoi utiliser un nonce de 192 bits plutôt que 256 bits ?

  • Dans les applications pratiques, il ne semble pas que les bits supplémentaires coûtent si cher

• (risque de collision de 2⁻³² à 2⁸⁰ messages)

  • Je me demande si la taille de bloc AES de 128 bits ne poserait pas problème avant cela