Chiffrement de Bout en Bout : 12 Étapes, 90 Min [2026]

Le chiffrement de bout en bout protège plus de trois milliards de conversations chaque jour sur WhatsApp, Signal ou iMessage, mais la plupart des développeurs n’ont jamais ouvert le capot pour voir comment il fonctionne réellement. Ce tutoriel corrige ça : vous allez construire, ligne par ligne, un système de chiffrement de bout en bout fonctionnel en Node.js, avec un échange de clés X25519, un chiffrement AES-256-GCM et une signature Ed25519. À la fin, vous aurez un outil en ligne de commande capable de chiffrer et déchiffrer des fichiers entre deux interlocuteurs, avec la même architecture cryptographique que les protocoles de messagerie sécurisée du marché.

Comptez environ 90 minutes pour suivre l’intégralité des 12 étapes, tester le code et comprendre pourquoi chaque brique cryptographique est nécessaire. Aucune bibliothèque tierce n’est requise : le module crypto natif de Node.js suffit depuis la version 20.

Qu’est-ce que le chiffrement de bout en bout et pourquoi le construire soi-même

Le chiffrement de bout en bout (E2EE, pour “end-to-end encryption”) garantit qu’un message reste illisible pour tout intermédiaire entre l’émetteur et le destinataire, y compris le fournisseur du service de messagerie. Contrairement au chiffrement en transit classique (HTTPS entre le client et le serveur), l’E2EE chiffre les données avec une clé que seuls les deux interlocuteurs possèdent. Le serveur ne voit passer que du texte chiffré, incapable de le déchiffrer même sous contrainte judiciaire.

Construire son propre système E2EE n’a pas vocation à remplacer Signal, dont le protocole a été audité pendant des années par des cryptographes du monde entier. L’objectif ici est pédagogique et pratique : comprendre les briques qui composent tout système de chiffrement de bout en bout moderne (échange de clés asymétrique, dérivation de clé, chiffrement authentifié) pour être capable de les auditer, de les intégrer dans une application interne, ou de déboguer un système existant qui utilise les mêmes primitives. Ces mêmes briques se retrouvent dans Signal, WhatsApp, Matrix (protocole Olm/Megolm) et la plupart des VPN modernes comme WireGuard.

Le choix de X25519 pour l’échange de clés n’est pas arbitraire. Cette courbe elliptique, standardisée dans la RFC 7748, offre un niveau de sécurité équivalent à RSA-3072 avec des clés de seulement 32 octets, des calculs nettement plus rapides, et une résistance native à plusieurs classes d’attaques par canal auxiliaire qui ont historiquement touché les implémentations RSA et ECC classiques (courbes NIST P-256/P-384). C’est également la courbe utilisée par Signal, WireGuard et la majorité des nouveaux protocoles.

Prérequis : outils, versions et connaissances nécessaires

Avant de commencer, vérifiez que votre environnement dispose des éléments suivants. Aucune inscription à un service tiers n’est nécessaire, tout le tutoriel fonctionne en local.

Node.js 20 LTS ou supérieur (le support natif de crypto.hkdfSync et de la génération de clés X25519 nécessite au minimum Node.js 15, mais utilisez la version 20 ou 22 LTS pour bénéficier des correctifs de sécurité les plus récents sur OpenSSL)
npm 10.x ou supérieur, installé avec Node.js
Un terminal (Bash, Zsh ou PowerShell) et un éditeur de code (VS Code recommandé)
Connaissances de base en JavaScript : fonctions, buffers, gestion asynchrone
Notions de cryptographie : ce tutoriel explique chaque concept, mais une familiarité avec les termes clé publique / clé privée facilite la lecture
15 Mo d’espace disque libre et aucune dépendance réseau une fois Node.js installé

Vérifiez votre version de Node.js avant de continuer :

node --version
# doit afficher v20.x.x ou supérieur

npm --version
# doit afficher 10.x.x ou supérieur

Si votre version est antérieure à Node.js 18, mettez à jour via nodejs.org ou un gestionnaire de versions comme nvm. Les fonctions crypto.diffieHellman() avec support X25519 unifié ne sont stables qu’à partir de Node.js 15 ; en dessous, certaines API diffèrent.

Étape 1 : comprendre l’échange de clés X25519 avant d’écrire du code

Avant d’écrire la moindre ligne, il faut comprendre le problème que résout l’échange de clés Diffie-Hellman sur courbe elliptique. Alice et Bob veulent communiquer de façon chiffrée, mais ils n’ont jamais partagé de secret commun au préalable. Ils ne peuvent pas non plus s’échanger une clé de chiffrement en clair sur le réseau, un attaquant pourrait l’intercepter.

La solution, décrite par Whitfield Diffie et Martin Hellman en 1976 et adaptée aux courbes elliptiques dans les années 2000, repose sur une propriété mathématique remarquable : Alice et Bob peuvent chacun calculer indépendamment la même valeur secrète en combinant leur propre clé privée avec la clé publique de l’autre, sans jamais transmettre de secret sur le réseau. Un attaquant qui intercepte les deux clés publiques ne peut pas reconstruire le secret partagé sans résoudre le problème du logarithme discret sur courbe elliptique, jugé impraticable avec les moyens de calcul actuels pour une courbe comme X25519.

Concrètement, le flux ressemble à ceci : chaque participant génère une paire de clés (publique et privée), publie sa clé publique, récupère la clé publique de l’autre, puis calcule localement un secret partagé identique des deux côtés. Ce secret partagé sert ensuite de matière première pour dériver une clé de chiffrement symétrique, celle qui chiffrera réellement les messages avec AES-256-GCM.

Étape 2 : initialiser le projet Node.js

Créez un nouveau dossier de projet et initialisez-le. Aucune dépendance externe n’est nécessaire : tout ce dont nous avons besoin (X25519, HKDF, AES-256-GCM, Ed25519) est intégré au module crypto natif de Node.js depuis les versions 15 à 18 selon la primitive.

mkdir e2ee-tutoriel
cd e2ee-tutoriel
npm init -y
touch e2ee.js

Ouvrez package.json et ajoutez une contrainte de version minimale pour éviter qu’un collègue exécute le projet sur une version de Node.js trop ancienne, dépourvue du support natif de HKDF :

{
  "name": "e2ee-tutoriel",
  "version": "1.0.0",
  "type": "commonjs",
  "engines": {
    "node": ">=18.0.0"
  },
  "main": "e2ee.js"
}

Étape 3 : générer les paires de clés d’Alice et de Bob

Ouvrez e2ee.js et commencez par la fonction de génération de clés. Le module crypto de Node.js expose generateKeyPairSync('x25519'), qui produit directement des objets clé au format attendu par les fonctions Diffie-Hellman.

const crypto = require('crypto');
const fs = require('fs');

function keygen(name) {
  const { publicKey, privateKey } = crypto.generateKeyPairSync('x25519');

  fs.writeFileSync(
    `${name}_public.pem`,
    publicKey.export({ type: 'spki', format: 'pem' })
  );
  fs.writeFileSync(
    `${name}_private.pem`,
    privateKey.export({ type: 'pkcs8', format: 'pem' })
  );

  console.log(`Clés générées : ${name}_public.pem / ${name}_private.pem`);
}

keygen('alice');
keygen('bob');

Exécutez ce script. Vous devriez obtenir quatre fichiers PEM :

$ node e2ee.js
Clés générées : alice_public.pem / alice_private.pem
Clés générées : bob_public.pem / bob_private.pem

$ ls *.pem
alice_private.pem  alice_public.pem  bob_private.pem  bob_public.pem

La clé privée ne doit jamais quitter la machine de son propriétaire. Dans une application réelle, elle serait stockée dans un trousseau système (Keychain sur macOS, Credential Manager sur Windows, ou un module matériel comme une YubiKey), jamais dans un fichier texte en clair sur disque comme nous le faisons ici par simplicité pédagogique.

Étape 4 : dériver le secret partagé avec crypto.diffieHellman

C’est ici que la magie opère. La fonction crypto.diffieHellman() prend la clé privée d’un participant et la clé publique de l’autre, et retourne le secret partagé. Ajoutez ce code à e2ee.js :

function loadPublicKey(file) {
  return crypto.createPublicKey(fs.readFileSync(file));
}
function loadPrivateKey(file) {
  return crypto.createPrivateKey(fs.readFileSync(file));
}

function computeSharedSecret(privateKeyFile, peerPublicKeyFile) {
  const privateKey = loadPrivateKey(privateKeyFile);
  const peerPublicKey = loadPublicKey(peerPublicKeyFile);
  return crypto.diffieHellman({ privateKey, publicKey: peerPublicKey });
}

const aliceShared = computeSharedSecret('alice_private.pem', 'bob_public.pem');
const bobShared = computeSharedSecret('bob_private.pem', 'alice_public.pem');

console.log('Secrets identiques :', aliceShared.equals(bobShared));

Le point essentiel à vérifier ici : Alice calcule son secret à partir de sa clé privée et de la clé publique de Bob, Bob fait l’inverse, et pourtant les deux obtiennent exactement la même valeur de 32 octets. C’est cette propriété mathématique qui rend l’échange de clés possible sans jamais transmettre le secret lui-même sur le réseau.

Sortie attendue :

$ node e2ee.js
Secrets identiques : true

Étape 5 : renforcer la clé avec HKDF-SHA256

Utiliser directement le secret Diffie-Hellman brut comme clé de chiffrement AES est une erreur fréquente. Ce secret n’a pas une distribution statistiquement uniforme sur 256 bits (il porte la structure algébrique de la courbe elliptique), ce qui le rend impropre à un usage direct comme clé symétrique. La bonne pratique consiste à le faire passer par une fonction de dérivation de clé, HKDF (HMAC-based Key Derivation Function), normalisée dans la RFC 5869.

HKDF prend trois entrées : le secret brut, un sel aléatoire (salt) qui garantit que deux sessions ne produiront jamais la même clé même avec le même secret Diffie-Hellman, et une information contextuelle (info) qui lie la clé dérivée à un usage précis. Ajoutez cette fonction :

const APP_INFO = Buffer.from('e2ee-tutoriel-v1');

function deriveKey(sharedSecret, salt) {
  const keyMaterial = crypto.hkdfSync('sha256', sharedSecret, salt, APP_INFO, 32);
  return Buffer.from(keyMaterial);
}

const salt = crypto.randomBytes(16);
const aliceKey = deriveKey(aliceShared, salt);
const bobKey = deriveKey(bobShared, salt);

console.log('Clés AES identiques :', aliceKey.equals(bobKey));
console.log('Longueur de la clé :', aliceKey.length, 'octets');

Le sel doit être généré aléatoirement à chaque session et transmis en clair avec le message chiffré (ce n’est pas un secret, sa fonction est de garantir l’unicité). Le champ info, en revanche, est une chaîne fixe propre à votre application : elle empêche qu’une clé dérivée pour un usage (chiffrement de message) soit réutilisable pour un autre usage (par exemple signature) même si le secret Diffie-Hellman sous-jacent est identique.

Étape 6 : chiffrer les messages avec AES-256-GCM

Avec une clé symétrique de 256 bits en main, on peut enfin chiffrer. AES-256-GCM (Galois/Counter Mode) est un mode de chiffrement authentifié : il chiffre les données et produit simultanément un tag d’authentification qui permet de détecter toute altération du texte chiffré. C’est le mode recommandé par le NIST dans la publication spéciale 800-38D et celui utilisé par TLS 1.3, Signal et WireGuard.

function encrypt(key, plaintext) {
  const iv = crypto.randomBytes(12); // 96 bits, taille recommandée pour GCM
  const cipher = crypto.createCipheriv('aes-256-gcm', key, iv);

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

  return { iv, ciphertext, authTag };
}

const message = 'Rendez-vous à 18h, apporte le dossier.';
const enveloppe = encrypt(aliceKey, message);

console.log('IV (hex) :', enveloppe.iv.toString('hex'));
console.log('Texte chiffré (hex) :', enveloppe.ciphertext.toString('hex'));
console.log("Tag d'authentification (hex) :", enveloppe.authTag.toString('hex'));

Chaque IV (vecteur d’initialisation) de 12 octets doit être unique par message chiffré avec la même clé. Réutiliser un IV avec AES-GCM est l’une des pires erreurs possibles en cryptographie appliquée : cela permet à un attaquant de récupérer la clé de flux XOR entre deux messages et, dans certains cas, de forger des tags d’authentification valides. Générer un IV aléatoire de 96 bits à chaque appel, comme fait ici avec crypto.randomBytes(12), rend une collision statistiquement négligeable tant que le nombre de messages par clé reste raisonnable (en dessous de plusieurs centaines de millions).

Étape 7 : déchiffrer et vérifier l’intégrité avec le tag d’authentification

Le déchiffrement est symétrique, avec une étape supplémentaire cruciale : la vérification du tag d’authentification avant de faire confiance au texte déchiffré.

function decrypt(key, { iv, ciphertext, authTag }) {
  const decipher = crypto.createDecipheriv('aes-256-gcm', key, iv);
  decipher.setAuthTag(authTag);

  const plaintext = Buffer.concat([
    decipher.update(ciphertext),
    decipher.final(), // lève une exception si le tag ne correspond pas
  ]);

  return plaintext.toString('utf8');
}

const messageDechiffre = decrypt(bobKey, enveloppe);
console.log('Message déchiffré :', messageDechiffre);
console.log("Correspond à l'original :", messageDechiffre === message);

Sortie attendue :

Message déchiffré : Rendez-vous à 18h, apporte le dossier.
Correspond à l'original : true

Testez maintenant ce qui se passe si un octet du texte chiffré est modifié en transit, par exemple par un attaquant actif ou une corruption réseau :

const tampered = Buffer.from(enveloppe.ciphertext);
tampered[0] ^= 0xff; // on inverse le premier octet

try {
  decrypt(bobKey, { ...enveloppe, ciphertext: tampered });
} catch (err) {
  console.log('Altération détectée :', err.message);
}
// Altération détectée : Unsupported state or unable to authenticate data

C’est exactement le comportement recherché : decipher.final() lève une exception plutôt que de retourner un texte corrompu silencieusement. Ne capturez jamais cette exception pour “essayer quand même” d’utiliser le texte déchiffré, c’est le signal que le message a été altéré ou que la mauvaise clé a été utilisée.

Étape 8 : construire l’enveloppe binaire du message chiffré

Pour transmettre ou stocker un message chiffré, il faut combiner le sel, l’IV, le tag d’authentification et le texte chiffré en une seule enveloppe binaire que le destinataire pourra découper dans le bon ordre. Voici le format que nous utiliserons, avec des tailles fixes pour simplifier le découpage :

Champ	Taille	Rôle
salt	16 octets	Dérivation HKDF unique par session
iv	12 octets	Vecteur d’initialisation AES-GCM
authTag	16 octets	Tag d’authentification GCM
ciphertext	variable	Texte chiffré (taille du message d’origine)

function packEnvelope({ salt, iv, ciphertext, authTag }) {
  return Buffer.concat([salt, iv, authTag, ciphertext]);
}

function unpackEnvelope(payload) {
  const salt = payload.subarray(0, 16);
  const iv = payload.subarray(16, 28);
  const authTag = payload.subarray(28, 44);
  const ciphertext = payload.subarray(44);
  return { salt, iv, authTag, ciphertext };
}

Les tailles fixes de 16, 12 et 16 octets évitent d’avoir à sérialiser des longueurs séparément. Si votre protocole doit un jour supporter plusieurs algorithmes (par exemple ChaCha20-Poly1305 en plus d’AES-256-GCM), ajoutez un octet d’en-tête indiquant l’algorithme utilisé avant le sel.

Étape 9 : écrire la CLI complète (keygen, encrypt, decrypt)

Assemblons maintenant toutes les briques précédentes dans un outil en ligne de commande utilisable pour chiffrer et déchiffrer des fichiers réels. Remplacez le contenu de e2ee.js par la version complète suivante :

#!/usr/bin/env node
const crypto = require('crypto');
const fs = require('fs');

const APP_INFO = Buffer.from('e2ee-tutoriel-v1');

function keygen(name) {
  const { publicKey, privateKey } = crypto.generateKeyPairSync('x25519');
  fs.writeFileSync(`${name}_public.pem`, publicKey.export({ type: 'spki', format: 'pem' }));
  fs.writeFileSync(`${name}_private.pem`, privateKey.export({ type: 'pkcs8', format: 'pem' }));
  console.log(`Clés générées : ${name}_public.pem / ${name}_private.pem`);
}

function loadPublicKey(file) { return crypto.createPublicKey(fs.readFileSync(file)); }
function loadPrivateKey(file) { return crypto.createPrivateKey(fs.readFileSync(file)); }

function deriveSessionKey(privateKeyFile, peerPublicKeyFile, salt) {
  const privateKey = loadPrivateKey(privateKeyFile);
  const peerPublicKey = loadPublicKey(peerPublicKeyFile);
  const sharedSecret = crypto.diffieHellman({ privateKey, publicKey: peerPublicKey });
  return Buffer.from(crypto.hkdfSync('sha256', sharedSecret, salt, APP_INFO, 32));
}

function encryptFile(inputFile, privateKeyFile, peerPublicKeyFile, outputFile) {
  const salt = crypto.randomBytes(16);
  const key = deriveSessionKey(privateKeyFile, peerPublicKeyFile, salt);
  const iv = crypto.randomBytes(12);
  const plaintext = fs.readFileSync(inputFile);

  const cipher = crypto.createCipheriv('aes-256-gcm', key, iv);
  const ciphertext = Buffer.concat([cipher.update(plaintext), cipher.final()]);
  const authTag = cipher.getAuthTag();

  fs.writeFileSync(outputFile, Buffer.concat([salt, iv, authTag, ciphertext]));
  console.log(`Fichier chiffré : ${outputFile}`);
}

function decryptFile(inputFile, privateKeyFile, peerPublicKeyFile, outputFile) {
  const payload = fs.readFileSync(inputFile);
  const salt = payload.subarray(0, 16);
  const iv = payload.subarray(16, 28);
  const authTag = payload.subarray(28, 44);
  const ciphertext = payload.subarray(44);

  const key = deriveSessionKey(privateKeyFile, peerPublicKeyFile, salt);
  const decipher = crypto.createDecipheriv('aes-256-gcm', key, iv);
  decipher.setAuthTag(authTag);
  const plaintext = Buffer.concat([decipher.update(ciphertext), decipher.final()]);

  fs.writeFileSync(outputFile, plaintext);
  console.log(`Fichier déchiffré : ${outputFile}`);
}

const [, , cmd, ...args] = process.argv;
if (cmd === 'keygen') keygen(args[0]);
else if (cmd === 'encrypt') encryptFile(args[0], args[1], args[2], args[3]);
else if (cmd === 'decrypt') decryptFile(args[0], args[1], args[2], args[3]);
else console.log('Usage: node e2ee.js  ...');

Testez le flux complet, d’Alice vers Bob :

# Scénario nominal : Alice envoie, Bob reçoit
$ node e2ee.js keygen alice
Clés générées : alice_public.pem / alice_private.pem

$ node e2ee.js keygen bob
Clés générées : bob_public.pem / bob_private.pem

$ echo "Message secret pour Bob, 29 août 2026." > message.txt

$ node e2ee.js encrypt message.txt alice_private.pem bob_public.pem message.enc
Fichier chiffré : message.enc

$ node e2ee.js decrypt message.enc bob_private.pem alice_public.pem message.dec
Fichier déchiffré : message.dec

$ diff message.txt message.dec && echo "Identique : succès"
Identique : succès

Remarquez l’inversion des clés entre le chiffrement et le déchiffrement : Alice chiffre avec sa clé privée et la clé publique de Bob, Bob déchiffre avec sa clé privée et la clé publique d’Alice. C’est cette asymétrie qui permet à chacun de calculer le même secret sans jamais l’avoir transmis.

Étape 10 : ajouter la rotation de clés pour la confidentialité persistante

Le système actuel a une faiblesse structurelle : si la clé privée d’Alice ou de Bob est compromise un jour, un attaquant qui a enregistré le trafic chiffré passé peut recalculer rétroactivement tous les secrets partagés et déchiffrer l’historique complet des conversations. C’est l’absence de confidentialité persistante (forward secrecy).

Signal résout ce problème avec le protocole Double Ratchet, qui génère une nouvelle paire de clés éphémères à chaque message. Une version simplifiée, suffisante pour comprendre le principe, consiste à faire évoluer la clé de session à chaque message via une chaîne de hachage plutôt que de la garder statique :

function ratchetKey(currentKey) {
  // Fait avancer la chaîne de clés de façon irréversible :
  // connaître la clé actuelle ne permet pas de retrouver la précédente
  return crypto.createHash('sha256')
    .update(currentKey)
    .update('ratchet-step')
    .digest();
}

let sessionKey = deriveSessionKey('alice_private.pem', 'bob_public.pem', salt);

function sendMessage(plaintext) {
  const iv = crypto.randomBytes(12);
  const cipher = crypto.createCipheriv('aes-256-gcm', sessionKey, iv);
  const ciphertext = Buffer.concat([cipher.update(plaintext, 'utf8'), cipher.final()]);
  const authTag = cipher.getAuthTag();

  sessionKey = ratchetKey(sessionKey); // la clé change après chaque message
  return { iv, ciphertext, authTag };
}

Avec ce mécanisme, la compromission de la clé de session au message N ne permet pas de déchiffrer les messages 1 à N-1 (la fonction de hachage est irréversible), mais expose les messages futurs tant qu’une nouvelle négociation Diffie-Hellman n’a pas eu lieu. Un vrai Double Ratchet combine cette chaîne symétrique avec des ré-échanges Diffie-Hellman périodiques pour obtenir à la fois la confidentialité persistante et l’auto-guérison après compromission. C’est un sujet à part entière, documenté dans les spécifications techniques publiées par Signal.

Étape 11 : signer les messages avec Ed25519 pour authentifier l’expéditeur

Le chiffrement garantit la confidentialité, mais pas l’authenticité de l’expéditeur au niveau applicatif. Un attaquant qui a accès temporairement au canal ne peut pas lire les messages, mais rien dans notre schéma actuel ne prouve cryptographiquement que le message vient bien d’Alice plutôt que de quelqu’un d’autre disposant de la clé de session (par exemple un serveur relais compromis, si l’architecture en utilise un). On ajoute donc une signature Ed25519, une paire de clés distincte de celle utilisée pour X25519.

function keygenSigning(name) {
  const { publicKey, privateKey } = crypto.generateKeyPairSync('ed25519');
  fs.writeFileSync(`${name}_sign_public.pem`, publicKey.export({ type: 'spki', format: 'pem' }));
  fs.writeFileSync(`${name}_sign_private.pem`, privateKey.export({ type: 'pkcs8', format: 'pem' }));
}

function signMessage(privateKeySignFile, data) {
  const privateKey = loadPrivateKey(privateKeySignFile);
  return crypto.sign(null, data, privateKey); // Ed25519 n'a pas besoin de hachage explicite
}

function verifySignature(publicKeySignFile, data, signature) {
  const publicKey = loadPublicKey(publicKeySignFile);
  return crypto.verify(null, data, publicKey, signature);
}

// Utilisation : Alice signe le texte chiffré avant de l'envoyer
const signature = signMessage('alice_sign_private.pem', enveloppe.ciphertext);
const estValide = verifySignature('alice_sign_public.pem', enveloppe.ciphertext, signature);
console.log('Signature valide :', estValide);

Ed25519 utilise l’algorithme EdDSA sur la courbe Edwards25519, spécifié dans la RFC 8032 et adopté par TLS 1.3, SSH et la majorité des gestionnaires de mots de passe modernes pour la signature. Contrairement à ECDSA, il ne nécessite pas de générateur de nombres aléatoires de haute qualité à chaque signature, ce qui élimine toute une classe de vulnérabilités historiques liées à la réutilisation accidentelle d’un nonce (c’est exactement ce type de faille qui avait permis d’extraire des clés privées sur la PS3 en 2010).

Étape 12 : tester le projet de bout en bout

Il est temps de valider l’ensemble du système avec un scénario complet incluant un cas d’échec volontaire, pour vérifier que le système rejette bien les données invalides plutôt que d’échouer silencieusement.

# Scénario nominal : Alice envoie, Bob reçoit
node e2ee.js keygen alice
node e2ee.js keygen bob
echo "Rapport confidentiel Q3" > rapport.txt
node e2ee.js encrypt rapport.txt alice_private.pem bob_public.pem rapport.enc
node e2ee.js decrypt rapport.enc bob_private.pem alice_public.pem rapport.dec
diff rapport.txt rapport.dec && echo "OK : contenu identique"

# Scénario d'échec : une pirate (Eve) tente de déchiffrer avec sa propre clé
node e2ee.js keygen eve
node e2ee.js decrypt rapport.enc eve_private.pem alice_public.pem rapport_eve.dec
# Attendu : erreur "Unsupported state or unable to authenticate data"

Si le deuxième scénario ne produit pas d’erreur, ou pire, écrit un fichier de sortie avec un contenu incohérent, il y a un défaut d’implémentation à corriger avant tout déploiement. Le test d’échec est aussi important que le test de succès : une bibliothèque cryptographique qui fonctionne dans le cas nominal mais échoue silencieusement dans les cas d’attaque est dangereuse.

Les erreurs les plus fréquentes à éviter

Ces cinq erreurs reviennent le plus souvent dans les implémentations de chiffrement de bout en bout maison, y compris chez des développeurs expérimentés.

Réutiliser un IV avec la même clé AES-GCM. C’est l’erreur la plus grave possible en pratique : elle peut exposer la clé de flux et permettre la forge de messages. Générez toujours un IV aléatoire de 12 octets par opération de chiffrement, jamais un compteur partagé entre plusieurs clés.
Utiliser le secret Diffie-Hellman brut comme clé AES. Le secret X25519 n’a pas les propriétés statistiques requises pour un usage direct. Passez-le systématiquement par HKDF ou une fonction de dérivation équivalente.
Ignorer ou avaler l’exception de decipher.final(). Cette exception signale un échec d’authentification GCM. L’attraper pour continuer quand même avec un texte partiel revient à désactiver la protection contre l’altération.
Stocker les clés privées en clair sans contrôle d’accès. Dans ce tutoriel, les fichiers PEM sont en clair pour la pédagogie. En production, chiffrez-les au repos avec une clé dérivée d’un mot de passe (via Argon2id) ou utilisez un module matériel de sécurité.
Confondre chiffrement et authentification. AES-256-GCM garantit la confidentialité et l’intégrité du message, mais pas l’identité de l’expéditeur au niveau applicatif si un intermédiaire a accès à la clé de session. Ajoutez toujours une signature (Ed25519 ici) si l’authentification de l’expéditeur est un objectif de sécurité.

Dépannage : problèmes courants et leurs solutions

Voici les erreurs les plus fréquemment rencontrées en suivant ce tutoriel, avec leur cause et leur correction.

Symptôme	Cause probable	Solution
`Unsupported state or unable to authenticate data` au déchiffrement	Tag d’authentification incorrect, mauvaise clé, ou données altérées	Vérifiez que le même sel et la même paire de clés (inversée) sont utilisés des deux côtés
`crypto.hkdfSync is not a function`	Version de Node.js antérieure à 15	Mettez à jour vers Node.js 18 LTS ou 20 LTS minimum
`ERR_OSSL_EVP_UNSUPPORTED` lors de `generateKeyPairSync('x25519')`	Build de Node.js compilé sans support OpenSSL complet (rare, certaines distributions Linux allégées)	Utilisez le binaire officiel distribué sur nodejs.org plutôt qu’un paquet système tiers
Les secrets Diffie-Hellman ne correspondent pas entre Alice et Bob	Les clés publiques ont été inversées ou proviennent de la mauvaise paire	Vérifiez que chaque partie utilise SA clé privée et la clé publique DE L’AUTRE, jamais la sienne
`ERR_CRYPTO_INVALID_KEYPAIR` à l’import d’un fichier PEM	Fichier PEM tronqué ou corrompu lors d’une copie	Régénérez la paire de clés avec `keygen`, ne copiez jamais un PEM avec un éditeur qui modifie les fins de ligne
Le fichier déchiffré fait 0 octet	Le découpage de l’enveloppe (salt/iv/authTag) est incorrect	Vérifiez les offsets 16/28/44 dans `unpackEnvelope`, ils doivent correspondre exactement aux tailles utilisées au chiffrement
Erreur `ERR_INVALID_ARG_TYPE` sur `hkdfSync`	Le paramètre `info` n’est pas un Buffer	Enveloppez toujours `info` avec `Buffer.from()` avant de le passer à `hkdfSync`
Signature Ed25519 toujours invalide	Les données signées ne sont pas strictement identiques à celles vérifiées (encodage différent)	Signez et vérifiez le même buffer binaire, jamais une conversion texte intermédiaire

Bonnes pratiques avancées pour un déploiement en production

Ce tutoriel construit un système fonctionnel à but pédagogique. Pour un usage en production, plusieurs points additionnels doivent être traités.

Vérification d’identité hors bande. L’échange de clés Diffie-Hellman protège contre l’interception passive, mais pas contre un attaquant actif capable de substituer sa propre clé publique à celle de la victime (attaque de l’intermédiaire). Signal résout ce problème avec les “numéros de sécurité” que les utilisateurs peuvent comparer manuellement ou par QR code. Sans ce mécanisme de vérification hors bande, votre système reste vulnérable à une interception active si le canal de distribution des clés publiques n’est pas lui-même de confiance.

Rotation régulière des clés de signature. Contrairement aux clés de session éphémères, les clés d’identité Ed25519 à long terme doivent tout de même être renouvelées périodiquement (par exemple annuellement) et révocables en cas de compromission suspectée.

Protection contre les attaques par rejeu. Ajoutez un numéro de séquence ou un horodatage signé dans chaque message pour empêcher qu’un attaquant capture un message chiffré valide et le renvoie plus tard pour tromper le destinataire.

Effacement mémoire des clés sensibles. Node.js ne garantit pas l’effacement immédiat des buffers contenant des clés une fois qu’ils sortent de portée (le ramasse-miettes JavaScript ne réécrit pas la mémoire à zéro). Pour un usage sensible, utilisez crypto.KeyObject plutôt que des buffers bruts quand c’est possible, et envisagez des modules natifs avec effacement explicite pour les clés de très longue durée de vie.

Alignement avec les recommandations françaises. L’ANSSI recommande des tailles de clé et des primitives cryptographiques précises pour les systèmes d’information sensibles ; X25519, AES-256-GCM et Ed25519 figurent parmi les mécanismes considérés robustes à ce jour, mais toute application traitant des données réglementées doit valider son architecture face au référentiel en vigueur avant mise en production.

Résistance post-quantique. X25519 et Ed25519 reposent sur le problème du logarithme discret sur courbe elliptique, qu’un ordinateur quantique suffisamment puissant pourrait résoudre via l’algorithme de Shor. Pour des données dont la confidentialité doit être garantie au-delà de la prochaine décennie, envisagez un mécanisme hybride combinant X25519 avec un algorithme post-quantique comme ML-KEM, déjà standardisé par le NIST.

AES-256-GCM + X25519 face aux autres approches de chiffrement de bout en bout

Le schéma construit dans ce tutoriel n’est qu’une des combinaisons possibles de primitives cryptographiques. Voici comment il se positionne face aux alternatives courantes.

Approche	Échange de clés	Chiffrement	Forward secrecy	Cas d’usage typique
Ce tutoriel (simplifié)	X25519	AES-256-GCM	Partielle (ratchet symétrique seul)	Apprentissage, prototypage interne
Signal Protocol (Double Ratchet)	X25519 (X3DH puis ratchets répétés)	AES-256-CBC + HMAC	Complète (auto-guérison incluse)	Messagerie grand public (Signal, WhatsApp)
WireGuard	X25519 (Noise Protocol)	ChaCha20-Poly1305	Complète, avec ré-échange périodique	VPN réseau
TLS 1.3	X25519 ou P-256 (éphémère)	AES-256-GCM ou ChaCha20-Poly1305	Oui, par session uniquement	Chiffrement en transit navigateur-serveur
PGP/GPG classique	RSA ou ECC statique	AES-256-CBC	Non, sauf clés éphémères ajoutées manuellement	Email chiffré, signature de fichiers

La différence principale entre notre implémentation et Signal ne réside pas dans le choix des primitives, très proches, mais dans la robustesse du protocole de ratchet complet et dans des années d’audits publics par la communauté cryptographique. Pour tout système destiné à protéger des communications sensibles à grande échelle, privilégiez une bibliothèque déjà auditée (libsignal, libsodium) plutôt qu’une implémentation maison, même correcte sur le plan des primitives. Ce tutoriel a une vocation pédagogique : comprendre le fonctionnement interne pour mieux évaluer, auditer ou déboguer ces systèmes.

Pour approfondir la comparaison entre les choix de stockage de clés en environnement de production, consultez le guide OWASP sur le stockage cryptographique, qui détaille les recommandations pour la gestion des clés côté serveur.

Foire aux questions

Le chiffrement de bout en bout maison de ce tutoriel est-il utilisable en production ?

Les primitives utilisées (X25519, AES-256-GCM, HKDF-SHA256, Ed25519) sont solides et largement déployées. Mais le protocole complet présenté ici manque de vérification d’identité hors bande, de protection anti-rejeu complète et d’un vrai Double Ratchet. Pour une messagerie destinée à de vrais utilisateurs, préférez une bibliothèque auditée comme libsignal plutôt qu’une réimplémentation maison, même techniquement correcte.

Pourquoi X25519 plutôt que RSA pour l’échange de clés ?

X25519 offre un niveau de sécurité comparable à RSA-3072 avec des clés dix fois plus courtes (32 octets contre environ 384 octets), des calculs nettement plus rapides, et une conception qui élimine par construction plusieurs classes de vulnérabilités d’implémentation qui ont historiquement touché RSA, comme les attaques par canal auxiliaire liées au temps de calcul.

Que se passe-t-il si deux messages sont chiffrés avec le même IV et la même clé ?

C’est l’une des failles les plus graves possibles avec AES-GCM. Un attaquant peut récupérer le XOR des deux textes en clair en combinant les deux textes chiffrés, et dans certains scénarios, forger des tags d’authentification valides pour de nouveaux messages. C’est pourquoi ce tutoriel génère systématiquement un IV aléatoire de 12 octets à chaque appel de chiffrement.

Quelle est la différence entre chiffrement en transit et chiffrement de bout en bout ?

Le chiffrement en transit (HTTPS classique) protège les données entre le client et le serveur, mais le serveur lui-même peut lire le contenu en clair. Le chiffrement de bout en bout protège les données entre les deux utilisateurs finaux : même le serveur qui relaie les messages ne peut pas les déchiffrer, puisqu’il ne possède ni la clé privée d’Alice ni celle de Bob.

Faut-il utiliser une bibliothèque comme libsodium plutôt que le module crypto natif de Node.js ?

Le module crypto natif de Node.js s’appuie sur OpenSSL, une bibliothèque mature et largement auditée, ce qui le rend parfaitement adapté à un usage en production pour les primitives utilisées ici. libsodium reste une alternative valable, en particulier pour son API volontairement restreinte qui réduit les risques de mauvaise utilisation, mais elle ajoute une dépendance native supplémentaire au projet.

Le chiffrement de bout en bout résiste-t-il aux ordinateurs quantiques ?

Pas dans sa forme actuelle. X25519 et Ed25519 reposent sur le logarithme discret sur courbe elliptique, un problème que l’algorithme de Shor pourrait résoudre efficacement sur un ordinateur quantique suffisamment puissant. AES-256, en revanche, résiste raisonnablement bien grâce à sa taille de clé, l’algorithme de Grover ne réduisant sa sécurité effective qu’à environ 128 bits. Pour une protection à très long terme, un échange de clés hybride combinant X25519 et un algorithme post-quantique comme ML-KEM est recommandé.

Pourquoi ajouter une signature Ed25519 si le message est déjà chiffré et authentifié par GCM ?

Le tag d’authentification GCM garantit que le message n’a pas été altéré et qu’il provient de quelqu’un possédant la clé de session, mais pas nécessairement d’Alice spécifiquement si la clé de session a pu être partagée avec un tiers (via un serveur relais compromis, par exemple). La signature Ed25519, calculée avec une clé d’identité distincte que seule Alice possède, apporte une preuve cryptographique supplémentaire et indépendante de l’identité de l’expéditeur.

Combien de temps faut-il pour chiffrer un fichier avec cette implémentation ?

Sur un ordinateur portable récent, le calcul du secret Diffie-Hellman X25519 prend moins d’une milliseconde, la dérivation HKDF est quasi instantanée, et AES-256-GCM chiffre plusieurs centaines de mégaoctets par seconde grâce à l’accélération matérielle AES-NI présente sur la quasi-totalité des processeurs modernes. Pour des messages texte ou des fichiers de quelques mégaoctets, l’ensemble du processus est imperceptible pour l’utilisateur.