Le National Institute of Standards and Technology (NIST) a finalisé le 23 octobre 2025 les standards de cryptographie post-quantique. Trois algorithmes sont officiellement approuvés : CRYSTALS-Kyber pour l'échange de clés, CRYSTALS-Dilithium pour les signatures numériques et SPHINCS+ comme alternative. La course contre les ordinateurs quantiques commence.
La Menace Quantique
Store Now, Decrypt Later
Scénario actuel :
2025 : Attaquant intercepte et stocke traffic chiffré RSA/ECC
2030 : Ordinateur quantique suffisamment puissant disponible
→ Déchiffre rétroactivement toutes les données de 2025
Données sensibles avec longue durée de vie :
- Secrets d'État (classified : 25-50 ans)
- Données médicales (HIPAA : 6 ans minimum, souvent à vie)
- Propriété intellectuelle (brevets : 20 ans)
- Contrats financiers (archivage : 10 ans)
Problème : Si chiffré avec RSA aujourd'hui → vulnérable demain
Timeline ordinateurs quantiques :
- 2025 : 100-1000 qubits (pas encore dangereux)
- 2028 : 10000 qubits (peut casser RSA-2048 en théorie)
- 2030-2033 : 1000000 qubits (casse RSA-4096 en heures)
Action requise : migrer MAINTENANT (avant 2028)
Algorithmes Vulnérables
Cassables par Shor's Algorithm (quantum) :
- ✅ RSA : cassable en temps polynomial
- ✅ Elliptic Curve (ECC, ECDSA, ECDH) : cassable
- ✅ Diffie-Hellman : cassable
- ✅ DSA : cassable
Résistants (pour l'instant) :
- ⚠️ AES-128 : réduit à 64 bits de sécurité (Grover's Algorithm)
- ✅ AES-256 : reste sûr (128 bits sécurité effective)
- ✅ SHA-256 : réduit mais acceptable
- ✅ SHA-384/512 : restent sûrs
Conclusion : tout le PKI actuel (RSA/ECC) = obsolète en 2030
Algorithmes NIST Approuvés
1. CRYSTALS-Kyber : Key Encapsulation
Usage : remplace RSA/ECDH pour échange de clés
Principe (Learning With Errors) :
Problème mathématique :
A × s + e = b
Où :
- A = matrice publique (grande, aléatoire)
- s = secret (petit vecteur)
- e = erreur (petit bruit)
- b = résultat public
Attaquant connaît A et b, doit trouver s
→ Problème NP-difficile même pour ordinateur quantique
Tailles de clés :
| Algorithme | Clé publique | Clé privée | Ciphertext | Niveau sécurité |
|---|---|---|---|---|
| RSA-2048 | 256 bytes | 256 bytes | 256 bytes | Cassé en 2030 |
| ECDH-256 | 32 bytes | 32 bytes | 32 bytes | Cassé en 2030 |
| Kyber-512 | 800 bytes | 1632 bytes | 768 bytes | AES-128 équivalent |
| Kyber-768 | 1184 bytes | 2400 bytes | 1088 bytes | AES-192 équivalent |
| Kyber-1024 | 1568 bytes | 3168 bytes | 1568 bytes | AES-256 équivalent |
Performance (benchmarks CPU Intel i7) :
| Opération | RSA-2048 | ECDH-256 | Kyber-768 |
|---|---|---|---|
| Keygen | 50ms | 0.5ms | 0.04ms |
| Encapsulation | 2ms | 0.5ms | 0.05ms |
| Decapsulation | 50ms | 0.5ms | 0.06ms |
Kyber = 10-100x plus rapide que RSA !
2. CRYSTALS-Dilithium : Signatures
Usage : remplace RSA/ECDSA pour signatures numériques
Principe (Module-LWE) :
- Similaire à Kyber mais optimisé pour signatures
- Basé sur lattices (réseaux euclidiens)
Tailles :
| Algorithme | Clé publique | Clé privée | Signature | Niveau sécurité |
|---|---|---|---|---|
| RSA-2048 | 256 bytes | 256 bytes | 256 bytes | Cassé en 2030 |
| ECDSA-256 | 32 bytes | 32 bytes | 64 bytes | Cassé en 2030 |
| Dilithium2 | 1312 bytes | 2528 bytes | 2420 bytes | AES-128 équivalent |
| Dilithium3 | 1952 bytes | 4000 bytes | 3293 bytes | AES-192 équivalent |
| Dilithium5 | 2592 bytes | 4864 bytes | 4595 bytes | AES-256 équivalent |
Performance :
| Opération | RSA-2048 | ECDSA-256 | Dilithium3 |
|---|---|---|---|
| Keygen | 50ms | 0.5ms | 0.3ms |
| Sign | 50ms | 0.6ms | 0.5ms |
| Verify | 2ms | 1.2ms | 0.2ms |
Dilithium = comparable à ECDSA en vitesse
3. SPHINCS+ : Signatures Hash-Based
Usage : alternative à Dilithium (backup si Dilithium cassé)
Principe (Merkle Trees) :
- Basé uniquement sur fonctions de hash (SHA-256)
- Sécurité prouvée (pas d'hypothèses mathématiques complexes)
- Très conservatif : si SHA-256 sûr → SPHINCS+ sûr
Tailles :
| Algorithme | Clé publique | Clé privée | Signature |
|---|---|---|---|
| SPHINCS+-128s | 32 bytes | 64 bytes | 7856 bytes |
| SPHINCS+-256s | 64 bytes | 128 bytes | 29792 bytes |
Problème : signatures ÉNORMES (30kb !)
Usage recommandé :
- Root CA certificates (signés rarement)
- Backup si Dilithium prouvé vulnérable
- Systèmes ultra-critiques (militaire, nucléaire)
Migration Pratique
Phase 1 : Inventaire (3-6 mois)
Identifier tous usages cryptographiques :
# Audit certificats TLS
find /etc/ssl/certs -name "*.crt" -exec openssl x509 -in {} -text -noout \; | grep "Public Key Algorithm"
# Audit code source
grep -r "RSA\|ECDSA\|openssl_" ./src/
# Audit bases de données
# Identifier colonnes chiffrées et algorithmes utilisés
Prioriser par criticité :
- Critique : données longue durée de vie (santé, défense)
- Haute : PKI d'entreprise, code signing
- Moyenne : TLS Internet-facing
- Basse : chiffrement éphémère (sessions)
Phase 2 : Hybrid Cryptography (2025-2028)
Approche recommandée : combiner ancien + nouveau
TLS 1.3 avec hybride :
Client Hello :
- Supported Groups :
* X25519 (ECC classique)
* X25519Kyber768Draft00 (hybride !)
Server choisit hybride si supporté, sinon ECC
Key Exchange :
shared_secret = KDF(
ECDH(client_x25519, server_x25519) || # ECC classique
Kyber.Decap(kyber_ciphertext) # Post-quantum
)
Sécurité :
- Si Kyber cassé → ECC protège encore
- Si ECC cassé (quantum) → Kyber protège
- Les deux doivent être cassés pour compromettre
Implémentation OpenSSL 3.2+ :
# Compiler avec support PQC
git clone https://github.com/open-quantum-safe/openssl
cd openssl
./Configure --with-oqs
make && make install
# Générer certificat hybride
openssl req -x509 -new \
-newkey dilithium3 \
-keyout server.key \
-out server.crt \
-nodes -days 365
# Configurer Nginx
server {
listen 443 ssl;
ssl_certificate /etc/ssl/certs/server.crt;
ssl_certificate_key /etc/ssl/private/server.key;
# Ciphersuites hybrides
ssl_ciphers 'TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_KYBER768_AES256_GCM_SHA384';
ssl_prefer_server_ciphers on;
}
Phase 3 : Migration Complète (2028-2030)
Remplacer complètement RSA/ECC par PQC
PKI Migration :
1. Créer nouvelle Root CA avec Dilithium5
↓
2. Cross-sign avec ancienne Root CA RSA
(pendant période transition)
↓
3. Émettre nouveaux certificats intermédiaires Dilithium3
↓
4. Émettre certificats leaf Dilithium2/3
↓
5. Révoquer anciens certificats RSA
(après que tous clients supportent PQC)
Timeline recommandée :
- 2025-2026 : Hybrid déployé sur 80% systèmes
- 2027-2028 : PQC-only sur systèmes critiques
- 2029-2030 : Dépréciation complète RSA/ECC
Code Examples
Python avec liboqs
from oqs import KeyEncapsulation, Signature
# Key Encapsulation (Kyber)
kem = KeyEncapsulation("Kyber768")
# Serveur génère keypair
public_key = kem.generate_keypair()
# Client encapsule secret
ciphertext, shared_secret_client = kem.encap_secret(public_key)
# Serveur décapsule
shared_secret_server = kem.decap_secret(ciphertext)
assert shared_secret_client == shared_secret_server
# Utiliser shared_secret comme clé AES-256
from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes
cipher = Cipher(
algorithms.AES(shared_secret_client[:32]),
modes.GCM(nonce)
)
# Signature (Dilithium)
sig = Signature("Dilithium3")
public_key_sig = sig.generate_keypair()
message = b"Important document"
signature = sig.sign(message)
# Vérification
is_valid = sig.verify(message, signature, public_key_sig)
print(f"Signature valide : {is_valid}")
Go avec circl
package main
import (
"github.com/cloudflare/circl/kem/kyber/kyber768"
"github.com/cloudflare/circl/sign/dilithium/mode3"
)
func main() {
// Kyber768 KEM
publicKey, privateKey := kyber768.GenerateKeyPair(nil)
ct, ss_client, err := kyber768.Encapsulate(publicKey)
if err != nil {
panic(err)
}
ss_server, err := kyber768.Decapsulate(privateKey, ct)
if err != nil {
panic(err)
}
// ss_client == ss_server : shared secret établi !
// Dilithium3 Signature
pk, sk := mode3.GenerateKey(nil)
message := []byte("Critical message")
signature := mode3.Sign(sk, message)
valid := mode3.Verify(pk, message, signature)
println("Signature valid:", valid)
}
Support Écosystème
Bibliothèques Disponibles
Open Quantum Safe (OQS) :
- C/C++ : liboqs
- OpenSSL : fork OQS-OpenSSL
- BoringSSL : fork OQS-BoringSSL
Cloudflare circl :
- Go : github.com/cloudflare/circl
- Production-ready (utilisé par Cloudflare)
PQClean :
- C : implémentations optimisées
- Utilisé par projets critiques
Microsoft :
- .NET : PQCrypto NuGet package
- Azure : support natif prévu Q2 2026
Google :
- Chromium : support hybride X25519Kyber768 depuis Chrome 124
- Android : BoringSSL avec PQC (Android 16+)
Protocoles
TLS 1.3 :
- RFC 9180 : Hybrid Public Key Encryption (HPKE)
- Chrome, Firefox : support hybride activé
SSH :
- OpenSSH 9.6+ : support Kyber
ssh -o KexAlgorithms=sntrup761x25519-sha512@openssh.com
VPN :
- WireGuard : PQ-WireGuard variant
- OpenVPN : plugin PQC disponible
Signal Protocol :
- PQXDH : extension post-quantum (déployé 2025)
Coûts et Limitations
Bande Passante
Impact sur TLS Handshake :
| Handshake | RSA-2048 | ECDH-256 | Kyber768 Hybrid |
|---|---|---|---|
| ClientHello | 200 bytes | 200 bytes | 1400 bytes |
| ServerHello | 1500 bytes | 1500 bytes | 2700 bytes |
| Total | 1700 bytes | 1700 bytes | 4100 bytes |
Overhead : +2.4kb par handshake
Impact :
- Réseau rapide (fibre) : négligeable
- Mobile 4G : +50ms latency
- Satellite/3G : +200ms latency
Mitigation :
- TLS session resumption (évite handshakes)
- 0-RTT avec PSK
Stockage
Certificats plus gros :
| Type | RSA-2048 | Dilithium3 |
|---|---|---|
| Certificat X.509 | 1kb | 6kb |
| Chain (3 certs) | 3kb | 18kb |
Impact navigateur :
- Cache certificats : +15kb par site
- Négligeable (sites modernes = 2-5MB)
Recommandations par Secteur
Secteur Public / Défense
Timeline agressive :
- 2025 : Audit complet + POC hybride
- 2026 : Déploiement hybride obligatoire
- 2027 : Migration PQC-only classified systems
- 2028 : Dépréciation complète RSA/ECC
Algorithmes :
- Kyber-1024 (sécurité maximale)
- Dilithium5
- SPHINCS+-256 pour root CAs
Santé / Finance
Timeline standard :
- 2025-2026 : Inventaire + roadmap
- 2027-2028 : Hybride production
- 2029 : PQC-only systèmes critiques
- 2030 : Migration complète
Algorithmes :
- Kyber-768 (bon compromis)
- Dilithium3
Tech / Startups
Timeline flexible :
- 2026 : Activer hybride si disponible dans stack
- 2028 : Évaluer migration PQC-only
- 2030+ : Migrer selon besoins business
Algorithmes :
- Kyber-512/768
- Dilithium2/3
Articles connexes
Pour approfondir le sujet, consultez également ces articles :
- CISA Lance le Programme de Sécurité Post-Quantique : Protéger l'Internet de Demain
- Zero Trust Architecture : NIST 2.0 et Implémentation Pratique 2025
- 1Password Passkeys : Support Universel et Sync Cross-Platform
Conclusion
La cryptographie post-quantique n'est plus une option : avec la menace "Store Now, Decrypt Later" et les progrès des ordinateurs quantiques, la migration doit commencer maintenant. Le NIST a fourni les standards, les outils existent, il ne reste qu'à exécuter.
Actions immédiates :
- Inventorier tous usages crypto (TLS, PKI, code signing)
- Déployer hybride sur systèmes Internet-facing (TLS)
- Planifier migration complète pour 2028-2030
Risque de ne rien faire :
- Données actuelles déchiffrables en 2030
- Non-conformité réglementaire (NIST devient standard)
- Perte de confiance clients
La course quantique est lancée. Êtes-vous prêts ?
