Pourquoi le choix du chiffrement est critique

Quand vous confiez des messages sensibles à un service en ligne, vous lui faites une confiance implicite : celle de ne pas pouvoir les lire. Mais cette confiance ne doit pas reposer sur une promesse commerciale — elle doit être garantie mathématiquement.

C'est le rôle du chiffrement. Et tous les algorithmes ne se valent pas.


Qu'est-ce que XChaCha20-Poly1305 ?

XChaCha20-Poly1305 est un algorithme de chiffrement authentifié (AEAD — Authenticated Encryption with Associated Data). Il combine deux composants :

  • XChaCha20 : un chiffrement de flux qui transforme vos données en texte illisible à l'aide d'une clé et d'un nonce unique.
  • Poly1305 : un code d'authentification de message (MAC) qui garantit l'intégrité des données — toute tentative de modification est immédiatement détectée.

Le préfixe X de XChaCha20 désigne une variante étendue de ChaCha20, avec un nonce de 192 bits au lieu de 96 bits. Cela élimine pratiquement tout risque de réutilisation de nonce — l'une des principales vulnérabilités des systèmes de chiffrement en pratique.


Pourquoi pas AES-GCM ?

AES-GCM est l'algorithme le plus répandu. Il est solide — mais il présente quelques caractéristiques qui ont orienté notre choix vers XChaCha20-Poly1305 :

Sensibilité à la réutilisation de nonce

Si un nonce (nombre aléatoire utilisé une seule fois) est réutilisé avec AES-GCM, la conséquence est catastrophique : la clé secrète peut être reconstituée. XChaCha20 avec ses nonces de 192 bits rend cette erreur quasi impossible en pratique.

Performance sans accélération matérielle

AES-GCM bénéficie d'accélérations matérielles (AES-NI) sur les processeurs modernes. Mais tous les environnements n'en disposent pas. XChaCha20-Poly1305 est conçu pour être rapide en logiciel pur, et offre des performances comparables ou supérieures sur des architectures sans AES-NI.

Résistance aux timing attacks

ChaCha20 est conçu pour fonctionner en temps constant, ce qui le rend plus résistant aux attaques par canaux auxiliaires (timing attacks). AES peut, dans certaines implémentations non matérielles, être vulnérable à ce type d'attaque.


Le chiffrement côté client : la différence essentielle

Utiliser XChaCha20-Poly1305 est une chose. Mais ce qui fait la vraie différence chez EchoPass, c'est où le chiffrement a lieu.

La plupart des services qui disent "chiffrer vos données" le font côté serveur : vos données arrivent en clair sur leurs serveurs, puis sont stockées chiffrées. Techniquement, ils ont accès à vos données non chiffrées.

Chez EchoPass, le chiffrement est entièrement côté client :

  1. Vous saisissez votre message dans le navigateur.
  2. Votre mot de passe est utilisé pour dériver une clé via Argon2id.
  3. La clé chiffre votre message avec XChaCha20-Poly1305 dans votre navigateur.
  4. Seul le texte chiffré est envoyé à nos serveurs.

Résultat : nous ne pouvons techniquement pas lire vos messages, même si nous le voulions, même en cas de requête judiciaire, même en cas de fuite de nos bases de données.


Argon2id : la dérivation de clé

La solidité du chiffrement dépend aussi de la qualité de la clé. Or, la clé est dérivée de votre mot de passe — qui peut être relativement court ou prévisible.

C'est là qu'intervient Argon2id, l'algorithme de dérivation de clé (KDF) champion de la Password Hashing Competition. Il est conçu pour rendre les attaques par force brute extrêmement coûteuses, même avec du matériel spécialisé (GPU, ASIC).

Argon2id combine les avantages de deux variantes :

  • Argon2i : résistant aux attaques par canaux auxiliaires
  • Argon2d : résistant aux attaques GPU par son utilisation intensive de mémoire

Ce que cela signifie pour vous

Concrètement, voici ce que cette architecture garantit :

  • Vos messages sont illisibles pour EchoPass à tout moment
  • Une fuite de notre base de données n'expose pas vos messages, seulement des données chiffrées
  • Un attaquant qui volerait votre mot de passe ne peut pas déchiffrer vos messages sans accès à vos données locales
  • Aucun gouvernement ni aucune injonction légale ne peut nous forcer à révéler vos messages

La sécurité n'est pas une promesse. C'est une architecture.