Cryptage AES pour les développeurs Quand vous en avez besoin et comment elle fonctionne

Si vous stockez des données sensibles — des informations personnelles des utilisateurs, des clés API, des enregistrements financiers — l'encryption AES est l'outil que vous devez utiliser. C'est la norme de l'industrie pour l'encryption symétrique au repos : rapide, éprouvée dans le temps et prise en charge nativement dans toutes les principales langues.

Mais l'AES mal implémenté est pire que sans utilité. Le mode ECB révèle des motifs. Le réutilisation d'un IV avec GCM annule entièrement sa garantie de sécurité. Et le stockage de votre clé à côté de votre chiffrement annule tout le sens de l'opération.

Voici ce que vous devez réellement utiliser pour appliquer correctement l'AES en production.

Qu'est-ce que l'AES ?

L'AES (Advanced Encryption Standard) est un chiffrement symétrique à bloc. Symétrique signifie que la même clé est utilisée pour chiffrer et déchiffrer. Chiffrement à bloc signifie qu'il opère sur des blocs fixes de 128 bits de données.

Il a remplacé le DES en 2001, et aujourd'hui il est partout : TLS, chiffrement du disque, gestionnaires de mots de passe, chiffrement des champs de base de données. Contrairement au chiffrement asymétrique (RSA, ECDH), l'AES est rapide assez pour chiffrer de grandes quantités de données en temps réel. Le compromis : les deux parties doivent partager la même clé, donc la distribution de la clé devient votre problème.

AES-128 vs AES-256 : quelle taille de clé ?

L'AES existe en trois tailles de clés : 128, 192 et 256 bits. En pratique, vous choisirez entre 128 et 256.

	AES-128	AES-256
Longueur de clé	128 bits	256 bits
Rondes	10	14
Performance	Plus rapide	Environ 401 TP7T plus lent
Sécurité	Fort — aucune attaque pratique connue	Plus fort — résistant à l'avenir face aux ordinateurs quantiques
Verdict	Adapté à la plupart des applications	Utilisez-le pour des données sensibles ou pour une conservation prolongée

L'AES-128 n'est pas cassé. Aucune attaque pratique n'existe. Mais si vous chiffrer des données qui doivent rester sécurisées pendant plus de 20 ans — ou si votre modèle de menace inclut des ordinateurs quantiques — l'AES-256 ajoute une marge significative. Pour la plupart des applications de chiffrement des champs de base de données aujourd'hui, l'AES-128 est suffisant. En cas de doute, utilisez l'AES-256 ; la perte de performance est négligeable pour les charges typiques.

Mode d'opération : pourquoi GCM et pas ECB

L'AES seul chiffre uniquement un bloc de 128 bits. Pour des données réelles, vous avez besoin d'un mode d'opération qui gère plusieurs blocs et les séquence correctement. Ce choix est crucial.

Mode	Authentifié	IV requis	Verdict
ECB	Non	Non	N'utilisez jamais — des textes identiques produisent des chiffrements identiques, ce qui révèle des motifs
CBC	Non	Oui	Dépassé — pas d'authentification, vulnérable aux attaques de padding oracle
GCM	Oui (AEAD)	Oui (nonce)	Utilisez cela — chiffre et authentifie en une passe

Utilisez GCM. GCM (Galois/Counter Mode) est un chiffrement AEAD — Authenticated Encryption with Associated Data. Il fait deux choses en même temps :

1. Chiffre vos données afin qu'elles soient illisibles sans la clé
2. Produit une étiquette d'authentification afin que toute modification soit détectée immédiatement

Sans authentification, un attaquant peut inverser des bits dans votre chiffrement et vous déchiffrerez du bruit sans le savoir. Avec GCM, la déchiffrement échoue brutalement si le chiffrement a été modifié — avant même que le texte clair ne soit retourné.

L'IV/Nonce : aléatoire, jamais réutilisé

GCM nécessite un vecteur d'initialisation (IV), également appelé nonce — « nombre utilisé une fois ». L'IV n'a pas besoin d'être secret, mais il doit être :

• Aléatoire — généré avec un générateur aléatoire cryptographique
• Unique — jamais réutilisé avec la même clé

Le réutilisation d'un IV avec la même clé dans GCM est catastrophique. Un attaquant qui voit deux chiffrements cryptés avec la même clé et IV peut les XORer ensemble et récupérer les deux textes clairs. Ce n'est pas théorique — cela s'est produit dans des systèmes en production.

Utilisez un IV aléatoire de 96 bits (12 octets) par opération de chiffrement. Puisque vous en avez besoin pour la déchiffrement, stockez-le à côté du chiffrement — préfixer l'IV au chiffrement est le format conventionnel.

Code fonctionnel : AES-256-GCM

Voici des extraits prêts à l'emploi. Les deux stockent l'IV et l'étiquette d'authentification avec le chiffrement afin que la déchiffrement soit autonome.

Node.js

const crypto = require('crypto');

const ALGORITHM = 'aes-256-gcm';
const KEY_LENGTH = 32; // 256 bits
const IV_LENGTH  = 12; // 96 bits — recommended for GCM
const TAG_LENGTH = 16; // 128-bit auth tag

function encrypt(plaintext, key) {
  const iv = crypto.randomBytes(IV_LENGTH);
  const cipher = crypto.createCipheriv(ALGORITHM, key, iv);

  const encrypted = Buffer.concat([
    cipher.update(plaintext, 'utf8'),
    cipher.final(),
  ]);
  const tag = cipher.getAuthTag();

  // Layout: [iv (12)] + [tag (16)] + [ciphertext]
  return Buffer.concat([iv, tag, encrypted]).toString('base64');
}

function decrypt(ciphertextB64, key) {
  const data      = Buffer.from(ciphertextB64, 'base64');
  const iv        = data.subarray(0, IV_LENGTH);
  const tag       = data.subarray(IV_LENGTH, IV_LENGTH + TAG_LENGTH);
  const encrypted = data.subarray(IV_LENGTH + TAG_LENGTH);

  const decipher = crypto.createDecipheriv(ALGORITHM, key, iv);
  decipher.setAuthTag(tag);

  return Buffer.concat([decipher.update(encrypted), decipher.final()]).toString('utf8');
}

// Usage
const key        = crypto.randomBytes(KEY_LENGTH); // store this securely
const ciphertext = encrypt('sensitive data here', key);
const plaintext  = decrypt(ciphertext, key);

Python

import os, base64
from cryptography.hazmat.primitives.ciphers.aead import AESGCM

IV_LENGTH = 12  # 96 bits

def encrypt(plaintext: str, key: bytes) -> str:
    iv = os.urandom(IV_LENGTH)
    aesgcm = AESGCM(key)
    # encrypt() appends the 16-byte auth tag automatically
    ciphertext = aesgcm.encrypt(iv, plaintext.encode(), None)
    return base64.b64encode(iv + ciphertext).decode()

def decrypt(ciphertext_b64: str, key: bytes) -> str:
    data       = base64.b64decode(ciphertext_b64)
    iv         = data[:IV_LENGTH]
    ciphertext = data[IV_LENGTH:]
    aesgcm = AESGCM(key)
    return aesgcm.decrypt(iv, ciphertext, None).decode()

# Usage
key        = AESGCM.generate_key(bit_length=256)  # store this securely
ciphertext = encrypt('sensitive data here', key)
plaintext  = decrypt(ciphertext, key)

Installez la dépendance : pip install cryptography

Vous pouvez tester le chiffrement et la déchiffrement AES interactivement — sans configuration — avec l' IO Tools Outil de chiffrement/déchiffrement AES.

Gestion des clés : la partie difficile

Votre chiffrement n'est aussi fort que votre gestion des clés. Les erreurs les plus courantes :

• La clé est stockée dans la même base de données que les données chiffrées — si un attaquant obtient votre dump de base de données, il obtient les deux.
• La clé est commitée dans le contrôle de version — même si elle est ignorée par git .env, la rotation devient difficile et l'historique persiste.
• La clé apparaît dans les logs — les logs d'application sont envoyés à des agrégateurs. Les clés ne doivent jamais apparaître là.

Où stocker réellement les clés de chiffrement :

• AWS KMS / Google Cloud KMS / Azure Key Vault — stockage de clés géré avec des traces d'audit et une rotation automatique
• HashiCorp Vault — hébergé localement, bon pour les environnements multi-cloud
• Variables d'environnement — acceptable pour des charges à faible sensibilité avec une surface d'exposition limitée

Pour le chiffrement des champs de base de données, le modèle d'encryption enveloppe est la pratique standard : générer une clé de chiffrement des données (DEK) par enregistrement ou par colonne, puis chiffrer la DEK avec une clé maîtresse stockée dans un KMS. Votre base de données contient uniquement des DEK chiffrés et des chiffrements — la clé maîtresse ne touche jamais la base de données.

Quand utiliser l'AES — et quand ne pas l'utiliser

L'AES est le bon outil pour :

• Chiffrer des champs dans une base de données — les numéros de sécurité sociale, les numéros de carte, les dossiers médicaux
• Chiffrer des fichiers au repos avant leur stockage dans le cloud
• Partager des secrets entre services qui partagent une clé pré-établie

L'AES n'est pas le bon outil quand :

• Vous transmettez des données sur un réseau — utilisez TLS. Ne concevez pas votre propre couche de transport.
• Vous avez besoin d'un chiffrement asymétrique — si les émetteurs et destinataires ne peuvent pas partager une clé à l'avance, utilisez RSA ou ECDH pour l'échange de clés.
• Vous stockez des mots de passe — utilisez bcrypt, scrypt ou Argon2. Les mots de passe chiffrés peuvent être déchiffrés ; les mots de passe correctement hachés ne peuvent pas être déchiffrés.
• Une solution gérée convient — AWS Secrets Manager, Vault et similaires gèrent la rotation, le contrôle d'accès et les traces d'audit sans configuration. Privilégiez cela plutôt que l'AES manuel si cela couvre votre cas d'usage.

L'erreur la plus courante que font les développeurs est de considérer l'AES comme une solution complète en matière de sécurité. C'est un primitif — un bloc de construction. Associez-le à un mode authentifié (GCM), à des IV uniques par opération, et à une gestion des clés correcte, et il devient extrêmement efficace. Omettez l'un de ces éléments et vous avez construit quelque chose qui semble sécurisé mais qui ne l'est pas.

Vous aimerez peut-être aussi