Cryptographie quantique : l'essentiel pour les développeurs

Charles Bennett et Gilles Brassard ont reçu le prix Turing pour leurs travaux fondateurs en science de l'information quantique, et plus précisément pour le protocole de distribution de clés quantiques BB84, publié en 1984. Il s'est écoulé 40 ans entre la publication de l'article et la récompense, ce qui montre le temps qu'il faut à un travail théorique en informatique quantique pour devenir assez pertinent pour que la communauté informatique le reconnaisse.

Cette reconnaissance tombe à un moment intéressant. Les ordinateurs quantiques capables de casser le chiffrement RSA n'existent pas encore, et ne verront peut-être pas le jour avant une dizaine d'années. Pourtant, la communauté cryptographique est déjà en pleine migration. Le NIST a finalisé ses premiers standards de cryptographie post-quantique, les grands navigateurs testent des échanges de clés post-quantiques, et Signal l'a déjà déployé en production. L'écart entre « les ordinateurs quantiques finiront un jour par casser le chiffrement » et « il faut modifier nos systèmes maintenant » s'est refermé.

Ce que les ordinateurs quantiques menacent vraiment

La plupart des articles grand public sur l'informatique quantique et la cryptographie oscillent entre l'alarmisme effrayant (« tout le chiffrement est cassé ! ») et le scepticisme dédaigneux (« ça ne marchera jamais »). La réalité est plus précise, et plus intéressante.

Les ordinateurs quantiques menacent la cryptographie asymétrique, c'est-à-dire les systèmes reposant sur la difficulté mathématique de factoriser de grands nombres (RSA) ou de calculer des logarithmes discrets (Diffie-Hellman, ECC). L'algorithme de Shor, exécuté sur un ordinateur quantique suffisamment grand, peut résoudre ces problèmes en temps polynomial. Concrètement, RSA-2048, que des ordinateurs classiques mettraient des milliards d'années à casser, pourrait théoriquement être craqué par un ordinateur quantique en quelques heures.

Les ordinateurs quantiques sont beaucoup moins dangereux pour la cryptographie symétrique. L'algorithme de Grover offre une accélération quadratique pour la recherche par force brute, ce qui divise en pratique la longueur de la clé par deux. AES-256 devient équivalent à AES-128 face à un attaquant quantique, ce qui reste impraticable à forcer. AES-128 tombe au niveau de sécurité d'une clé de 64 bits, ce qui est inquiétant sans être catastrophique.

What's threatened by quantum computers:
BROKEN (by Shor's algorithm):
├── RSA (all key sizes)
├── Diffie-Hellman key exchange
├── Elliptic Curve Cryptography (ECDSA, ECDH)
└── DSA
WEAKENED (by Grover's algorithm):
├── AES-128 → effectively 64-bit security (upgrade to AES-256)
├── AES-256 → effectively 128-bit security (still secure)
└── SHA-256 → effectively 128-bit preimage resistance (still secure)
NOT AFFECTED:
├── One-time pads
├── Hash-based signatures (SPHINCS+)
└── Symmetric encryption with sufficiently large keys

En pratique, tout ce qui utilise la cryptographie à clé publique (les handshakes TLS, les connexions SSH, la signature de code, les cryptomonnaies, les signatures numériques) devra migrer vers des algorithmes résistants au quantique. Le chiffrement symétrique doit surtout passer à des clés plus longues.

Le problème du « Harvest Now, Decrypt Later »

C'est la raison pour laquelle la migration est urgente, même si les ordinateurs quantiques ne peuvent encore rien casser. Des adversaires, principalement des États, enregistrent très probablement dès maintenant le trafic chiffré, dans l'intention de le déchiffrer le jour où les ordinateurs quantiques seront disponibles.

Pensez aux données qui doivent rester confidentielles pendant plus de 20 ans : communications diplomatiques, rapports de renseignement, secrets industriels, dossiers médicaux. Si ces données sont chiffrées aujourd'hui avec RSA ou ECDH, et qu'un ordinateur quantique capable arrive dans 15 ans, le chiffrement échoue rétroactivement. Les données ont toujours été vulnérables, on ne le savait simplement pas encore.

Il ne s'agit pas d'une modélisation de menace spéculative. La NSA a explicitement recommandé la transition vers des algorithmes résistants au quantique pour les systèmes classifiés. Dans le milieu du renseignement, on part du principe que des États stockent déjà du trafic chiffré. Si vos données doivent rester secrètes longtemps, il fallait migrer hier.

Cryptographie post-quantique : le choix du NIST

Le NIST a organisé un concours pluriannuel pour standardiser des algorithmes de cryptographie post-quantique, sur le modèle de la sélection d'AES. Après l'évaluation de dizaines de candidats, trois algorithmes principaux ont été retenus :

• ML-KEM (Kyber) : un mécanisme d'encapsulation de clés pour l'échange de clés. Il repose sur le problème Module Learning With Errors (MLWE), issu de la cryptographie sur réseaux. Il remplace Diffie-Hellman et ECDH dans les handshakes TLS et les protocoles similaires. Il est rapide, produit des clés relativement petites, et c'est la recommandation principale pour l'échange de clés à usage général.
• ML-DSA (Dilithium) : un algorithme de signature numérique, lui aussi basé sur la cryptographie sur réseaux. Il remplace RSA et ECDSA pour la signature. Les signatures sont plus volumineuses qu'avec ECDSA (environ 2,5 Ko contre 64 octets), ce qui a des conséquences sur les chaînes de certificats et les protocoles qui transmettent beaucoup de signatures.
• SLH-DSA (SPHINCS+) : un schéma de signature numérique basé sur les fonctions de hachage. Sa sécurité repose sur les fonctions de hachage plutôt que sur des problèmes de réseaux. Il est plus lent et produit des signatures plus grosses que ML-DSA, mais sa sécurité s'appuie sur des hypothèses bien connues sur les fonctions de hachage plutôt que sur des hypothèses plus récentes liées aux réseaux. C'est la solution de repli conservatrice.

Les algorithmes basés sur les réseaux (ML-KEM, ML-DSA) sont privilégiés pour des raisons de performance, mais ils reposent sur des problèmes mathématiques relativement récents comparés aux décennies d'analyse dont ont bénéficié RSA et AES. Il existe une petite mais non nulle probabilité qu'une percée en cryptanalyse des réseaux les affaiblisse. SPHINCS+ existe comme assurance : sa sécurité repose sur des fonctions de hachage étudiées depuis plus de 30 ans.

Ce qui est déjà déployé

La cryptographie post-quantique n'est plus théorique. Elle est présente dans les systèmes de production que vous utilisez aujourd'hui.

• Chrome et Firefox utilisent un échange de clés hybride (X25519 + ML-KEM-768) pour les connexions TLS. La partie « hybride » signifie qu'ils combinent un échange de clés classique avec un échange post-quantique : si l'un des deux est cassé, la connexion reste sécurisée. Cela ajoute environ 1 Ko au handshake TLS.
• Signal a déployé PQXDH, un protocole d'accord de clés post-quantique, pour l'échange de clés initial. Chaque nouvelle conversation Signal bénéficie désormais d'une confidentialité persistante post-quantique.
• Apple iMessage a introduit PQ3, qui utilise un échange de clés post-quantique avec des renouvellements de clés périodiques. Apple affirme que cela offre une sécurité de « niveau 3 », le plus haut de son cadre.
• Cloudflare prend en charge l'échange de clés post-quantique sur son CDN. Si votre trafic passe par Cloudflare, vos connexions utilisent peut-être déjà ML-KEM, sans que vous le sachiez.
• AWS KMS prend en charge le TLS post-quantique hybride pour ses opérations de gestion de clés.

Le défi de la migration pour les développeurs

Si vous développez des logiciels qui utilisent de la cryptographie (c'est-à-dire presque tous les logiciels), voici à quoi ressemble concrètement la migration.

TLS : largement géré pour vous

Si votre application utilise TLS via une bibliothèque standard (OpenSSL, BoringSSL, crypto/tls de Go), le support post-quantique est ajouté au niveau de la bibliothèque. Vous en bénéficierez via les mises à jour de dépendances. L'action principale consiste à ne pas figer vos versions de bibliothèques TLS anciennes et à vérifier que vos systèmes gèrent des handshakes un peu plus volumineux.

L'augmentation de taille compte plus qu'on ne le pense. ML-KEM-768 ajoute environ 1 100 octets au message ClientHello de TLS. Certains middleboxes, pare-feux et piles TLS mal implémentées ne gèrent pas les ClientHello dépassant environ 512 octets. Le déploiement de l'échange de clés post-quantique chez Google a révélé qu'environ 0,5 % des connexions échouaient à cause d'incompatibilités avec des middleboxes. Si vos utilisateurs sont derrière des pare-feux d'entreprise, testez-le.

Signatures numériques : plus perturbantes

Les signatures post-quantiques sont nettement plus volumineuses que les signatures classiques. Une signature ECDSA fait 64 octets. Une signature ML-DSA-65 fait environ 3 300 octets, et une signature SLH-DSA peut dépasser 17 000 octets. Les effets en cascade sont nombreux :

• Les chaînes de certificats X.509 deviennent beaucoup plus lourdes. Une chaîne typique de 3 certificats avec des signatures ML-DSA pèse environ 10 Ko de plus qu'avec ECDSA. Sur des connexions à bande passante limitée, cela compte.
• Les systèmes blockchain et les cryptomonnaies qui reposent sur des signatures compactes font face à des problèmes de passage à l'échelle. Chaque transaction avec une signature post-quantique occupe 50 fois plus d'espace.
• La signature de code, la signature de paquets et la vérification des mises à jour logicielles doivent gérer des signatures plus grosses sans casser les hypothèses de taille des outils existants.
• Les journaux de transparence des certificats, les réponses OCSP et la distribution des CRL grossissent tous.

Cryptographie au niveau applicatif : votre problème

Si votre application implémente ses propres protocoles cryptographiques (chiffrement de bout en bout, échange de clés maison, jetons signés, stockage chiffré), vous devez planifier activement votre migration. La stratégie générale :

1. Faites l'inventaire de vos dépendances cryptographiques. Repérez chaque endroit où votre code utilise RSA, ECDSA, ECDH ou Diffie-Hellman. Cela inclut les bibliothèques, les systèmes de gestion de clés, les autorités de certification et les modules de sécurité matériels (HSM).
2. Adoptez d'abord des schémas hybrides. Combinez des algorithmes classiques et post-quantiques. Si l'algorithme post-quantique révèle une faiblesse, vous revenez à la sécurité classique. Si les ordinateurs quantiques arrivent, vous êtes déjà protégé par le post-quantique.
3. Utilisez des bibliothèques éprouvées. Ne réimplémentez pas vous-même les algorithmes post-quantiques. Utilisez liboqs (Open Quantum Safe), qui s'intègre à OpenSSL et fournit des implémentations testées de ML-KEM, ML-DSA et SPHINCS+.
4. Mesurez l'impact sur les performances. Les opérations post-quantiques sont généralement rapides (la génération de clés ML-KEM est comparable à ECDH), mais la vérification de signature est plus lente, et la taille des clés et des signatures affecte la bande passante et le stockage.
5. Prévoyez l'agilité cryptographique. Concevez vos protocoles de façon que les algorithmes cryptographiques puissent être remplacés sans casser le protocole. C'est difficile à rajouter après coup : il est bien plus simple de l'intégrer dès le départ.

Et la distribution quantique de clés ?

BB84 de Bennett et Brassard, le travail qui leur a valu le prix Turing, est une distribution quantique de clés (QKD), une approche totalement différente. Au lieu de s'appuyer sur des problèmes mathématiques que les ordinateurs quantiques ne savent pas résoudre, la QKD utilise les propriétés physiques de la mécanique quantique pour distribuer les clés de chiffrement. Toute tentative d'espionnage de l'échange de clés perturbe les états quantiques et devient détectable.

La QKD est théoriquement élégante et sûre par construction, car elle repose sur la physique plutôt que sur des hypothèses de calcul. En pratique, ses limites sont sérieuses : elle nécessite des liaisons dédiées par fibre optique (impossible via Internet), la portée maximale est de quelques centaines de kilomètres sans répéteurs quantiques (qui n'existent pas encore à grande échelle), et elle coûte extrêmement cher. La Chine a déployé un réseau QKD entre Pékin et Shanghai, mais il repose sur des nœuds relais de confiance, ce qui va un peu à l'encontre de l'objectif.

Pour un avenir prévisible, la cryptographie post-quantique (des algorithmes mathématiques sur ordinateurs classiques) reste la voie pratique. La QKD est pertinente pour les liaisons gouvernementales et militaires très sensibles, mais elle ne remplacera pas TLS pour votre application web.

Calendrier : quand cela deviendra-t-il vraiment important ?

Personne ne sait quand un ordinateur quantique cryptographiquement pertinent (CRQC) existera, c'est-à-dire assez puissant pour casser RSA-2048. Les estimations vont de 2030 à « jamais », la plupart des experts se regroupant autour de 2035-2040. Les plus gros ordinateurs quantiques actuels comptent environ 1 000 qubits physiques, alors que casser RSA-2048 demanderait, selon les estimations, des millions de qubits logiques corrigés des erreurs.

Mais voilà : la date exacte importe peu. La migration elle-même prend des années. Les grandes organisations doivent recenser leurs usages cryptographiques, mettre à jour leurs bibliothèques, tester la compatibilité, renouveler les clés et les certificats, et adapter leurs protocoles. Le NIST recommande de terminer la transition d'ici 2035. Sachant que les migrations logicielles en entreprise prennent couramment 5 à 10 ans, commencer maintenant est déjà sans doute tardif.

Le conseil pratique est banal mais juste : mettez à jour vos bibliothèques TLS, planifiez la migration de vos signatures, adoptez des schémas hybrides lorsque c'est possible, et intégrez l'agilité cryptographique dans les nouveaux systèmes. Inutile de paniquer, mais il faut commencer. Les organisations qui auront le plus de mal sont celles qui considèrent la migration post-quantique comme un problème pour plus tard, jusqu'à ce qu'il devienne une urgence.