Chiffrement asymétrique : RSA, ECC

Le chiffrement asymétrique, ou chiffrement à clé publique, utilise une paire de clés liées mathématiquement : une clé publique, que tout le monde peut connaître, et une clé privée, que son propriétaire est seul à détenir. Ce que l'une fait, seule l'autre peut le défaire. Ce chapitre explique les deux usages de la paire (chiffrer et signer), déroule RSA et Diffie-Hellman avec de petits nombres, présente les courbes elliptiques et montre comment, en pratique, asymétrique et symétrique travaillent ensemble.

Clé publique et clé privée

Imagine une boîte aux lettres : n'importe qui peut y glisser une lettre par la fente, seul le propriétaire a la clé pour l'ouvrir. La fente, c'est la clé publique ; la clé de la boîte, c'est la clé privée. Deux propriétés rendent le système possible :

connaître la clé publique ne permet pas, en pratique, de calculer la clé privée ;
ce qui est chiffré avec la clé publique ne se déchiffre qu'avec la clé privée correspondante, et inversement pour la signature.

La clé publique se publie : dans un annuaire, sur un site web, dans un certificat, dans le fichier authorized_keys d'un serveur SSH. La clé privée ne quitte jamais son propriétaire : elle reste dans un fichier protégé par une phrase de passe, une carte à puce, une clé de sécurité USB, le TPM d'un PC ou le module matériel (HSM) d'une autorité de certification.

Deux usages : chiffrer pour quelqu'un, signer pour prouver

La même paire de clés sert à deux opérations qui se font dans des sens opposés. Les confondre est l'erreur la plus fréquente des copies.

Chiffrer avec la clé publique du destinataire ; signer avec sa propre clé privée

Opération	Qui l'effectue	Avec quelle clé	Qui peut défaire ou vérifier	Service rendu
Chiffrer un message pour Bob	N'importe qui (Alice)	La clé publique de Bob	Seulement Bob, avec sa clé privée	Confidentialité
Signer un document	Bob	Sa clé privée	N'importe qui, avec la clé publique de Bob	Intégrité, authenticité, non-répudiation

RSA pas à pas avec de petits nombres

RSA, publié en 1977 par Ron Rivest, Adi Shamir et Leonard Adleman, repose sur un constat d'arithmétique : multiplier deux grands nombres premiers est instantané, retrouver ces deux nombres à partir de leur produit est extrêmement long. Voici l'algorithme avec des nombres minuscules, pour comprendre le mécanisme ; les vraies clés utilisent des nombres de plus de 300 chiffres.

1. Choisir deux nombres premiers p = 13 et q = 19 (ils restent secrets).

2. Calculer le module n = p × q = 247. Il fait partie des deux clés.

3. Calculer l'indicatrice d'Euler φ(n) = (p − 1)(q − 1) = 12 × 18 = 216. Seul celui qui connaît p et q sait la calculer.

4. Choisir l'exposant public e, premier avec φ(n). Ici e = 5, car PGCD(5, 216) = 1 (en pratique, on prend presque toujours e = 65 537).

5. Calculer l'exposant privé d, inverse de e modulo φ(n) : e × d ≡ 1 [216]. L'algorithme d'Euclide donne 216 = 5 × 43 + 1, donc 1 = 216 − 5 × 43, et d ≡ −43 ≡ 173 [216]. Vérification : 5 × 173 = 865 = 4 × 216 + 1. C'est l'inverse modulaire du cours d'arithmétique.

Clé publique : (n, e) = (247, 5).
Clé privée : (n, d) = (247, 173).

Chiffrer un message m (un nombre plus petit que n) : c = mᵉ mod n. Pour m = 42, on calcule 42⁵ mod 247 par élévations au carré successives :

text

42² = 1 764      1 764 mod 247 = 35      (247 × 7 = 1 729)
42⁴ = 35² = 1 225   1 225 mod 247 = 237  (247 × 4 = 988)
42⁵ = 42⁴ × 42 ≡ 237 × 42 = 9 954   9 954 mod 247 = 74   (247 × 40 = 9 880)

Le chiffré est c = 74.

Déchiffrer : m = cᵈ mod n = 74¹⁷³ mod 247 = 42. Le calcul est long à la main, immédiat pour un ordinateur ; la propriété mathématique (le théorème d'Euler) garantit qu'on retombe toujours sur m.

Pour casser cette clé, un attaquant doit retrouver d à partir de (247, 5). Il lui suffit de factoriser 247 = 13 × 19, puis de refaire les étapes 3 à 5. Avec 247, c'est immédiat. Avec un module de 2 048 bits (617 chiffres décimaux), aucune méthode connue n'y parvient : le record public de factorisation d'un module RSA est de 829 bits (RSA-250, en 2020), au prix de milliers d'années de calcul cumulé.

Quelle taille de clé RSA en 2026 ? Le guide de l'ANSSI fixe la règle : un module d'au moins 2 048 bits, pour un usage qui ne dépasse pas la fin de l'année 2030, et recommande 3 072 bits même avant cette date. Une clé de 1 024 bits n'est plus acceptable.

Diffie-Hellman : se mettre d'accord sur un secret en public

En 1976, Whitfield Diffie et Martin Hellman publient une idée qui semblait impossible : deux personnes qui ne se sont jamais rencontrées peuvent convenir d'une clé secrète commune en n'échangeant que des messages publics. C'est l'échange de clés Diffie-Hellman (DH).

On fixe publiquement un grand nombre premier p et un générateur g. Avec de petits nombres, p = 23 et g = 5 :

Alice choisit un secret a = 4 et envoie A = gᵃ mod p = 5⁴ mod 23 = 625 mod 23 = 4.
Bob choisit un secret b = 3 et envoie B = gᵇ mod p = 5³ mod 23 = 125 mod 23 = 10.
Alice calcule Bᵃ mod p = 10⁴ mod 23 = 10 000 mod 23 = 18.
Bob calcule Aᵇ mod p = 4³ mod 23 = 64 mod 23 = 18.

Les deux obtiennent le même secret, 18, car (gᵇ)ᵃ = (gᵃ)ᵇ = gᵃᵇ. L'espion a vu passer p, g, A et B, mais pour calculer le secret il lui faudrait retrouver a à partir de A = gᵃ mod p : c'est le problème du logarithme discret, impossible à résoudre en pratique avec des nombres de 2 048 bits ou sur une courbe elliptique bien choisie.

Diffie-Hellman : deux calculs différents, le même secret, sans jamais l'envoyer

Diffie-Hellman a une faiblesse : il ne dit pas avec qui on échange. Un attaquant placé au milieu (man in the middle) peut mener un échange avec Alice en se faisant passer pour Bob, et un autre avec Bob en se faisant passer pour Alice, puis relayer et lire tout le trafic. La parade consiste à authentifier l'échange : en TLS, le serveur signe sa part de l'échange avec la clé privée de son certificat (chapitre 9).

Quand les secrets a et b sont tirés au hasard pour chaque connexion puis effacés, on parle de Diffie-Hellman éphémère (DHE, ou ECDHE sur courbe elliptique). Même si la clé privée du serveur est volée un jour, les anciennes conversations enregistrées restent indéchiffrables : c'est la confidentialité persistante (forward secrecy), obligatoire en TLS 1.3.

Les courbes elliptiques : mêmes services, clés plus courtes

La cryptographie sur courbes elliptiques (ECC) remplace les calculs modulo un grand nombre premier par des opérations sur les points d'une courbe. Elle offre la même sécurité avec des clés beaucoup plus courtes, donc des calculs plus rapides et des certificats plus légers. Les équivalences admises (NIST, publication SP 800-57) :

Niveau de sécurité	Symétrique	RSA ou DH classique	Courbe elliptique
112 bits	3DES (obsolète)	2 048 bits	224 bits
128 bits	AES-128	3 072 bits	256 bits (P-256, Curve25519)
192 bits	AES-192	7 680 bits	384 bits (P-384)
256 bits	AES-256	15 360 bits	512 bits et plus (P-521)

Les courbes que tu croiseras :

P-256 et P-384, normalisées par le NIST, très répandues dans les certificats web ;
Curve25519, conçue par Daniel J. Bernstein : X25519 pour l'échange de clés (le plus utilisé en TLS 1.3), Ed25519 pour les signatures (le type de clé SSH recommandé aujourd'hui).

Le guide de l'ANSSI exige un sous-groupe dont l'ordre est un nombre premier d'au moins 250 bits : P-256, P-384, Curve25519 et Brainpool P256r1 conviennent.

Le chiffrement hybride : le meilleur des deux mondes

Le chiffrement asymétrique est lent, des centaines à des milliers de fois plus que l'AES, et RSA ne chiffre directement qu'un message plus court que sa clé. On ne s'en sert donc jamais pour chiffrer un fichier ou un flux. Les protocoles combinent les deux familles :

on tire au hasard une clé de session symétrique (256 bits) ;
on chiffre les données avec cette clé, en AES-GCM ou ChaCha20-Poly1305 ;
on transmet la clé de session protégée par l'asymétrique : chiffrée avec la clé publique du destinataire (PGP, S/MIME), ou convenue par un échange Diffie-Hellman authentifié (TLS 1.3, SSH, WireGuard).

	Symétrique	Asymétrique
Clés	Une clé secrète partagée	Une paire : publique et privée
Vitesse	Très rapide	Lent
Usage	Chiffrer les données	Échanger les clés, signer
Nombre de clés pour n personnes	n(n − 1)/2	n paires
Exemples	AES, ChaCha20	RSA, ECDH (X25519), ECDSA, Ed25519

Générer et protéger une paire de clés

Avec OpenSSL, la commande genpkey génère une clé privée, et pkey -pubout en extrait la clé publique :

bash

# Paire RSA de 3 072 bits
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072 -out cle-privee.pem
openssl pkey -in cle-privee.pem -pubout -out cle-publique.pem

# Paire sur courbe elliptique P-256, ou Ed25519
openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out cle-ec.pem
openssl genpkey -algorithm ed25519 -out cle-ed25519.pem

Les fichiers commencent par -----BEGIN PRIVATE KEY----- et -----BEGIN PUBLIC KEY----- : c'est le format PEM, du Base64 entre deux lignes d'en-tête.

Pour SSH (administration des serveurs Debian, git push vers GitHub), on génère une paire Ed25519 protégée par une phrase de passe :

bash

ssh-keygen -t ed25519 -C "technicien@helianthe.lan"
# Crée ~/.ssh/id_ed25519 (privée, à protéger) et ~/.ssh/id_ed25519.pub (publique, à déposer)
ssh-copy-id -i ~/.ssh/id_ed25519.pub admin@srv-portail.helianthe.lan

La clé publique est ajoutée au fichier ~/.ssh/authorized_keys du serveur. À la connexion, le serveur envoie un défi que le client signe avec sa clé privée : le serveur vérifie la signature avec la clé publique, sans qu'aucun secret ne circule. Une fois les clés en place, on désactive l'authentification par mot de passe (PasswordAuthentication no dans /etc/ssh/sshd_config). Le cours Git et GitHub montre la même démarche pour GitHub.

Protéger la clé privée, c'est :

la chiffrer avec une phrase de passe (proposée par ssh-keygen, option -aes256 de openssl genpkey) ;
restreindre ses droits (chmod 600 sous Linux) ;
pour les clés les plus précieuses (autorité de certification, signature de code), la garder dans un matériel dont elle ne sort pas : carte à puce, clé FIDO2, TPM, HSM ;
la révoquer et la remplacer dès qu'elle est soupçonnée compromise (un portable volé, un départ).

À l'E7 : comment la notion est demandée

Justifier HTTPS. Un sujet SLAM de la session 2025 (cas Kirassur) fait justifier le choix de HTTPS pour une API dont la clé d'accès circule dans les adresses : expliquer l'événement redouté en HTTP (l'interception de la clé), puis comment HTTPS protège. La réponse attendue mobilise ce chapitre et le chapitre 9 : échange de clés authentifié par le certificat, puis chiffrement symétrique des échanges.
Transférer un fichier volumineux en toute confidentialité. Le sujet SLAM 2025 (cas Casterman) demande une solution pour transmettre un PDF de 2 Go à un imprimeur. SFTP avec authentification par clés SSH est une réponse solide (transférer un fichier sensible).
Dire quelle clé utiliser dans un schéma d'échange, et pourquoi la clé privée ne circule pas.

En SISR, l'asymétrique se retrouve dans l'administration à distance par clés SSH, l'authentification des VPN par certificats et l'autorité de certification interne. En SLAM, dans les jetons signés en RS256 ou ES256 (chapitre 7) et dans le déploiement par clé SSH.