Comment fonctionne vraiment la cryptographie à clé publique

Chaque fois que tu te connectes en SSH à un serveur ou que tu charges un site HTTPS, deux clés mathématiquement liées font le travail lourd. L'une est publique, l'autre est privée, et la relation entre elles est ce qui rend possible la communication sécurisée sur un réseau non fiable en premier lieu.

L'idée de base

Avec le chiffrement symétrique, une seule clé verrouille et déverrouille les données. Ça fonctionne bien si les deux parties partagent déjà un secret, mais distribuer ce secret en toute sécurité est la partie difficile. La cryptographie à clé publique (asymétrique) résout ce problème en générant une paire mathématiquement liée : une clé publique que tu distribues à quiconque, et une clé privée que tu ne partages jamais.

Les données chiffrées avec la clé publique ne peuvent être déchiffrées qu'avec la clé privée correspondante. Les données signées avec la clé privée peuvent être vérifiées par quiconque possède la clé publique. Ces deux propriétés couvrent presque tout ce pour quoi nous l'utilisons : la confidentialité et l'authentification.

RSA, l'exemple classique

RSA repose sur le fait que multiplier deux grands nombres premiers est rapide, mais factoriser le produit pour retrouver ces nombres premiers est brutal en termes de calcul à grande échelle. Une clé RSA de 2048 bits est construite à partir de deux nombres premiers d'environ 1024 bits chacun. La clé publique est (n, e) — n étant le produit des nombres premiers, e un exposant fixe comme 65537. La clé privée est dérivée en utilisant l'indicatrice d'Euler de n et implique de connaître les nombres premiers d'origine.

Le chiffrement est l'exponentiation modulaire : c = m^e mod n. Le déchiffrement l'inverse avec l'exposant privé d : m = c^d mod n. Personne ne chiffre vraiment directement de grands volumes de données avec RSA en pratique, cependant — c'est lent et a des limites de taille liées à la longueur de la clé. À la place, RSA enveloppe généralement une clé de session symétrique (AES-256, par exemple), et le cipher symétrique gère les données en volume. C'est l'approche hybride que TLS utilise.

La cryptographie sur courbes elliptiques et pourquoi elle prend le contrôle

ECC te donne une sécurité équivalente à RSA avec des clés beaucoup plus petites. Une clé ECC de 256 bits (comme secp256r1 ou Curve25519) est à peu près comparable en force à une clé RSA de 3072 bits. Des clés plus petites signifient des poignées de main plus rapides et moins de bande passante, c'est pourquoi les configurations TLS modernes, les implémentations SSH et le protocole Signal s'appuient sur ECC.

Les maths sont différentes — c'est basé sur le problème du logarithme discret sur des points sur une courbe elliptique plutôt que sur la factorisation d'entiers — mais la relation entre clé publique et clé privée et les garanties sont conceptuellement les mêmes.

Les signatures numériques : l'autre moitié de l'équation

Le chiffrement préserve la confidentialité des données. Les signatures prouvent l'authenticité et l'intégrité. Pour signer un message, tu le hashes (SHA-256, généralement) et chiffres ce hash avec ta clé privée. Quiconque possède ta clé publique peut hacher le message lui-même, déchiffrer ta signature, et vérifier que les deux hashes correspondent.

C'est exactement ce qui se passe quand tu exécutes git commit -S avec une clé GPG, ou quand une Autorité de certification signe un certificat TLS. La clé privée de l'AC signe ton certificat ; les navigateurs sont livrés avec la clé publique de l'AC pré-fiable, donc ils peuvent vérifier l'authenticité de ton certificat sans jamais parler directement à l'AC.

Où ça apparaît au quotidien

L'authentification par clé SSH est une application directe : ssh-keygen -t ed25519 génère une paire de clés, tu mets la moitié publique dans ~/.ssh/authorized_keys sur le serveur, et l'authentification se fait via un échange de défis utilisant la clé privée, aucun mot de passe jamais transmis.

Les poignées de main TLS utilisent la cryptographie asymétrique brièvement, juste pour établir une clé symétrique partagée (via l'échange de clés ECDHE dans les configurations modernes), puis passent au chiffrement symétrique rapide pour la session réelle. Le chiffrement email PGP/GPG suit aussi le modèle hybride — chiffre le message avec une clé AES aléatoire, puis chiffre cette clé AES avec la clé publique RSA ou ECC du destinataire.

Ce qui se casse réellement en pratique

Les maths derrière RSA et ECC n'ont pas été cassées par l'informatique classique. Ce qui va mal c'est presque toujours l'implémentation : la génération de nombres aléatoires faibles lors de la création de clés (le bug OpenSSL Debian de 2008 est le cas d'école), les nonces réutilisés dans les signatures ECDSA qui fuient les clés privées, ou les attaques par oracle de padding contre une RSA mal implémentée (l'attaque de Bleichenbacher contre le padding PKCS#1 v1.5). L'informatique quantique est la menace théorique à long terme — l'algorithme de Shor casserait à la fois RSA et ECC si un ordinateur quantique suffisamment puissant existait — c'est pourquoi le NIST a déjà standardisé des algorithmes post-quantiques comme ML-KEM (anciennement Kyber) pour la migration future.

Si tu veux aller plus loin avec ça, la cryptography track de Korra Studio couvre les protocoles d'échange de clés et les internals des fonctions de hash plus en profondeur, et les segments networking montrent comment tout ça s'intègre dans une vraie poignée de main TLS octet par octet.