Calcul d’octets dans l’AES crypto
Estimez précisément la taille finale d’un message chiffré avec AES selon le mode, le padding, l’IV ou nonce, la taille du tag d’authentification et la clé. Cet outil aide à prévoir l’empreinte réseau, le stockage et les surcoûts cryptographiques réels.
Calculateur AES
Guide expert du calcul d’octets dans l’AES crypto
Le calcul d’octets dans l’AES crypto consiste à estimer la taille réelle d’un message une fois chiffré. Cette question paraît simple, mais elle dépend de plusieurs paramètres techniques : la taille du texte en clair, le mode de chiffrement utilisé, l’ajout éventuel d’un padding, la présence d’un IV ou d’un nonce, et parfois d’un tag d’authentification. Pour les architectes cloud, les développeurs backend, les responsables sécurité et les ingénieurs réseau, cette estimation n’est pas théorique. Elle a un impact direct sur le stockage, la bande passante, la latence et même la conception des formats de trames.
AES, ou Advanced Encryption Standard, repose toujours sur un bloc de 128 bits, soit 16 octets. En revanche, la clé peut faire 128, 192 ou 256 bits, soit respectivement 16, 24 ou 32 octets. Beaucoup de personnes confondent la taille de bloc et la taille de clé. Or, dans un calcul d’encombrement des données chiffrées, c’est d’abord la taille de bloc de 16 octets qui détermine l’effet du padding dans les modes par blocs comme CBC et ECB.
Pourquoi la taille finale change-t-elle après chiffrement ?
La taille finale peut rester identique au texte en clair, ou augmenter légèrement, voire davantage si plusieurs éléments sont transmis avec le message. Dans les modes par flot comme CTR, OFB ou souvent CFB, la taille du texte chiffré reste en général égale à la taille du texte clair. Dans les modes par blocs avec padding, comme CBC avec PKCS7, le message est complété jusqu’au bloc suivant. Cela signifie qu’un message de 1 octet devient 16 octets de ciphertext, et qu’un message de 16 octets devient 32 octets si l’on applique PKCS7, car un bloc complet de padding est ajouté.
En mode GCM, il faut aussi prendre en compte un tag d’authentification, souvent de 16 octets, et un nonce, fréquemment de 12 octets. Si votre protocole transmet explicitement ces éléments, ils augmentent la taille totale. Dans CBC, il faut généralement transmettre un IV de 16 octets. En pratique, l’erreur la plus fréquente est d’oublier ces octets annexes alors qu’ils voyagent réellement avec le message.
Les éléments à additionner dans un calcul AES
- Données en clair : taille d’origine du message.
- Padding : ajouté seulement dans certains modes, surtout CBC et ECB.
- IV ou nonce : souvent transmis avec le ciphertext.
- Tag d’authentification : typique de GCM, parfois 16 octets.
- Encodage applicatif : par exemple Base64 augmente encore la taille, même si ce calculateur se concentre sur les octets bruts.
Formules pratiques par mode
Voici les formules les plus utiles pour estimer la taille du ciphertext brut :
- AES-CBC avec PKCS7 : taille ciphertext = (⌊n / 16⌋ + 1) × 16
- AES-CBC sans padding : taille ciphertext = n, mais uniquement si n est multiple de 16
- AES-ECB avec PKCS7 : même logique que CBC pour la taille
- AES-CTR, AES-CFB, AES-OFB : taille ciphertext = n
- AES-GCM : taille ciphertext = n, puis ajouter le tag et souvent le nonce transmis
Le total transmis peut donc être résumé par : total = ciphertext + IV ou nonce + tag. La taille de clé n’est généralement pas transportée avec chaque message. Elle sert surtout à documenter le paramétrage cryptographique et à rappeler que la clé AES-128 fait 16 octets, AES-192 fait 24 octets, et AES-256 fait 32 octets.
Tableau de référence AES issu des standards
| Version AES | Taille de clé | Taille de bloc | Nombre de rounds | Taille de clé en octets |
|---|---|---|---|---|
| AES-128 | 128 bits | 128 bits | 10 | 16 octets |
| AES-192 | 192 bits | 128 bits | 12 | 24 octets |
| AES-256 | 256 bits | 128 bits | 14 | 32 octets |
Ces valeurs proviennent des spécifications officielles AES. Elles sont essentielles pour comprendre qu’une clé plus longue n’augmente pas la taille du bloc chiffré. En revanche, la clé plus longue implique davantage de rounds. Pour le calcul d’octets côté message, ce point ne modifie pas la taille du ciphertext, mais il reste important pour l’analyse globale d’un système.
Exemples concrets de calcul d’octets
Prenons un message de 1000 octets. En AES-CTR, le ciphertext fera 1000 octets. Si vous ajoutez un nonce de 16 octets, le total transmis devient 1016 octets. En AES-GCM avec nonce de 12 octets et tag de 16 octets, le total transmis est de 1028 octets. En AES-CBC avec PKCS7, 1000 n’étant pas multiple de 16, il faut arrondir au bloc suivant. Le ciphertext devient alors 1008 octets. Avec un IV de 16 octets, le total transmis monte à 1024 octets.
Autre exemple important : si votre texte clair fait exactement 1024 octets en CBC avec PKCS7, la taille chiffrée n’est pas 1024 mais 1040 octets, car un bloc complet de padding de 16 octets est ajouté. Avec l’IV transmis, le total atteint 1056 octets. Cette nuance est souvent oubliée dans les estimations d’API, de fichiers chiffrés ou d’enveloppes CMS.
Tableau comparatif d’encombrement pour un message de 1000 octets
| Mode AES | Padding | IV / nonce | Tag | Ciphertext brut | Total transmis | Surcoût |
|---|---|---|---|---|---|---|
| CBC | PKCS7 | 16 octets | 0 | 1008 octets | 1024 octets | +24 octets |
| CTR | Aucun | 16 octets | 0 | 1000 octets | 1016 octets | +16 octets |
| GCM | Aucun | 12 octets | 16 octets | 1000 octets | 1028 octets | +28 octets |
| ECB | PKCS7 | 0 | 0 | 1008 octets | 1008 octets | +8 octets |
Comment interpréter ce surcoût
Sur un fichier volumineux, quelques octets semblent négligeables. Mais à grande échelle, l’effet est sensible. Sur 10 millions de messages de 1000 octets chiffrés en GCM avec nonce 12 octets et tag 16 octets, le surcoût brut théorique représente 280 millions d’octets, soit environ 267 MiB supplémentaires transmis. Dans un environnement mobile, IoT ou edge, cette différence a un coût réel en radio, batterie, latence et stockage.
Le bon calcul d’octets dans l’AES crypto est donc une étape d’ingénierie. Il permet de :
- dimensionner une base de données ou un objet de stockage chiffré,
- prévoir la taille des colonnes et des blobs,
- définir les limites de payload API,
- estimer la bande passante sur des millions de transactions,
- éviter les erreurs de sérialisation ou de framing réseau.
Différence entre octets bruts, hexadécimal et Base64
Le calculateur ci-dessus travaille en octets bruts. En pratique applicative, on encode souvent le résultat en hexadécimal ou en Base64 pour l’inclure dans du JSON, de l’URL-safe text ou des entêtes. Or ces encodages augmentent encore la taille :
- Hexadécimal : 1 octet devient 2 caractères, soit un facteur 2.
- Base64 : augmentation d’environ 33 % dans le cas général.
Si votre message AES-GCM totalise 1028 octets bruts, son encodage Base64 prendra environ 1372 caractères, selon les détails d’alignement. Beaucoup d’estimations échouent parce qu’elles mélangent la taille cryptographique brute et la taille textuelle encodée.
Bonnes pratiques pour un calcul fiable
- Identifier d’abord le mode exact : CBC, CTR, GCM, etc.
- Vérifier si un padding est utilisé et lequel.
- Déterminer si l’IV ou le nonce est transmis avec chaque message.
- Mesurer la taille du tag si le mode est authentifié, notamment GCM.
- Ne pas confondre la taille de clé avec la taille du ciphertext.
- Ajouter ensuite le coût de l’encodage applicatif si nécessaire.
Quels standards consulter ?
Pour aller à la source, les références les plus fiables sont les publications NIST et certains supports académiques. Vous pouvez consulter :
- NIST FIPS 197, spécification officielle d’AES
- NIST SP 800-38A, modes de chiffrement par blocs
- NIST SP 800-38D, recommandation GCM et GMAC
Faut-il préférer GCM pour les nouveaux projets ?
Dans la plupart des conceptions modernes, GCM est très apprécié car il apporte la confidentialité et l’authenticité. Son coût en octets est simple à comprendre : le ciphertext garde la taille du message, puis on ajoute généralement un nonce de 12 octets et un tag de 16 octets. Cela le rend très prévisible. CBC, lui, reste utile dans des contextes hérités, mais il exige une gestion correcte du padding et de l’intégrité au niveau applicatif ou via une composition adaptée. Pour un calcul d’octets précis, GCM est souvent plus facile à modéliser.
Résumé opérationnel
Si vous ne retenez qu’une méthode, retenez celle-ci : commencez par la taille du texte clair, appliquez la règle du mode choisi, ajoutez l’IV ou le nonce, ajoutez le tag si nécessaire, puis seulement après tenez compte d’un éventuel encodage Base64 ou hexadécimal. Pour CBC et ECB avec PKCS7, pensez toujours à l’ajout d’un bloc complet lorsque la taille est déjà multiple de 16. Pour CTR, OFB, CFB et GCM, la taille du ciphertext brut reste généralement égale à celle du message. La qualité d’une architecture sécurisée passe aussi par ce type de précision chiffrée.