Définition (fiche de glossaire) : ChaCha20-Poly1305 est une construction de chiffrement authentifié avec données associées (AEAD) qui combine le chiffrement par flot ChaCha20 avec le code d'authentification de message Poly1305. Il chiffre le trafic avec une clé de 256 bits et attache une étiquette d'authentification de 128 bits afin que les destinataires puissent détecter toute altération dans la même opération cryptographique.
Lorsqu'une application VPN indique « ChaCha20-Poly1305 » à côté de WireGuard ou d'une suite de chiffrement TLS, elle nomme l'algorithme qui protège réellement les charges utiles des paquets après le handshake. Comprendre ce nom compte plus que mémoriser des slogans marketing : ChaCha20-Poly1305 n'est pas un protocole VPN à lui seul, et ce n'est pas un substitut plus faible à AES. C'est un chiffre AEAD moderne normalisé pour les protocoles IETF et largement déployé dans WireGuard, TLS, SSH et IPsec.
D'où vient le nom
Daniel J. Bernstein a conçu Poly1305 (2005) et ChaCha (2008) comme primitives logicielles à haute vitesse. L'IETF a ensuite normalisé une combinaison AEAD spécifique dans RFC 8439 (rendant obsolète la RFC 7539) : ChaCha20 produit un flux de clés combiné par XOR avec le texte en clair, et Poly1305 authentifie le texte chiffré ainsi que toute donnée associée. La construction allonge le texte chiffré d'une étiquette fixe de 16 octets.
Selon l' aperçu Wikipedia de ChaCha20-Poly1305, l'algorithme prend une clé de 256 bits et un nonce de 96 bits, reprend la structure chiffrer-puis-MAC familière d'AES-GCM, et est utilisé dans IPsec, SSH, TLS 1.2/1.3, DTLS et WireGuard. Cette ampleur explique pourquoi le même nom de chiffrement apparaît dans les clients VPN grand public et les passerelles d'entreprise.
Comment ChaCha20 chiffre
ChaCha20 est un chiffrement par flot. Il ne découpe pas les données en blocs de 128 bits comme le fait AES. Il développe plutôt une clé, un nonce et un compteur de blocs en blocs de flux de clés de 64 octets, en n'utilisant que l'addition, le XOR et la rotation de bits sur 20 tours. Le flux de clés est combiné par XOR avec le texte en clair pour produire le texte chiffré. Le déchiffrement consiste au même XOR avec le même flux de clés.
L'explication ChaCha20 de Proton résume l'intérêt pratique pour les utilisateurs de VPN : ChaCha20 est conçu pour rester rapide en logiciel ordinaire, ce qui aide les téléphones, les processeurs plus anciens et les appareils sans accélération matérielle AES. AES l'emporte souvent lorsque AES-NI ou les extensions cryptographiques ARM sont présentes ; ChaCha20 l'emporte souvent lorsque le chiffrement doit s'exécuter en logiciel pur, avec des propriétés de timing constantes.
Ce que Poly1305 apporte
Le chiffrement seul n'empêche pas un attaquant d'inverser des bits en transit. Poly1305 est un code d'authentification de message à usage unique qui produit une étiquette de 16 octets sur le texte chiffré (et les données associées). Dans la construction AEAD de la RFC 8439, le premier bloc ChaCha20 initialise une clé Poly1305 à usage unique ; les blocs suivants chiffrent la charge utile. Si la vérification de l'étiquette échoue, le paquet doit être écarté sans divulguer le texte en clair.
Ce modèle « chiffrer puis authentifier dans une seule API » est ce que signifie AEAD. AES-GCM accomplit le même travail avec des mécanismes internes différents. Les analystes en sécurité considèrent que ChaCha20-Poly1305 et AES-256-GCM correctement implémentés offrent une confidentialité et une intégrité équivalentes sous les hypothèses standard — à condition que les nonces ne se répètent jamais pour une clé donnée.
Pourquoi WireGuard et les piles mobiles s'y intéressent
La cryptographie publiée de WireGuard fixe le chiffrement de transport à ChaCha20-Poly1305. Il n'existe aucun commutateur utilisateur pour AES dans WireGuard classique. Ce choix maintient le protocole compact et auditable : un seul AEAD, une seule famille d'échange de clés, une surface de configuration minimale. OpenVPN et IKEv2/IPsec peuvent négocier plusieurs chiffrements, y compris ChaCha20-Poly1305 lorsque les bibliothèques et les pairs le prennent en charge, ce qui explique pourquoi le nom de l'algorithme apparaît aussi en dehors de WireGuard.
Sur les réseaux mobiles et les appareils à batterie limitée, les chiffrements adaptés au logiciel comptent. Des mesures TLS historiques citées dans l'annexe de performance du RFC 8439 ont montré que ChaCha20-Poly1305 surpassait AES-GCM sur les téléphones sans accélération AES, tandis qu'AES-GCM dominait sur les serveurs dotés d'AES-NI. En 2026, de nombreux téléphones disposent d'extensions cryptographiques, mais la conception adaptée au logiciel réduit encore le risque d'implémentation et maintient un débit prévisible sur des parcs hétérogènes.
ChaCha20 vs AES : les compromis qui comptent
- Type de chiffrement : ChaCha20 est un chiffrement par flot ; AES est un chiffrement par blocs généralement utilisé en mode GCM pour l'AEAD.
- Matériel : AES l'emporte généralement sur les processeurs dotés d'AES-NI / d'extensions cryptographiques ; ChaCha20 l'emporte généralement en logiciel pur.
- Canaux auxiliaires temporels : La conception add-rotate-XOR de ChaCha20 est largement considérée comme plus facile à implémenter sans écueils de timing de cache que certains chemins logiciels d'AES basés sur des tables.
- Discipline des nonces : GCM comme ChaCha20-Poly1305 échouent de façon catastrophique si une paire (clé, nonce) est réutilisée. Les protocoles doivent garantir l'unicité — WireGuard utilise des compteurs de paquets ; TLS dérive des clés et des nonces frais pour chaque enregistrement.
- Familiarité avec la conformité : Les listes de contrôle d'entreprise citent encore plus souvent AES-256 ; c'est une habitude institutionnelle, pas une preuve que ChaCha20-Poly1305 est plus faible lorsqu'il est normalisé et utilisé correctement.
Ce que ChaCha20-Poly1305 n'est pas
Ce n'est pas un protocole VPN. Il ne remplace pas WireGuard, OpenVPN ou IKEv2. Il ne dissimule pas que vous utilisez un VPN, ne choisit pas les pays de sortie et n'applique pas une politique no-logs. Ce sont des problèmes de transport, de routage et de confiance envers l'opérateur. ChaCha20-Poly1305 ne répond qu'à ceci : une fois que les pairs partagent une clé de session, comment les paquets sont-ils scellés pour que les intercepteurs ne puissent ni les lire ni les modifier silencieusement ?
Ce n'est pas non plus « à l'épreuve du quantique ». Comme AES-256-GCM, c'est un chiffrement symétrique ; la préoccupation habituelle harvest-now-decrypt-later pour les VPN porte sur l'échange de clés du handshake (ECDH aujourd'hui, déploiements hybrides ML-KEM émergents), et non sur le retrait soudain de ChaCha20 lui-même. Traitez les allégations de VPN post-quantique comme des propos sur les handshakes et l'authentification, et non sur le remplacement de ChaCha20 par un autre chiffrement de masse.
Liste de contrôle pratique pour les lecteurs
- Si votre client affiche WireGuard, attendez-vous à ChaCha20-Poly1305 sur le canal de données, par conception.
- Si votre client affiche OpenVPN ou IKEv2, confirmez le chiffrement négocié dans les journaux ou les paramètres avancés ; ChaCha20-Poly1305 peut être disponible aux côtés d'AES-GCM.
- Ne courez pas après les adjectifs « de grade militaire ». Préférez les suites AEAD documentées issues des RFC actuelles et des clients maintenus.
- Rappelez-vous qu'un AEAD robuste ne peut pas corriger un mot de passe réutilisé, une page d'hameçonnage ou une fuite DNS hors du tunnel.
En bref : ChaCha20-Poly1305 est le cheval de bataille AEAD derrière une grande partie du trafic VPN et HTTPS actuel. Apprenez la définition, connaissez la règle du nonce, et traitez le choix du protocole et la politique de l'opérateur comme des questions distinctes du nom du chiffrement de masse affiché à l'écran des paramètres.