Chiffrement symétrique vs asymétrique : différences clés

Le chiffrement symétrique utilise une seule clé pour chiffrer et déchiffrer — pensez à AES-256-GCM, le chiffrement qui sécurise vos fichiers lors du transfert. Le chiffrement asymétrique utilise une paire de clés : une clé publique que tout le monde peut voir et une clé privée que vous seul détenez, utilisée par des algorithmes comme RSA-4096 et Curve25519. Le symétrique est rapide (gigaoctets par seconde sur les CPU modernes) mais nécessite que les deux parties partagent le même secret. L'asymétrique résout le problème de l'échange de clé mais est 1 000 fois plus lent. Chaque service de transfert de fichiers moderne — HexaTransfer, Tresorit, Proton Drive, SwissTransfer — utilise les deux : l'asymétrique pour échanger une clé symétrique, puis le symétrique pour chiffrer le fichier proprement dit.

Le monde à une clé : le chiffrement symétrique

Les chiffrements symétriques utilisent la même clé dans les deux sens. Si je chiffre un fichier avec la clé K, vous avez besoin de la clé K pour le déchiffrer. Les principaux algorithmes symétriques encore en usage :

AES (Rijndael) avec des clés de 128, 192 ou 256 bits, standardisé dans FIPS 197.
ChaCha20 avec des clés de 256 bits, préféré sur les appareils sans accélération matérielle AES-NI.
3DES — déprécié par le NIST en 2023, ne l'utilisez pas.

Le débit est le grand avantage. AES-256-GCM tourne à environ 3–5 Go/s par cœur sur Intel AES-NI, et ChaCha20-Poly1305 atteint 1,5–3 Go/s sur les téléphones ARM. Chiffrer un fichier de 10 Go prend quelques secondes.

Le problème : comment faites-vous parvenir la clé à l'autre personne ? L'envoyer par e-mail annule l'intérêt. C'est le problème de la distribution des clés, et c'est pourquoi l'asymétrique existe.

Le monde à deux clés : le chiffrement asymétrique

Inventé par Diffie et Hellman en 1976 et réalisé par Rivest, Shamir et Adleman sous forme de RSA en 1977. Chaque utilisateur a une paire de clés : une clé publique publié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, et vice versa.

Si vous souhaitez m'envoyer un fichier secret, vous le chiffrez avec ma clé publique. Seule ma clé privée peut l'ouvrir — et je n'ai jamais eu à vous partager quoi que ce soit de secret. Problème de distribution des clés résolu.

Algorithmes asymétriques actuels :

RSA-2048 ou RSA-4096 — lent mais universellement pris en charge, utilisé dans les certificats TLS.
Courbe elliptique (ECDH, ECDSA) sur des courbes comme P-256, P-384 ou Curve25519 — clés plus petites, opérations plus rapides. Une clé EC de 256 bits correspond à la sécurité d'une clé RSA de 3 072 bits.
Ed25519 — la valeur par défaut moderne pour la signature, utilisée par SSH et Signal.

Pourquoi l'asymétrique est trop lent pour les fichiers

Les calculs asymétriques sont coûteux. Le chiffrement RSA-4096 tourne à environ 100–500 opérations par seconde sur un CPU moderne. Chaque opération traite environ 470 octets (la taille de bloc RSA moins le rembourrage). Soit environ 200 Ko/s — environ 50 000 fois plus lent qu'AES-256-GCM.

Chiffrer un fichier de 10 Go avec RSA prendrait environ 14 heures. Avec AES-256-GCM, environ 3 secondes. Cette asymétrie de vitesse explique pourquoi personne n'utilise réellement RSA pour chiffrer des fichiers directement.

Le chiffrement hybride : l'approche du monde réel

Chaque protocole qui a besoin à la fois de sécurité et de vitesse combine les deux. TLS 1.3, PGP, Signal, Age et tout service de transfert de fichiers crédible utilisent ce modèle :

L'expéditeur génère une clé AES aléatoire de 256 bits (la "clé de session" ou "clé de fichier").
Le fichier est chiffré avec AES-256-GCM en utilisant cette clé.
La clé AES elle-même est chiffrée avec la clé publique du destinataire (RSA-OAEP ou ECIES).
Le texte chiffré et la clé chiffrée voyagent tous les deux vers le destinataire.
Le destinataire déchiffre la clé AES avec sa clé privée, puis l'utilise pour déchiffrer le fichier.

Vous payez le coût asymétrique une seule fois par destinataire, pour une clé de 256 bits. Le fichier en masse est traité symétriquement à pleine vitesse. Le meilleur des deux mondes.

Où les services de transfert divergent

Les services de transfert basés sur navigateur font face à une complication : le destinataire peut ne pas avoir de paire de clés. Il clique simplement sur un lien. Trois modèles gèrent cela :

Symétrique par lien partagé uniquement (SwissTransfer, HexaTransfer, successeurs de Firefox Send). Une clé AES-256 aléatoire est générée dans le navigateur de l'expéditeur, intégrée dans le fragment d'URL, et le navigateur du destinataire la lit depuis le fragment. Aucune cryptographie asymétrique requise — le fragment est le canal.
Asymétrique de compte à compte (Tresorit, Proton Drive). Chaque utilisateur a une paire de clés RSA ou ECC générée à l'inscription. Les fichiers chiffrés pour un destinataire spécifique utilisent sa clé publique.
Hybride avec mot de passe (nombreux services). Le fragment d'URL contient un sel ; l'utilisateur tape un mot de passe ; PBKDF2 ou Argon2id dérive la clé symétrique. Pas d'asymétrique, mais le mot de passe sert de secret partagé.

L'approche par lien partagé est la plus simple et fonctionne pour les destinataires sans compte. L'asymétrique lié à un compte est plus solide car la perte du lien ne divulgue pas la clé. Choisissez en fonction de votre modèle de menace.

Les signatures numériques : l'autre rôle de l'asymétrique

L'asymétrique fait quelque chose que le symétrique ne peut pas : prouver l'auteur. Si je signe un fichier avec ma clé privée, quiconque possède ma clé publique peut vérifier que je l'ai signé, et sait qu'il n'a pas été altéré depuis. Le symétrique peut assurer l'authentification (HMAC, tag GCM) mais seulement entre des parties qui partagent déjà un secret.

Algorithmes de signature en usage :

RSA-PSS avec SHA-256 — héritage mais largement pris en charge.
ECDSA sur P-256 ou P-384 — approuvé NIST, utilisé dans les systèmes fédéraux.
Ed25519 — rapide, déterministe, résistant aux mauvais générateurs aléatoires. Le choix moderne.

La distribution de logiciels (apt, Homebrew, images Docker) s'appuie sur des signatures Ed25519 ou RSA pour empêcher la falsification de la chaîne d'approvisionnement. Les services de transfert de fichiers n'exposent généralement pas les signatures directement, mais le tag d'authentification GCM dans AES-256-GCM assure l'intégrité dans un seul chiffrement.

Tailles de clés et niveaux de sécurité

Un tableau de conversion rapide pour une sécurité équivalente contre les ordinateurs classiques :

128 bits symétrique = 3 072 bits RSA = 256 bits EC (P-256 ou Curve25519)
192 bits symétrique = 7 680 bits RSA = 384 bits EC (P-384)
256 bits symétrique = 15 360 bits RSA = 512 bits EC (P-521)

La recommandation actuelle du NIST pour les nouveaux systèmes : au moins 112 bits de sécurité, soit RSA-2048 ou P-256. Les agences fédérales utilisent 128 bits (RSA-3072, P-384) comme minimum jusqu'en 2030.

Face aux futurs ordinateurs quantiques, les clés symétriques perdent environ la moitié de leur force (algorithme de Grover), tandis que RSA et ECC sont entièrement compromis (algorithme de Shor). Le NIST a standardisé des remplaçants post-quantiques en 2024 : ML-KEM (anciennement Kyber) pour l'échange de clés et ML-DSA (anciennement Dilithium) pour les signatures. La migration est en cours mais lente.

Quand utiliser lequel

Un guide de décision pratique :

Chiffrer un fichier pour soi-même (sauvegarde, archivage) : AES-256-GCM symétrique avec un mot de passe fort via Argon2id. Pas besoin d'asymétrique.
Envoyer un fichier à un destinataire connu : hybride — AES-256-GCM pour le fichier, enveloppe à clé publique pour la clé de session.
Envoyer à plusieurs destinataires : chiffrez le fichier une fois avec AES, puis encapsulez la clé séparément avec la clé publique de chaque destinataire. Ajoute environ 300 octets par destinataire.
Prouver l'auteur : signature Ed25519 sur le texte chiffré.
Partage ponctuel via lien : symétrique avec la clé dans le fragment d'URL.

Assembler le tout

Pour des transferts sensibles aujourd'hui, une configuration pragmatique : AES-256-GCM pour le chiffrement massif, X25519 ECDH pour l'échange de clés si les destinataires ont des identités, PBKDF2 ou Argon2id pour les clés dérivées d'un mot de passe, et TLS 1.3 comme couche de transport. Cette combinaison est ce que déploient les services modernes audités.

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