Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Le choix de l’AEAD aead Décidé

Le danger « réutilisation de nonce » qu'on agite d'habitude ne s'applique presque pas ici. Une fois ce faux problème écarté, le vrai critère est le matériel — et il pointe vers XChaCha20-Poly1305.

Le faux problème. La catastrophe d’AES-GCM, c’est un même (clé, nonce) sur deux clairs différents. Or sur le chemin des chunks, la clé est dérivée du contenu : clé_chunk = BLAKE3_keyed(secret, chunk). Deux chunks différents → deux clés différentes ; deux fois le même chunk → même clé, même chiffré (ce qu’on veut pour la dédup). Le cas dangereux — même clé, même nonce, clair différent — ne peut pas se produire par construction, car la clé est unique par clair. On peut même prendre un nonce constant. La seule « fuite » : deux chiffrés identiques trahissent deux clairs identiques — ce que la dédup révèle déjà.

Où le nonce compte vraiment — les métadonnées Manifestes et racines ne sont pas convergents : une seule clé de tenant, longue durée de vie, des millions de clairs différents, nonce aléatoire. Là, la collision de nonce redevient réelle — un nonce de 96 bits (AES-GCM) tombe sous la borne anniversaire. Deux réponses : un nonce assez grand (XChaCha = 192 bits), ou la misuse-resistance (GCM-SIV).

Le vrai critère : le matériel. AES n’est rapide qu’avec accélération (AES-NI sur x86, extensions ARMv8). Sans elle, l’AES logiciel est lent et vulnérable au cache-timing (implémentations à table-T qui fuient la clé). ChaCha20 est constant-time par conception et rapide en logiciel pur.

Débit AEAD mesuré — 16 Ko/bloc, 1 cœur

AVEC AES-NI · MACHINE NORMALE AES-256-GCM 3,68 AES-256-GCM-SIV* ~2,4 XChaCha20-Poly1305 2,08 SANS AES-NI · NAS BAS DE GAMME* AES-256-GCM ~0,2 ⚠ fuite cache-timing XChaCha20-Poly1305 ~0,7 0 1 2 3 4 GB/s

Mesuré sur x86 AES-NI, 1 cœur, blocs 16 Ko (openssl speed). *GCM-SIV et le cas sans AES-NI sont estimés. La ligne corail = débit Gigabit Ethernet (~0,125 GB/s) : même la branche la plus lente sature le réseau.

Sur cette machine, AES-GCM va ~1,8× plus vite que ChaCha. Mais trois choses font fondre cet écart :

  • Ce n'est pas le bon candidat. Ton candidat était AES-GCM-SIV, qui fait deux passes (~2,4 GB/s). Face aux ~2,08 de XChaCha, l'écart réel n'est plus 1,8× mais ~1,1-1,25×.
  • Le chiffrement n'est pas le goulot. À 2 GB/s, tu es bien au-dessus du disque et du réseau.
  • Sur NAS sans AES-NI, le rapport s'inverse. L'AES logiciel chute à ~0,1-0,3 GB/s et fuit la clé par cache-timing ; ChaCha tient ~0,5-1 GB/s et reste constant-time.
Décision — XChaCha20-Poly1305 partout Chunks : nonce déterministe. Métadonnées : nonce aléatoire 192 bits, zéro souci de collision. Un seul code-path, constant-time sur toute la flotte hétérogène. En Rust : crate chacha20poly1305 (RustCrypto), XChaCha20Poly1305.

Honnêteté. L’extension XChaCha (nonce 192 bits) est un draft CFRG, pas un RFC final — mais déployée depuis des années via libsodium et considérée solide. AES-GCM-SIV reste défendable si ta flotte réelle est massivement x86/ARMv8-crypto. Vu les NAS bas de gamme dans la cible, on tranche ChaCha.