Chiffrement de bout en bout, expliqué simplement

Le principe en une phrase

Le chiffrement de bout en bout garantit que seuls l'émetteur et le destinataire peuvent lire les messages. Ni le serveur qui les transporte, ni un fournisseur d'accès Internet, ni un éventuel pirate sur le réseau, ni même l'éditeur du service ne peuvent les déchiffrer. La clé qui sert à brouiller les données ne quitte jamais les appareils des deux interlocuteurs.

Comparaison avec HTTPS classique

Quand tu envoies un message WhatsApp, il fait deux trajets distincts : ton téléphone → serveur Meta → téléphone du destinataire. Si seul HTTPS était utilisé, le serveur déchiffrerait ton message à l'arrivée puis le re-chiffrerait pour le destinataire. Concrètement : Meta verrait le contenu en clair pendant un instant. Avec le chiffrement de bout en bout, ce n'est plus le cas : le message reste illisible pour le serveur, qui ne sert que de relais.

Métaphore : HTTPS, c'est envoyer une lettre dans une enveloppe qu'un employé de la poste ouvre, lit, puis remet dans une nouvelle enveloppe. E2EE, c'est utiliser un cadenas dont seul ton destinataire a la clé — l'employé voit le colis mais ne peut pas l'ouvrir.

Comment ça marche, concrètement

Le chiffrement repose sur deux ingrédients principaux : un algorithme qui transforme les données, et une clé qui pilote cette transformation. Sans la clé, l'algorithme produit du bruit incompréhensible.

AES-256 : l'algorithme de chiffrement

AES (Advanced Encryption Standard) est l'algorithme standard de chiffrement symétrique depuis 2001. Le suffixe 256 indique la longueur de la clé en bits. Pour comparer : la NSA elle-même utilise AES-256 pour ses documents classifiés Top Secret. Casser AES-256 par force brute exigerait plus d'énergie que celle disponible dans le système solaire entier — autrement dit, ce n'est pas l'attaque que tu auras à craindre.

Le mode GCM (Galois/Counter Mode) qu'on associe souvent à AES ajoute une vérification d'intégrité : si un attaquant modifie un seul bit du message chiffré, le destinataire le détecte au moment de déchiffrer. Sans GCM (ou équivalent), le chiffrement protège la confidentialité mais pas l'authenticité.

PBKDF2 : transformer un mot de passe en clé

Problème : AES-256 attend une clé de 256 bits parfaitement aléatoires. Un humain ne mémorise pas 256 bits aléatoires — il choisit un mot de passe court. C'est là qu'intervient PBKDF2 (Password-Based Key Derivation Function 2). Cette fonction prend ton mot de passe, le « malaxe » des centaines de milliers de fois avec une fonction de hachage cryptographique (SHA-256 par exemple), et en sort une clé pseudo-aléatoire de 256 bits.

Pourquoi répéter l'opération ? Pour ralentir un attaquant. Si quelqu'un tente de deviner ton mot de passe par force brute, chaque essai lui coûte le coût complet du PBKDF2 — quelques centaines de millisecondes. À 250 000 itérations, tester un milliard de mots de passe prendrait des décennies sur du matériel classique. C'est ce qu'on appelle un work factor.

L'échange de clés (Diffie-Hellman)

Reste le problème central : comment l'émetteur et le destinataire partagent la clé sans qu'un tiers ne l'intercepte ? Deux familles de solutions existent :

• Échange hors-bande — les deux personnes se mettent d'accord sur un code secret en personne, par téléphone, ou via un canal déjà sécurisé. C'est ce que fait Murmure : tu décides du code avec ton interlocuteur, chacun le tape, la clé est dérivée localement.
• Échange Diffie-Hellman — un protocole mathématique qui permet à deux parties de se mettre d'accord sur une clé secrète via un canal public, sans qu'un observateur passif ne puisse la deviner. C'est ce que font Signal, WhatsApp et iMessage à l'établissement de la conversation.

Forward Secrecy : la cerise sur le gâteau

Imagine que ton mot de passe fuite dans 10 ans. Avec une clé statique (comme dans Murmure), tout ton historique chiffré devient lisible. C'est gênant. La Forward Secrecy (PFS) résout ce problème : le protocole génère une nouvelle clé éphémère à chaque session — ou même à chaque message dans le cas du Double Ratchet de Signal. Compromettre la clé d'aujourd'hui ne donne aucune information sur les messages d'hier.

C'est une garantie forte mais qui complexifie sérieusement le protocole. Pour une messagerie ponctuelle, l'absence de PFS reste acceptable si tu changes le code régulièrement.

Les limites du E2EE

Le chiffrement de bout en bout protège le contenu des messages — pas les métadonnées. Le serveur sait toujours :

• Qui parle à qui (les identifiants de salon ou de compte)
• À quel moment (timestamps)
• Quelle taille font les messages (utile pour deviner le type : texte court vs image)
• Quel appareil et quelle IP se connectent

Pour cacher aussi les métadonnées, il faut combiner E2EE avec d'autres techniques : Sealed Sender chez Signal, onion routing chez Tor, mix networks. Un E2EE seul empêche de lire ce qui se dit, mais pas d'inférer un graphe social.

Autre limite — la plus importante : si le client lui-même est compromis (logiciel modifié, téléphone infiltré, application web servie par un serveur malveillant), le E2EE devient inutile. La clé est extraite avant ou après chiffrement. C'est pour cela qu'un audit du code client et la reproductibilité des builds sont essentiels pour les outils sérieux.

Comment Murmure applique ces principes

Murmure implémente une version minimaliste mais correcte de ces principes :

1. Tu choisis un code secret partagé avec ton interlocuteur (canal hors-bande).
2. Côté navigateur, PBKDF2-SHA256 avec 250 000 itérations dérive une clé AES-256 à partir du code.
3. Chaque message est chiffré en AES-256-GCM avec un nonce aléatoire de 96 bits (l'IV).
4. Seul le couple { iv, ct } chiffré transite par le serveur, qui ne peut pas le déchiffrer.
5. Une empreinte cryptographique (hash du code) s'affiche des deux côtés pour vérifier que vous avez bien la même clé.

Pas de Forward Secrecy, pas de Double Ratchet : Murmure mise sur la simplicité et la transparence. Le code est open source, lisible en quelques centaines de lignes.