Chiffrement résistant aux quantiques : préparez la sécurité du futur
Les ordinateurs quantiques menacent le chiffrement actuel. Découvrez les algorithmes post-quantiques Kyber et Dilithium pour la sécurité future.
Le chiffrement résistant aux quantiques protège les fichiers contre des adversaires disposant d'un ordinateur quantique cryptographiquement pertinent — capable d'exécuter l'algorithme de Shor suffisamment vite pour casser RSA-2048 ou ECDH P-256 en quelques heures. Le NIST a finalisé trois standards post-quantiques en août 2024 : ML-KEM (FIPS 203, anciennement Kyber) pour l'encapsulation de clé, ML-DSA (FIPS 204, anciennement Dilithium) pour les signatures, et SLH-DSA (FIPS 205, anciennement SPHINCS+) pour les signatures à base de hachage. Pour le transfert de fichiers, la voie pratique en 2026 est hybride : X25519-MLKEM-768 pour l'échange de clés, en conservant AES-256-GCM pour le chiffrement en vrac puisque les chiffrements symétriques ne perdent que la moitié de leurs bits face à l'algorithme de Grover.
Pourquoi le chiffrement symétrique est globalement sûr
L'algorithme de Grover divise par deux la longueur de clé effective des chiffrements symétriques — AES-256 descend à 128 bits de sécurité quantique, AES-128 descend à 64 et devient cassable. La mitigation est simple : utiliser AES-256 partout. ChaCha20-Poly1305 survit de même avec 128 bits de sécurité post-quantique. Les fonctions de hachage sont encore mieux positionnées ; SHA-256 conserve 128 bits de résistance aux collisions, SHA-384 conserve 192. Le ciel ne tombe pas sur la crypto symétrique. Tout outil de transfert de fichiers sérieux utilise déjà AES-256-GCM ; vous n'avez rien à changer de ce côté.
Là où le vrai danger se situe : l'échange de clés et les signatures
Les primitives à clé publique sont le problème. La factorisation RSA et le logarithme discret sur courbe elliptique tombent tous deux face à l'algorithme de Shor, qui nécessite environ 4 000 qubits logiques pour casser RSA-2048. Le Kookaburra 2025 d'IBM a 4 158 qubits physiques ; une fois la correction d'erreurs mature (vers 2030–2035 selon le calendrier NIST), l'attaque devient faisable. Chaque session TLS 1.3 utilise aujourd'hui ECDH ou X25519 pour l'échange de clés — c'est là que la rupture quantique frappe. Les fichiers que vous transférez en 2026 pourraient être déchiffrés en 2035 par un attaquant qui a stocké le texte chiffré. « Récolter maintenant, déchiffrer plus tard » n'est pas hypothétique ; des documents de la NSA de 2013 décrivent cette stratégie.
ML-KEM : le nouveau moteur d'échange de clés
ML-KEM (Module-Lattice Key Encapsulation Mechanism) est l'échange de clés post-quantique choisi par le NIST, standardisé comme FIPS 203. Trois jeux de paramètres : ML-KEM-512 (128 bits de sécurité quantique), ML-KEM-768 (192 bits) et ML-KEM-1024 (256 bits). Les clés publiques font 800 à 1 568 octets, les textes chiffrés 768 à 1 568 octets — grand comparé aux 32 octets de X25519, mais encore gérable. Chrome 131 a intégré X25519-MLKEM-768 hybride par défaut fin 2024. Cloudflare l'a activé sur tous ses endpoints en décembre 2024. Si votre service de transfert de fichiers tourne derrière Cloudflare, votre poignée de main TLS 1.3 est déjà protégée post-quantique.
ML-DSA pour l'authenticité
ML-DSA (Module-Lattice Digital Signature Algorithm), FIPS 204, remplace ECDSA et Ed25519 pour les signatures. Jeux de paramètres ML-DSA-44 (128 bits), ML-DSA-65 (192 bits), ML-DSA-87 (256 bits). Les signatures font 2 420 à 4 595 octets — contre 64 octets pour Ed25519. Pour le transfert de fichiers, les signatures comptent à deux endroits : l'authentification du certificat TLS du serveur, et la signature des entrées de journal d'audit pour la non-répudiation. Let's Encrypt et DigiCert prévoient tous deux l'émission de certificats ML-DSA pour 2026–2027. En attendant, les certificats hybrides contenant à la fois des signatures Ed25519 et ML-DSA font la transition.
SLH-DSA comme solution de repli conservative
SLH-DSA (FIPS 205, anciennement SPHINCS+) est basé sur le hachage et ne dépend que de la sécurité de SHA-256 ou SHAKE — aucune hypothèse mathématique nouvelle. C'est l'algorithme qu'on choisit si on se méfie des réseaux de treillis. Les signatures sont beaucoup plus grandes (7 856 à 49 856 octets) et plus lentes à calculer, mais l'argument de sécurité est irréfutable. Pour les journaux d'audit à longue rétention où les signatures doivent être fiables en 2050, SLH-DSA est la couverture. Pour chaque transfert de fichier de 30 secondes, c'est excessif.
Schémas hybrides : ceinture et bretelles
Le déploiement purement post-quantique est risqué parce que ML-KEM est nouveau — la cryptanalyse va se poursuivre. Le consensus industriel, codifié dans NIST SP 800-227 (brouillon 2024), est hybride : exécuter à la fois les algorithmes classiques et post-quantiques en parallèle, XOR les secrets dérivés. Un attaquant doit casser les deux pour déchiffrer. X25519-MLKEM-768 est le défaut actuel pour TLS ; RSA-3072 + ML-KEM-768 pour les environnements contraints. Pour le chiffrement de fichiers au repos, vous pouvez chiffrer hybridement la clé de fichier AES-256 sous à la fois une clé publique X25519 et une ML-KEM, et stocker les deux textes chiffrés.
Chemins de migration pour les systèmes existants
Le problème d'agilité cryptographique est réel. La plupart des bases de code de transfert de fichiers codent en dur les noms d'algorithme dans les configurations et définitions de struct. Refactorisez vers des OID et des fournisseurs enfichables pour que remplacer ECDH par ML-KEM soit un changement de configuration, pas une réécriture. Le NCSC (Royaume-Uni) recommande de terminer l'inventaire d'ici fin 2026, le déploiement hybride d'ici 2028, et le passage complet au post-quantique d'ici 2031. CNSA 2.0 (systèmes de sécurité nationale américains) impose ML-KEM et ML-DSA dans les nouveaux systèmes d'ici 2027 et partout d'ici 2033. Votre fournisseur de transfert de fichiers devrait publier une feuille de route PQC ; s'il n'en a pas mentionné une d'ici 2026, interrogez-le.
Tailles de clés, bande passante et le cas mobile
ML-KEM-768 ajoute environ 2,3 Ko par poignée de main TLS par rapport à X25519. Sur une connexion 5G c'est 2 ms de latence, invisible. Sur un lien satellite avec 600 ms de RTT, perceptible mais tolérable. Pour un transfert de fichier de 10 Go qui prend déjà des minutes, la surcharge est négligeable. La préoccupation concerne les services à fort nombre de connexions (un CDN acceptant 10 000 poignées de main/seconde) où la surcharge mémoire se multiplie. HexaTransfer et les services similaires tournant derrière Cloudflare externalisent ce coût vers la périphérie.
Quand les signatures de fichiers doivent durer des décennies
Le cas vraiment intéressant est celui des signatures numériques sur des fichiers destinés à être vérifiables en 2060. Un contrat .pdf signé avec Ed25519 en 2026 pourra être invérifiable (ou falsifiable) en 2040. Option 1 : re-signer périodiquement avec l'algorithme le meilleur du moment. Option 2 : signer avec SLH-DSA aujourd'hui et faire confiance à la longévité de SHA-256. Option 3 : horodater la signature sur une blockchain (OpenTimestamps l'ancre sur Bitcoin) pour qu'au moins l'existence et la date soient préservées cryptographiquement même si l'algorithme de signature tombe. La signature de grade archivistique est là où la réflexion post-quantique compte le plus.
Essayez sur hexatransfer.com — gratuit, sans compte, jusqu'à 10 Go.
Envoyez vos fichiers volumineux en toute sécurité avec le chiffrement de bout en bout
Transférez des fichiers jusqu'à 10 Go gratuitement avec le chiffrement de bout en bout. Aucun compte requis. Vos fichiers sont chiffrés dans votre navigateur avant l'envoi — personne d'autre ne peut les lire.
Envoyer un fichier