Architectures matérielles & Cryptographie post-quantique

Architectures matérielles

Un algorithme quantique est abstrait, mais il doit s’exécuter sur un objet physique réel. Un qubit physique, c’est simplement un système quantique à deux états bien séparés que l’on sait préparer, manipuler et lire — et qui reste « cohérent » assez longtemps. « Cohérent » signifie qu’il garde son information quantique avant que le bruit de l’environnement ne la détruise (la décohérence, vue au jour 28).

Analogie .NET : vois un qubit physique comme une instance d’objet très instable. Tu peux l’initialiser, appeler des méthodes dessus (les portes) et lire sa valeur (la mesure) — mais un « ramasse-miettes » bruité menace de le corrompre à tout instant. Toute la difficulté du matériel, c’est de retarder cette corruption.

Les 3 métriques qui comptent vraiment

• Cohérence (T1 / T2) : combien de temps le qubit survit. Plus c’est long, plus on peut empiler de portes avant que l’état ne « pourrisse ».
• Connectivité : quels qubits peuvent interagir directement par une porte à 2 qubits. C’est un graphe de voisinage. Une faible connectivité oblige à « déplacer » l’information avec des portes SWAP.
• Fidélité des portes : la probabilité qu’une porte fasse exactement ce qu’on lui demande. 99,9 % paraît énorme, mais sur 1000 portes l’erreur s’accumule vite.

Les grandes familles de matériel

Aucune plateforme ne gagne sur tous les axes : c’est un compromis. Les supraconducteurs ont des portes ultra-rapides mais une cohérence courte et une connectivité limitée aux voisins. Les ions piégés offrent une connectivité « tous-à-tous » idéale et une cohérence longue, mais des portes environ 1000× plus lentes.

La connectivité, concrètement : pourquoi des SWAP apparaissent

Sur une machine à connectivité limitée, si ton circuit applique une porte à 2 qubits qui ne sont pas voisins, le compilateur (le transpiler) insère des portes SWAP pour les rapprocher. Chaque SWAP coûte 3 CNOT supplémentaires, donc plus de bruit. On peut l’observer en Qiskit :

# Qiskit — l'impact de la connectivité matérielle sur le circuit
from qiskit import QuantumCircuit, transpile

# On veut intriquer le qubit 0 avec le qubit 2
qc = QuantumCircuit(3)
qc.h(0)
qc.cx(0, 2)   # porte entre qubits NON voisins

# Machine en ligne : 0—1—2  (0 et 2 ne sont PAS connectés)
coupling_map = [[0, 1], [1, 2]]

t = transpile(qc, coupling_map=coupling_map, basis_gates=["cx", "h"])
# Le transpiler DOIT insérer des SWAP : 0 et 2 ne peuvent pas
# interagir directement → routage via le qubit 1.
print(t.count_ops())   # ex. {'cx': 4, 'h': 1} — des CNOT en plus !

Et côté Q# / .NET ?

Q# décrit l’algorithme indépendamment du matériel ; c’est le backend (Azure Quantum) qui cible une machine réelle. L’Adjoint/Controlled (vu au jour 34) reste portable ; les contraintes physiques (connectivité, jeu de portes natives) sont gérées à la compilation vers la cible.

// Q# — code agnostique du matériel : intrication de 2 qubits
operation EtatDeBell() : (Result, Result) {
    use (a, b) = (Qubit(), Qubit());
    H(a);            // superposition
    CNOT(a, b);      // intrication — la cible matérielle gère le routage
    let r = (M(a), M(b));
    ResetAll([a, b]);
    return r;
}

Piège fréquent : croire que « plus de qubits = meilleure machine ». Un processeur de 1000 qubits avec une fidélité de 99 % et une connectivité pauvre peut être moins utile qu’une machine de 50 qubits à 99,99 % et connectivité tous-à-tous. Le nombre de qubits seul ne dit rien sur ce qu’on peut réellement calculer.

Cryptographie post-quantique

La crypto d’aujourd’hui repose sur des problèmes mathématiques « durs » pour un ordinateur classique. Un ordinateur quantique tolérant aux fautes (jour 32) en casse une partie. Il faut distinguer deux mondes : l’asymétrique et le symétrique.

Qui casse quoi ?

• Shor (jour 21) résout la factorisation et le logarithme discret en temps polynomial. Cela casse toute la crypto asymétrique classique : RSA, Diffie-Hellman, courbes elliptiques (ECC). Augmenter la taille de clé n’aide pas — l’algorithme est polynomial.
• Grover (jour 19) ne donne qu’une accélération quadratique (√N) sur la recherche par force brute. Il **n’**annule pas la crypto symétrique : il divise par deux la sécurité effective. AES-128 tombe à ~64 bits effectifs. La parade : doubler la taille → AES-256.

Les standards NIST (2024)

La PQC, ce sont des algorithmes classiques (ils tournent sur ton CPU) mais fondés sur des problèmes que même un ordinateur quantique ne sait pas résoudre vite — surtout les réseaux euclidiens (lattices). Le NIST a standardisé en août 2024 :

• ML-KEM (FIPS 203, ex-Kyber) : un KEM — mécanisme d’établissement de clé. Remplace l’échange de clés (DH/RSA).
• ML-DSA (FIPS 204, ex-Dilithium) et SLH-DSA (FIPS 205, ex-SPHINCS+, fondé sur le hachage) : des schémas de signature numérique.

Distinction clé : un KEM sert à se mettre d’accord sur une clé secrète ; une signature sert à authentifier et prouver l’intégrité. On ne signe pas avec un KEM.

Côté code — .NET et Python

En .NET, Bouncy Castle implémente ML-KEM/ML-DSA ; OpenSSL 3.5 embarque ML-KEM. En Python, liboqs (via le binding oqs) est la référence pour expérimenter :

# Python (liboqs / oqs) — établissement de clé post-quantique
import oqs

# ML-KEM-768 : un KEM, PAS une signature
with oqs.KeyEncapsulation("ML-KEM-768") as kem:
    public_key = kem.generate_keypair()          # côté destinataire
    # côté expéditeur : encapsule un secret avec la clé publique
    ciphertext, secret_envoye = kem.encap_secret(public_key)
    # côté destinataire : décapsule pour retrouver le MÊME secret
    secret_recu = kem.decap_secret(ciphertext)
    assert secret_envoye == secret_recu   # clé partagée établie

Piège « récolter maintenant, déchiffrer plus tard » : même si aucune machine ne casse RSA aujourd’hui, un attaquant peut enregistrer ton trafic chiffré dès maintenant et le déchiffrer dans 10 ans. Pour toute donnée à longue durée de confidentialité, la migration vers le PQC est urgente dès aujourd’hui — pas « quand le quantique arrivera ».