Comment fonctionnent les clés de chiffrement : base de la sécurité

Une clé de chiffrement est une chaîne de bits aléatoires qui verrouille et déverrouille des données. Pour le transfert de fichiers moderne, cela signifie généralement une clé AES de 256 bits — 32 octets de données aléatoires générés par un générateur de nombres aléatoires cryptographiquement sûr (CSPRNG). Le même algorithme qui brouille une vidéo de 10 Go en texte chiffré ne peut la débrouiller qu'avec exactement la même clé. La sécurité des clés est là où le chiffrement tient ou s'effondre : un chiffrement AES-256 parfait ne vaut rien si la clé est faible, prévisible ou exposée. Cet article explique comment les clés sont fabriquées, partagées, stockées et détruites dans des services réels comme HexaTransfer, Tresorit et Proton Drive.

Les clés ne sont que des nombres aléatoires

Une clé de 256 bits représente 32 octets. Si vous en générez une dans le navigateur, elle ressemble à ceci :

const key = crypto.getRandomValues(new Uint8Array(32));
// Uint8Array(32) [183, 45, 201, 77, ...]

Ce qui en fait une "clé", c'est la façon dont un algorithme l'utilise. AES-256-GCM prend une clé de 256 bits, l'étend via un programme de clé en 15 clés de ronde, et les utilise pour brouiller des blocs de 128 bits sur 14 cycles. Le calcul se moque de la provenance des bits — il exige seulement qu'ils soient secrets et imprévisibles.

"Imprévisible" est la partie la plus difficile. Si un attaquant peut deviner l'état de votre générateur aléatoire, il peut régénérer votre clé. Le bug OpenSSL Debian de 2006 a réduit l'entropie des clés à 15 bits pendant deux ans avant d'être découvert — un exemple typique de ce qui se passe quand l'aléatoire échoue.

L'aléatoire cryptographiquement sûr

Les navigateurs fournissent crypto.getRandomValues() qui puise dans le CSPRNG du système d'exploitation : /dev/urandom sous Linux, BCryptGenRandom sous Windows, SecRandomCopyBytes sur macOS. Ces derniers mélangent à leur tour plusieurs sources d'entropie — timings d'interruptions, temps de recherche sur disque, puces RNG matérielles comme Intel RDRAND.

N'utilisez pas Math.random() pour les clés. C'est un Mersenne Twister prévisible et son état peut souvent être récupéré à partir de quelques sorties.

Côté serveur, crypto.randomBytes() dans Node.js et secrets.token_bytes() en Python encapsulent le CSPRNG du système d'exploitation et sont sûrs. Les normes NIST SP 800-90A et SP 800-90B définissent les exigences CSPRNG ; le noyau Linux 5.17+ utilise une conception basée sur BLAKE2s qui les respecte.

Clés symétriques : une clé, deux sens

Les algorithmes symétriques comme AES utilisent une seule clé pour le chiffrement et le déchiffrement. Les options de taille de clé :

128 bits — 2^128 valeurs possibles, sécurisé pour la plupart des usages, approuvé pour SECRET par la NSA CNSSP-15.
192 bits — rare, utilisé dans certains contextes gouvernementaux.
256 bits — 2^256 valeurs, approuvé pour TOP SECRET, valeur par défaut actuelle pour les services de transfert.

Doubler la taille de la clé ne double pas la difficulté de la force brute — cela l'élève au carré. 2^128 est déjà hors d'atteinte (l'âge de l'univers multiplié par dix milliards avec tous les ordinateurs de la Terre). 256 bits est une précaution contre les ordinateurs quantiques, où l'algorithme de Grover réduit effectivement la force des clés symétriques de moitié.

Le problème difficile avec les clés symétriques : amener la même clé aux deux parties sans que personne ne l'intercepte.

Clés asymétriques : l'astuce de la paire

La cryptographie à clé publique résout la distribution des clés. Chaque partie génère une paire de clés mathématiquement liées : une clé publique (partagée ouvertement) et une clé privée (gardée secrète). Tout ce qui est chiffré avec la clé publique ne peut être déchiffré qu'avec la clé privée.

Types de clés asymétriques courants :

RSA-2048 — module de 2048 bits, largement pris en charge, lent. Utilisé dans les certificats TLS.
RSA-4096 — plus fort, encore plus lent.
Curve25519 (X25519) — clé de courbe elliptique de 256 bits, rapide, utilisée par Signal et WireGuard.
Ed25519 — clé de signature de 256 bits, utilisée par SSH et la signature de commits Git.

La clé privée seule fait 32–512 octets selon l'algorithme. Les clés privées RSA sont plus grandes car elles contiennent plusieurs nombres premiers ; les clés privées Curve25519 ne sont que 32 octets aléatoires.

Hybride : combiner les deux pour les systèmes réels

Aucun système pratique ne chiffre de gros fichiers directement avec RSA. Chaque vrai protocole — TLS, PGP, Age, Signal, tout service de transfert sérieux — utilise le chiffrement hybride :

Générer une clé AES aléatoire de 256 bits ("clé de session" ou "clé de fichier").
Chiffrer le fichier avec AES-256-GCM.
Chiffrer la clé de session avec la clé publique du destinataire.
Envoyer les deux.

Le destinataire déchiffre la clé de session avec sa clé privée, puis l'utilise pour déchiffrer le fichier. Vous obtenez la vitesse du chiffrement symétrique et la commodité de distribution de clé de l'asymétrique.

Pour le transfert de fichiers basé sur navigateur, la "clé publique" est souvent remplacée par le fragment d'URL : l'expéditeur génère une clé de session, l'intègre dans l'URL après #, et le navigateur du destinataire la lit localement. Plus simple, et fonctionne sans que les destinataires aient une paire de clés.

Dériver des clés à partir de mots de passe

Les utilisateurs tapent des mots de passe ; les algorithmes veulent des bits aléatoires uniformes. Une fonction de dérivation de clé (KDF) fait le pont :

PBKDF2-HMAC-SHA-256 — itère une fonction de hash. OWASP 2023 recommande 600 000 itérations. Disponible dans l'API Web Crypto.
scrypt — résistant à la mémoire, résiste aux attaques par GPU. Paramètres : N=2^17, r=8, p=1.
Argon2id — meilleure pratique actuelle, vainqueur du Password Hashing Competition 2015. Paramètres : memory=64 Mo, iterations=3, parallelism=4.

Un KDF ajoute un sel (aléatoire, stocké avec le texte chiffré) et un facteur de travail (itérations) pour ralentir la force brute. Un mot de passe aléatoire de 12 caractères avec Argon2id à 64 Mo de mémoire prendrait des milliers d'années à un parc de GPU. Un mot de passe faible comme ete2024 tombe en quelques secondes quel que soit le KDF — le KDF ne peut pas ajouter de l'entropie qui n'était pas là.

Stockage des clés : où vivent-elles ?

Les clés doivent exister quelque part, et cet endroit est une décision critique pour la sécurité :

Mémoire du navigateur (session uniquement). La valeur par défaut pour les transferts éphémères. La clé est générée, utilisée et abandonnée dans le chargement de page.
Fragment d'URL. Partagé via le lien, stocké dans l'historique du navigateur du destinataire. La durée de vie limitée est importante.
Local storage / IndexedDB. Persistant mais accessible à tout JavaScript sur l'origine. Risqué sauf s'il est chiffré avec une autre clé.
Trousseau du système d'exploitation — macOS Keychain, Windows DPAPI, Linux libsecret. Sauvegardé par matériel sur certaines plateformes.
Module de sécurité matériel (HSM) — YubiKey, HSM cloud (AWS CloudHSM, Azure Dedicated HSM). Les clés ne quittent jamais le matériel.
Service de gestion des clés (KMS) — AWS KMS, Google Cloud KMS, HashiCorp Vault. Centralisé, auditable, facturé environ 1 $/clé/mois.

Pour le transfert de fichiers zéro connaissance, la clé vit dans le fragment d'URL et le navigateur de l'expéditeur. Le serveur ne la stocke jamais.

Rotation et destruction des clés

Les clés à longue durée de vie accumulent des risques. La bonne pratique est la rotation :

Certificats TLS : rotation tous les 90 jours (valeur par défaut Let's Encrypt), 398 jours maximum pour les CA publiques depuis 2020.
Clés de chiffrement des données : généralement tournées tous les 90 jours à 1 an dans les systèmes conformes (PCI DSS 4.0 Exigence 3.6).
Clés maîtres : tournées annuellement ou lors de changements de personnel.

La destruction a aussi son importance. Simplement supprimer les fichiers de clés du disque est insuffisant — les SSD peuvent conserver des données dans les zones de nivellement d'usure. La destruction sécurisée nécessite un écrasement ou des commandes de suppression HSM dédiées. L'effacement cryptographique — jeter la clé pour que les données chiffrées deviennent définitivement illisibles — est souvent l'approche la plus propre pour les données en masse.

Les services de transfert de fichiers utilisent généralement des clés par fichier qui n'existent que pendant la durée de vie du transfert (24 heures à 7 jours) et sont abandonnées avec le texte chiffré à l'expiration.

Reconnaître les mauvaises pratiques de clés

Trois modes de défaillance courants à surveiller :

Clés codées en dur dans le code client. Si la clé est la même pour chaque utilisateur, ce n'est pas une clé — c'est de l'obscurcissement.
Clés stockées à côté du texte chiffré sur le même serveur ou la même base de données. Une violation expose les deux.
Aucune rotation des clés. Les systèmes hérités avec des clés de chiffrement vieilles de dix ans ont grossièrement dix ans de risques de violation accumulés.

Un service réputé publie un livre blanc cryptographique couvrant la génération, le stockage, la rotation et la destruction des clés — et se soumet à des audits tiers par des entreprises comme Cure53 ou Trail of Bits.

Mise en perspective

Pour le partage de fichiers sensibles : choisissez un service qui génère des clés de 256 bits côté client via crypto.getRandomValues(), les intègre uniquement dans le fragment d'URL (jamais envoyé au serveur), prend en charge les clés dérivées d'un mot de passe via PBKDF2 ou Argon2id, et expire automatiquement à la fois la clé et le texte chiffré dans les 24 heures.

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