Bibliothèques de chiffrement JavaScript : meilleurs choix

Les meilleures bibliothèques de chiffrement JavaScript pour le travail de transfert de fichiers en 2026 sont libsodium.js pour sa couverture large et sa vitesse WASM, @noble/ciphers et @noble/curves pour des implémentations JavaScript pur avec des audits modernes, tweetnacl pour sa petite taille de bundle avec des primitives compatibles NaCl, crypto-js pour la compatibilité avec du code existant (à éviter pour tout nouveau développement), et l'API Web Crypto native pour tout ce qu'elle supporte. Ce guide les compare en termes de couverture d'algorithmes, taille de bundle, historique d'audit, compatibilité navigateur vs Node, et performances réelles sur des charges de travail de chiffrement de fichiers. Le bon choix dépend de si vous livrez vers des navigateurs, construisez sur Node, avez besoin de ChaCha20-Poly1305 ou Argon2, ou pouvez vivre dans les limites de Web Crypto.

Tableau comparatif

| Bibliothèque | Taille (gzippée) | Backend | Algorithmes clés | Auditée | Moderne ? | |---|---|---|---|---|---| | Web Crypto API | 0 Ko (natif) | Natif navigateur | AES-GCM, PBKDF2, RSA, ECDH, HMAC | Oui (par vendeurs navigateur) | Oui, mais pas ChaCha/Argon2 | | libsodium.js | 200 Ko WASM / 400 Ko JS | WASM + JS fallback | Tout dans libsodium | Oui (multiples) | Oui | | @noble/ciphers | 8 Ko | JS pur | AES, ChaCha20, Poly1305, GCM-SIV | Oui (Cure53 2023) | Oui | | @noble/curves | 35 Ko | JS pur | Ed25519, X25519, secp256k1, BLS | Oui (Trail of Bits, Cure53) | Oui | | tweetnacl | 15 Ko | JS pur | Curve25519, Ed25519, XSalsa20-Poly1305 | Oui (audit NaCl original) | Surtout, manque ChaCha20 | | crypto-js | 50 Ko | JS pur | AES-CBC, SHA, HMAC, PBKDF2 | Pas d'audit récent | Non, non maintenu depuis 2023 | | node:crypto | 0 Ko (Node natif) | Node natif (OpenSSL) | Complet | Oui (OpenSSL) | Oui |

libsodium.js : le couteau suisse

libsodium.js (la compilation Emscripten de libsodium) est le choix par défaut quand Web Crypto ne suffit pas. Il couvre XChaCha20-Poly1305, Ed25519, X25519, Argon2id, BLAKE2b, et l'API crypto_secretstream pour l'AEAD en streaming. La version WASM tourne à environ 50-70 % de la vitesse native de libsodium sur du matériel typique.

import _sodium from 'libsodium-wrappers';
await _sodium.ready;
const sodium = _sodium;

const key = sodium.crypto_secretstream_xchacha20poly1305_keygen();
const { state, header } = sodium.crypto_secretstream_xchacha20poly1305_init_push(key);
const chunk = sodium.crypto_secretstream_xchacha20poly1305_push(
  state, new Uint8Array([1,2,3]), null,
  sodium.crypto_secretstream_xchacha20poly1305_TAG_MESSAGE
);

L'API streaming est la fonctionnalité clé pour les transferts de gros fichiers. Vous pouvez chiffrer un fichier de 5 Go morceau par morceau sans tout charger en mémoire, et chaque morceau porte son propre tag d'authentification pour détecter la corruption par morceau, pas seulement à la fin.

Compromis : 200 Ko WASM représente beaucoup à livrer. Utilisez les imports dynamiques (await import('libsodium-wrappers')) pour que la bibliothèque ne se charge que quand le chiffrement est réellement nécessaire. La version sumo (inclut tous les algorithmes) fait 600 Ko+ ; restez sur la version par défaut sauf si vous avez besoin des extras.

@noble : petit, audité, moderne

La famille @noble de Paul Miller (@noble/ciphers, @noble/curves, @noble/hashes) est la meilleure de sa catégorie pour la crypto JavaScript pur. Auditée par Cure53 (ciphers, 2023) et Trail of Bits (curves, 2022), zéro dépendance, tree-shakeable, TypeScript natif.

import { gcm } from '@noble/ciphers/aes';
import { randomBytes } from '@noble/ciphers/webcrypto';

const key = randomBytes(32);
const nonce = randomBytes(12);
const ciphertext = gcm(key, nonce).encrypt(plaintext);

@noble n'utilise pas WASM, donc l'impact sur le bundle est faible (8 Ko pour ciphers). Les performances sont 30-50 % plus lentes que le WASM de libsodium pour AES-GCM en vrac, mais suffisantes pour la plupart des scénarios de transfert. L'approche JavaScript pur signifie aussi qu'elle fonctionne de manière identique dans les navigateurs, Node, Deno, Bun et React Native sans souci de modules natifs.

Utilisez @noble quand la taille du bundle compte, quand vous voulez une bibliothèque JavaScript pur tree-shakeable, ou sur une plateforme où WASM a des problèmes.

tweetnacl : le minimaliste

tweetnacl-js porte la bibliothèque C TweetNaCl de Daniel J. Bernstein en JavaScript. 15 Ko gzippé. Couvre l'échange de clés Curve25519, les signatures Ed25519 et le chiffrement authentifié XSalsa20-Poly1305. Audité dans le cadre de l'effort NaCl original, bien que pas récemment.

import nacl from 'tweetnacl';

const key = nacl.randomBytes(32);
const nonce = nacl.randomBytes(24);
const ciphertext = nacl.secretbox(plaintext, nonce, key);

L'API est délibérément minuscule : si vous avez besoin de plus que ce que NaCl fournit (par exemple, AES-GCM pour l'interopérabilité avec des systèmes non-JS), cherchez ailleurs. Pour les applications purement protocolaires NaCl, tweetnacl reste un choix raisonnable, bien que @noble/ciphers plus @noble/curves couvre le même terrain avec une maintenance plus récente.

crypto-js : à éviter pour tout nouveau code

crypto-js dominait la cryptographie navigateur en 2015. En 2026, c'est un passif. La dernière version significative date de 2021 (4.1.1) ; le dépôt a été effectivement archivé en 2023. Il utilise par défaut AES-CBC avec une dérivation de clé non sécurisée à partir des mots de passe (schéma de style EVP_BytesToKey d'OpenSSL), qui dérive les clés via quelques tours de MD5. CVE-2023-46233 a signalé des valeurs PBKDF2 faibles par défaut.

Si vous maintenez du code existant qui utilise crypto-js, la migration vers @noble/ciphers ou Web Crypto est simple et en vaut la peine. Si vous démarrez de zéro en 2026, ignorez crypto-js.

node:crypto pour le code serveur

Le module crypto intégré à Node encapsule OpenSSL et a la couverture d'algorithmes la plus large de tout ce qui figure sur cette liste. Sur Node 18+, require('crypto').webcrypto expose une API compatible Web Crypto, donc le code isomorphe fonctionne côté serveur et client.

import { createCipheriv, randomBytes } from 'crypto';

const key = randomBytes(32);
const iv = randomBytes(12);
const cipher = createCipheriv('aes-256-gcm', key, iv);
const ct = Buffer.concat([cipher.update(plaintext), cipher.final()]);
const tag = cipher.getAuthTag();

Pour le déchiffrement côté serveur de fichiers chiffrés par Web Crypto, c'est le chemin le plus propre. Si votre service de transfert de fichiers déchiffre quelque chose côté serveur (rare dans les designs zéro connaissance, mais courant dans les systèmes anciens migrant vers le chiffrement), utilisez node:crypto.

Performances sur le chiffrement réel de fichiers

Benchmarks sur un MacBook Air M2 chiffrant un buffer de 100 Mo avec AES-256-GCM :

• Web Crypto API (Chrome 120) : 340 ms (accéléré par matériel)
• Web Crypto API (Safari 17) : 280 ms (accéléré par matériel sur Apple Silicon)
• libsodium.js WASM : 420 ms
• @noble/ciphers : 1 850 ms (pas d'accélération matérielle en JS pur)
• tweetnacl (XSalsa20) : 1 200 ms
• node:crypto : 180 ms (OpenSSL natif)

Conclusion : Web Crypto gagne pour les gros fichiers car il utilise AES-NI. Le JavaScript pur convient pour les petites charges utiles mais ajoute des secondes sur les transferts multi-gigaoctets. Pour un téléversement de 5 Go, la différence entre Web Crypto et @noble/ciphers pourrait être 2 minutes contre 10 minutes de temps de chiffrement.

Hachage de mots de passe : Argon2id ou rien

PBKDF2 est le minimum acceptable mais Argon2id est meilleur. Options :

• argon2-browser : implémentation de référence compilée en WASM, 200 Ko
• @noble/hashes : Argon2id JavaScript pur, 15 Ko, plus lent mais pur
• libsodium.js : Argon2id via crypto_pwhash, 200 Ko mais vous l'avez déjà si vous utilisez libsodium

Utilisez Argon2id avec au moins 3 itérations, 64 Mio de mémoire et 4 de parallélisme pour les clés de chiffrement dérivées de mots de passe dans les contextes navigateur (recommandations OWASP 2024).

Choisir selon votre stack

• Vous construisez un transfert de fichiers simple avec chiffrement AES-GCM : utilisez Web Crypto directement, sans bibliothèque. HexaTransfer suit ce schéma.
• Vous avez besoin de ChaCha20-Poly1305 ou d'AEAD en streaming : libsodium.js.
• Vous êtes prudent avec WASM ou livrez vers des bundlers contraints : @noble/ciphers + @noble/curves.
• Vous utilisez des clés de protocole NaCl (par ex. boîtes scellées pour la réception de fichiers chiffrés) : @noble ou libsodium, pas crypto-js.
• Vous migrez depuis crypto-js : passez à @noble si la taille du bundle compte, libsodium.js sinon.
• Vous avez besoin de signatures post-quantiques ou KEM : pas encore de bibliothèque JS mature ; consultez @noble/post-quantum (pré-release début 2026).

Signaux d'audit et de maintenance

Avant d'adopter une bibliothèque crypto, vérifiez :

• Date du dernier commit (tout ce qui dépasse 18 mois de stagnation est risqué)
• Rapports d'audit publics (Cure53, Trail of Bits, NCC Group)
• Traqueur de problèmes pour les problèmes de sécurité non résolus
• Nombre de dépendances (moins = surface d'attaque plus petite)
• Téléchargements npm hebdomadaires (plus = plus d'yeux sur le code)

L'écosystème JavaScript a connu des incidents de chaîne d'approvisionnement (event-stream, ua-parser-js, colors) qui font des dépendances minimales une propriété de sécurité. Les bibliothèques crypto sans dépendances d'exécution (famille @noble, tweetnacl) sont plus faciles à auditer de bout en bout que celles tirant des polyfills et des utilitaires.

Essayez sur hexatransfer.com — gratuit, sans compte, jusqu'à 10 Go.