Ces dernières années, on voit apparaître sur le marché de plus en plus de nouveaux services de messagerie électronique qui se distinguent en mettant l'accent sur Vie privée, chiffrement de bout en bout (de bout en bout) et, désormais, la résistance aux attaques quantiques. C'est une bonne nouvelle pour les utilisateurs : une concurrence accrue signifie un choix plus large et une pression sur les acteurs établis. Mais parallèlement, le nombre de décisions auxquelles le grand public est confronté sur la base d'affirmations qu'il ne peut pratiquement pas vérifier lui-même augmente. Des concepts tels que „ l'architecture à connaissance nulle (connaissance zéro) “, „ le chiffrement post-quantique “, „ ML-KEM-768 „ ou “ X3DH + Double Ratchet » fonctionnent à merveille en marketing précisément parce qu’ils ont une consonance très technique et crédible. Vérifier qu’ils reposent bien sur une cryptographie correctement mise en œuvre est toutefois une tâche réservée à ceux qui ont le temps de lire le code source et d’en comprendre les détails.
Ces derniers jours, une discussion a eu lieu sur Reddit qui illustre bien pourquoi cette question est avant tout pratique, et pas seulement théorique. Elle constitue un rappel utile, quelle que soit son issue concrète. Dans cet article, je m'en servirai comme cadre pour une réflexion plus générale sur la manière d'aborder les nouveaux services liés à la vie privée.
Ce qui s'est passé sur Reddit
La discussion portait sur le service AsterMail (Aster Privacy), un nouveau source ouverte d'e-mails chiffrés. Celui-ci se distingue notamment par la cryptographie post-quantique, plus précisément par la combinaison des algorithmes X3DH, Double Ratchet et ML-KEM-768 pour les communications entre les comptes AsterMail. Ce choix d'algorithmes s'inscrit dans la même tendance générale que celle suivie aujourd'hui par d'autres services de communication sécurisés : combiner la cryptographie classique avec des mécanismes post-quantiques. Cela ne signifie toutefois pas qu'AsterMail utilise la même architecture que Signal, Tuta ou Proton Mail — Signal utilise ses propres adaptations post-quantiques du protocole Signal, tandis que Tuta utilise son propre protocole hybride TutaCrypt s CRISTAUX-Cyber a Proton introduit des clés post-quantiques dans OpenPGP v6.
Le fil de discussion a été lancé par un utilisateur qui a publié une liste de failles critiques dans l'implémentation d'AsterMail. Ses affirmations étaient très précises sur le plan technique. Elles concernaient par exemple le fait que la génération des clés ML-KEM certes, mais l'algorithme n'est pas intégré à l'échange initial de clés (les clés privées sont jetées). L'auteur a ensuite décrit des problèmes liés à la vérification des signatures entrantes, ce qu'on appelle un comportement de type « fail-open » lors de l'utilisation du réseau Tor, le stockage du jeton de commutation, la clé pré-générée RSA-4096 et plusieurs autres failles dans le code.
Findley, l'un des fondateurs d'AsterMail, a rapidement répondu à ce message et a confirmé la grande majorité des failles signalées. Il a déclaré : „ La plupart de ces failles critiques sont avérées, et nous travaillons activement à leur correction. “ Il a expliqué que le code ML-KEM est présent dans l'application et que les clés sont générées, mais que les développeurs n'ont pas eu le temps de l'intégrer à l'échange de clés initial. La communication s'effectuait donc en réalité sur ECDH P-256 et Double Ratchet — il s'agit d'un algorithme classique, mais non post-quantique Sécurité. Il a également indiqué que les utilisateurs pour lesquels la mise à jour côté serveur était activée recevraient une invitation à changer leur mot de passe, et a promis de publier prochainement le calendrier des corrections sur le blog. Dans une mise à jour ultérieure, il a précisé que les problèmes critiques avaient déjà été corrigés et déployés en production.
Pourquoi j'aborde cette situation avec prudence
À première vue, cela ressemble à une histoire qui se termine bien : les résultats sont connus, l'opérateur a reconnu son erreur, a mis en place des corrections et tout continue comme avant. En réalité, cependant, deux complications méritent d'être soulignées.
Le premier problème réside dans le fait qu'aucune des deux parties n'est tout à fait indépendante. L'auteur de l'audit, qui a publié les conclusions, a lui-même admis être le fondateur d'un service concurrent Secria. L'opérateur d'AsterMail est bien sûr également concerné, mais dans le sens inverse. Ce conflit d'intérêts ne discrédite pas en soi les conclusions : les erreurs techniques dans le code existent ou n'existent pas, peu importe qui les signale. Cela signifie toutefois que le lecteur ne dispose pas d'un rapport rédigé par un auditeur indépendant. Il ne voit que les affirmations d'un auteur motivé et la réponse de l'opérateur, qui est certes inhabituellement directe, mais qui reste une communication de crise publique. C'est à un auditeur ayant un accès complet au code qu'il reviendrait d'évaluer laquelle de ces affirmations résisterait à une évaluation cryptographique indépendante, et une telle évaluation n'existe pas à l'heure actuelle.
Une deuxième complication réside dans le fait que ce genre de situation n'a rien d'exceptionnel. Au contraire, il s'agit là du cycle de vie tout à fait classique d'un jeune service axé sur la confidentialité. Une petite équipe, un marketing ambitieux, un code écrit plus vite qu’il n’est documenté, et les premiers regards extérieurs ne l’examinent en détail qu’au moment où l’application est déjà couramment utilisée par de vraies personnes. La question n’est donc pas tant de savoir si „ AsterMail fait quelque chose de mal “, mais plutôt „ pourquoi les utilisateurs se retrouvent-ils dans une situation où ils doivent régler ce genre de problèmes a posteriori “.
Leçon à retenir pour l'utilisateur lambda
Si vous vous intéressez aux services liés à la confidentialité — ce qui est généralement le cas des lecteurs de blogs comme celui-ci —, cet épisode met en lumière plusieurs points. Ils semblent aller de soi, mais on a tendance à les oublier dans la pratique.
Un audit indépendant revêt une importance capitale, mais il a lui aussi ses limites. Pour les services bien établis, on trouve plus souvent des contrôles de sécurité externes, des rapports publiés ou, à tout le moins, une procédure de réponse aux failles décrite publiquement — Proton, par exemple, publie des audits réalisés par des sociétés telles que Cure53 ou Securitum. Un audit n’est pas une garantie d’absence de faille ; c’est la garantie qu’une partie spécifique du système a été examinée à un moment donné par un tiers qui met sa réputation en jeu. Dans le cas d'un service récent, le lecteur ne dispose pas de ce niveau de certitude et doit en tenir compte. Pas nécessairement pour rejeter le service, mais pour modérer ses attentes.
Le fait qu'un code soit open source ne signifie pas automatiquement qu'il est sûr. L'open source est une condition indispensable pour qu'un contrôle indépendant puisse avoir lieu. Mais ce n'est pas une condition suffisante. Le code peut être public tout en étant truffé de failles critiques que personne ne découvrira tant qu'on ne se mettra pas à les rechercher de manière ciblée. AsterMail fonctionne sous licence AGPL v3 et c'est précisément grâce au dépôt public que l'auteur de l'audit a pu trouver les erreurs. Si quelqu'un ne s'était penché sur le code qu'un mois plus tard, les problèmes y seraient restés pendant tout ce mois.
En matière de discours marketing, faites la distinction entre les promesses et la réalité. Si un service met en avant un algorithme spécifique (par exemple ML-KEM-768), cela ne signifie pas automatiquement qu'il est pleinement intégré au code de production à ce moment-là. Sans accès au code source, vous ne pouvez pas le vérifier en tant qu'utilisateur. Il vaut donc mieux soit attendre un audit indépendant, soit considérer les promesses techniques spécifiques comme des déclarations jusqu'à ce qu'une partie indépendante confirme leur véracité.
Les procédures de réinitialisation de compte ont un coût. La récupération d'accès est un compromis entre l'ergonomie et le modèle de sécurité : plus il est facile de redonner à l'utilisateur l'accès à ses anciens e-mails après la perte de son mot de passe, plus il est important de savoir comment les clés de chiffrement sont rendues à nouveau accessibles et qui a accès au matériel de récupération. Ce n'est pas nécessairement une mauvaise chose — tout dépend de la conception du système — mais c'est un point qu'il vaut la peine de vérifier explicitement dans la documentation de chaque service chiffré.
Enfin, une communication honnête de la part de l'exploitant ne remplace pas une vérification technique. La réponse de Findley est d'une franchise inhabituelle sur le plan de la communication : face à des conclusions embarrassantes, de nombreux opérateurs auraient préféré rester évasifs ou s'en prendre à l'auteur de l'audit, ce qui mérite d'être salué. Cela dit, il faut reconnaître que „ l'opérateur a déclaré que le problème était résolu “ n'est pas tout à fait la même chose que „ un audit indépendant a confirmé que le problème était résolu “. Pour décider à qui confier des messages sensibles, ce deuxième type d'affirmation joue un rôle plus important.
Course de fond
Le marché des messageries électroniques cryptées est aujourd'hui bien plus diversifié qu'il ne l'était il y a cinq ans. C'est une bonne chose. Mais cela a pour conséquence que le choix du fournisseur auquel confier ses communications sensibles est un peu plus compliqué, car les nouveaux acteurs ne disposent pas de ce que les acteurs établis ont à leur actif : des années de contrôles externes, des audits répétés et des incidents avérés pour lesquels on connaît la marche à suivre.
Il n'est donc pas judicieux de considérer l'affaire AsterMail ni comme un scandale retentissant, ni comme un modèle de transparence. Ces deux interprétations seraient prématurées et ignoreraient le fait que, pour l'instant, les seules sources d'information disponibles sont les déclarations des deux parties concernées. Ce qui ressort de cette discussion est quelque chose de plus général et, à mon avis, de plus utile : pour un nouveau service dédié à la protection de la vie privée qui n’a pas encore fait l’objet d’un audit indépendant, il vaut mieux attendre. Ne pas rejeter, ne pas condamner, simplement attendre — jusqu’à ce que ce service soit évalué par quelqu’un dont la réputation ne dépend pas de l’issue de cette évaluation.
La vie privée est un exercice de longue haleine. La patience y est souvent une vertu plus importante que l'enthousiasme.
Les informations contenues dans cet article s'appuient sur des discussions accessibles au public sur le réseau social Reddit et sur des documents publics fournis par les opérateurs des services mentionnés, à la date de publication, le 8 mai 2026. Cet article ne propose pas d'évaluation technique indépendante des constatations décrites et ne vérifie pas la véracité des déclarations des différentes parties au-delà de leurs propres affirmations. Nous vous recommandons de vérifier la situation actuelle directement auprès des opérateurs des services concernés.
Čeština
English
Deutsch
Español
Français