Bases de la cryptographie à clé publique : le partage sécurisé

La cryptographie à clé publique — également appelée cryptographie asymétrique — utilise deux clés mathématiquement liées : une clé publique que vous pouvez distribuer librement et une clé privée que vous protégez. Chiffrez quelque chose avec ma clé publique, et seule ma clé privée peut le lire. Cela résout le plus vieux problème en cryptographie : comment deux inconnus qui ne se sont jamais rencontrés peuvent partager un secret sur un canal ouvert. Inventée par Diffie et Hellman en 1976 et rendue pratique par RSA un an plus tard, elle est aujourd'hui le fondement de TLS 1.3, Signal, SSH, la signature de code Ed25519, et tout service de transfert de fichiers qui authentifie les utilisateurs. Voici comment elle fonctionne réellement.

La trappe mathématique

Toute cryptographie à clé publique repose sur des fonctions "à trappe" — des calculs faciles à effectuer dans un sens mais effectivement impossibles à inverser sans information supplémentaire. Deux familles dominent :

• Factorisation entière (RSA) : multiplier deux grands nombres premiers est trivial ; factoriser leur produit est exponentiellement difficile. Une clé RSA de 2048 bits utilise deux nombres premiers d'environ 1024 bits. La meilleure attaque connue, le Crible de Corps de Nombres Général, nécessite environ 2^112 opérations — hors de portée.
• Logarithmes discrets sur courbes elliptiques (ECDH, ECDSA, Ed25519) : calculer la multiplication de points sur une courbe est rapide ; inverser pour trouver le multiplicateur est difficile. Les courbes de 256 bits comme Curve25519 donnent une sécurité équivalente à un RSA de 3072 bits.

Ces deux problèmes sont faciles pour les ordinateurs quantiques via l'algorithme de Shor, c'est pourquoi le NIST a standardisé des alternatives post-quantiques (ML-KEM et ML-DSA) dans les FIPS 203–205 en 2024.

RSA en pratique

Ron Rivest, Adi Shamir et Leonard Adleman ont publié RSA en 1977. Le schéma est élégant :

1. Choisir deux grands nombres premiers p et q.
2. Calculer n = p × q (le module) et φ(n) = (p-1)(q-1).
3. Choisir e premier avec φ(n), couramment 65537.
4. Calculer d tel que e × d ≡ 1 (mod φ(n)).
5. Clé publique : (n, e). Clé privée : (n, d).

Chiffrement : texte_chiffré = message^e mod n. Déchiffrement : message = texte_chiffré^d mod n. Le calcul fonctionne grâce au théorème d'Euler.

En pratique, RSA utilise le rembourrage OAEP (RFC 8017) pour prévenir les attaques par texte chiffré choisi. Le RSA "manuel" est catastrophiquement non sécurisé. RSA-2048 est le minimum actuel pour les nouveaux systèmes ; RSA-3072 ou 4096 pour tout ce qui doit durer longtemps.

Diffie-Hellman : des secrets partagés sans envoyer de clés

RSA vous permet de chiffrer pour un destinataire connu. Diffie-Hellman fait quelque chose de subtilement différent : il permet à deux parties de dériver un secret partagé sur un canal public, sans qu'aucune n'envoie le secret.

La version classique (DH sur des entiers modulo un grand nombre premier) :

1. Les deux parties conviennent d'un grand nombre premier p et d'un générateur g.
2. Alice choisit le secret a, envoie A = g^a mod p.
3. Bob choisit le secret b, envoie B = g^b mod p.
4. Alice calcule B^a mod p = g^(ab) mod p.
5. Bob calcule A^b mod p = g^(ab) mod p.

Les deux arrivent à g^ab mod p sans jamais avoir envoyé a ou b. Un observateur voit g, p, A, B mais calculer g^ab à partir de A et B nécessite de résoudre le problème du logarithme discret.

Le DH moderne utilise des courbes elliptiques (ECDH). X25519 est le choix standard : clés de 32 octets, secrets partagés de 32 octets, implémentation renforcée contre les attaques par timing.

Les courbes elliptiques et pourquoi elles ont dominé

RSA donne une impression d'ancienneté parce qu'il l'est en grande partie. La cryptographie sur courbes elliptiques l'a remplacé pour trois raisons pratiques :

• Clés plus petites. Une clé EC de 256 bits donne la sécurité d'une clé RSA de 3072 bits. Soit 32 octets contre 384 octets.
• Opérations plus rapides. ECDH sur Curve25519 prend environ 70 microsecondes sur un CPU moderne. La génération d'une clé RSA-3072 prend des secondes.
• Meilleure résilience à l'aléatoire. Ed25519 est déterministe — les signatures ne nécessitent pas de nonces aléatoires par message, évitant le désastre ECDSA de la PS3 de Sony en 2010 où un nonce constant a divulgué la clé maître.

Les courbes NIST (P-256, P-384, P-521) sont largement prises en charge mais historiquement méfiées par certains cryptographes en raison de constantes inexpliquées. Curve25519 et Ed25519, conçues par Daniel Bernstein, sont les valeurs par défaut modernes utilisées dans TLS 1.3, WireGuard, Signal et SSH.

Les signatures : prouver qui a envoyé quoi

La cryptographie à clé publique fait quelque chose que le symétrique ne peut pas : prouver l'auteur. La signature inverse les rôles de chiffrement — vous "chiffrez" (signez) avec votre clé privée, et quiconque possède votre clé publique peut "déchiffrer" (vérifier). Si la vérification réussit, vous deviez détenir la clé privée.

Les vraies signatures utilisent des fonctions de hash pour traiter des messages de taille arbitraire :

1. Calculer h = SHA-256(message).
2. Signer h avec la clé privée (RSA-PSS, ECDSA ou Ed25519).
3. Le vérificateur hache le message reçu, compare avec la signature via la clé publique.

Applications : certificats TLS (l'AC signe la clé publique du site), signature de code (notarisation Apple, Microsoft Authenticode), signature de commits Git, gestionnaires de paquets (apt, Homebrew, npm).

Où le transfert de fichiers utilise la cryptographie à clé publique

Pour les transferts anonymes basés sur lien (SwissTransfer, HexaTransfer), la cryptographie à clé publique n'apparaît souvent pas directement — une clé symétrique aléatoire dans le fragment d'URL gère tout. Mais pour les services basés sur compte, les clés publiques comptent :

• Authentification du serveur TLS 1.3. Chaque connexion HTTPS commence par le certificat du serveur, vérifié par rapport à une chaîne de CA. L'échange de clé ECDHE éphémère dérive ensuite la clé de session.
• Chiffrement de compte à compte. Tresorit, Proton Drive et Mega donnent chacun à leurs utilisateurs une paire de clés à l'inscription. Les fichiers partagés entre comptes sont encapsulés avec la clé publique du destinataire.
• Clients et mises à jour signés. Les applications de bureau vérifient les mises à jour avec des signatures Ed25519 ou RSA pour prévenir les attaques sur la chaîne d'approvisionnement.
• Authentification sans mot de passe. WebAuthn et les Passkeys utilisent des clés EC stockées dans du matériel sécurisé (Touch ID, Windows Hello, YubiKey).

La distribution des clés : le problème restant

La cryptographie à clé publique résout un problème de distribution des clés mais en crée un autre : comment savoir qu'une clé publique appartient vraiment à celui qu'elle prétend représenter ? Trois modèles :

• PKI (Infrastructure à clé publique). Les autorités de certification signent les clés publiques. Utilisé par TLS avec des racines dans Chrome, Firefox, Safari.
• Toile de confiance. L'approche de PGP — les utilisateurs signent mutuellement leurs clés. Flexible mais les problèmes de passage à l'échelle ont limité l'adoption.
• TOFU (Trust On First Use). L'approche de SSH — accepter la clé la première fois, avertir si elle change. Simple mais vulnérable à l'interception initiale.
• Transparence des clés. Des journaux Merkle-tree où toutes les clés publiques sont auditables publiquement. Utilisé par WhatsApp, iMessage Contact Key Verification et les systèmes de passkeys modernes.

Pour le transfert de fichiers avec des destinataires inconnus, le partage par fragment d'URL contourne entièrement cela — l'expéditeur remet la clé au destinataire directement via le lien, et l'authenticité dépend du canal utilisé pour partager ce lien.

Ce que l'informatique quantique change

Un ordinateur quantique à grande échelle exécutant l'algorithme de Shor brise à la fois RSA et la cryptographie sur courbes elliptiques. Les estimations actuelles placent l'échéance à 10–20 ans, mais le risque est immédiat pour les données à longue durée de vie : les attaques "collectez maintenant, déchiffrez plus tard" enregistrent le trafic chiffré aujourd'hui et le déchiffrent dans le futur.

Les normes post-quantiques NIST 2024 :

• FIPS 203 (ML-KEM) — remplace Diffie-Hellman / ECDH pour l'échange de clés. Basé sur des problèmes de réseaux euclidiens.
• FIPS 204 (ML-DSA) — remplace RSA/ECDSA pour les signatures.
• FIPS 205 (SLH-DSA) — signatures basées sur des fonctions de hash en complément.

Cloudflare et Google prennent désormais en charge ML-KEM dans l'échange de clés TLS 1.3. Les services de transfert de fichiers suivront dans les prochaines années. Le chiffrement symétrique (AES-256-GCM) est largement épargné — l'algorithme de Grover ne réduit sa force effective que de moitié.

Assembler le tout

Pour les partages sensibles aujourd'hui : TLS 1.3 avec échange de clés X25519 protège la connexion, AES-256-GCM gère le chiffrement massif, et pour les services basés sur compte, ECDH avec Curve25519 encapsule les clés par fichier. Les services basés sur lien évitent la couche compte mais gagnent en simplicité. Les deux modèles offrent une sécurité solide quand ils sont correctement implémentés.

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