La nouvelle V2 du protocole de Session marque une avancée majeure pour l’appli de messagerie ultra confidentielle. Retour d’une vraie Perfect Forward Secrecy, ajout de briques de cryptographie post-quantique, et contrôle enfin sérieux des appareils liés, le tout sans sacrifier la simplicité d’usage. Dans cet article, il sera question de ce qui change concrètement entre la V1 et la V2, de la façon dont Session corrige ses vieux compromis techniques, et de ce que ces évolutions impliquent pour celles et ceux qui veulent un messager réellement privé sur le long terme.
De la V1 à la V2 : corriger un compromis douloureux
Historiquement, Session s’est distinguée par trois piliers : routage en oignon, architecture décentralisée et comptes sans numéro de téléphone. Cependant, la migration depuis le protocole Signal vers le protocole Session V1 avait laissé un angle mort gênant : l’abandon effectif de la Perfect Forward Secrecy (PFS), toutes les conversations étant chiffrées avec une seule clé de long terme (LTK) qui ne tournait pratiquement jamais. En pratique, si cette clé était compromise, l’attaquant pouvait, en théorie, remonter dans l’historique des messages et les déchiffrer un par un, ce qui va frontalement à l’encontre des attentes d’un public très soucieux de sécurité.
La V2 vient justement répondre à ce reproche central tout en conservant ce que la V1 avait apporté de positif. A savoir une gestion multi‑appareils fiable, une synchronisation robuste via la librairie de confiance libsodium et un système pour garder tous les clients alignés. Session a déjà souffert, à l’époque où le protocole Signal était encore utilisé, de messages impossibles à déchiffrer sur des appareils secondaires ou de conversations qui ne se synchronisaient pas correctement. Ce qui avait conduit à des frustrations répétées chez les utilisateurs avancés. L’enjeu de la V2 consiste donc à réintroduire la PFS sans réactiver ces anciennes misères, grâce à une architecture plus mûre, pensée dès le départ pour le multi‑device.
Perfect Forward Secrecy repensée pour le multi‑device
La pierre angulaire de Session V2, c’est le retour d’une vraie Perfect Forward Secrecy, mais sur une base de clés par appareil plutôt que sur une clé unique partagée par tous les clients. Concrètement, chaque device lié à un compte possède sa propre paire de clés et ces clés tournent régulièrement, de sorte que les anciennes soient supprimées après un délai défini. Si un appareil est compromis à un instant T, l’attaquant ne peut pas utiliser les clés présentes sur ce device pour remonter indéfiniment dans l’historique, car les clés plus anciennes ont déjà été effacées et ne sont plus disponibles nulle part.
L’autre différence fondamentale avec la V1 vient de la manière dont ces rotations de clés sont propagées entre appareils. Session exploite désormais libsodium comme colonne vertébrale pour diffuser les nouvelles informations cryptographiques à travers tous les devices liés, évitant les décalages qui provoquaient autrefois les fameux “failed to decrypt”. Là où la première tentative de PFS, héritée du Signal Protocol, peinait à vivre dans un environnement multi‑appareils, la V2 pose un modèle plus clair. Des clés distinctes par device, jamais partagées, combinées à un mécanisme de synchronisation déjà éprouvé dans l’infrastructure actuelle. Le résultat attendu, côté utilisateur, c’est un retour de la PFS sans renoncer au confort de pouvoir reprendre ses conversations indifféremment sur téléphone, laptop ou tablette.
Parer à l’avenir : cryptographie post‑quantique et long terme
L’autre grande nouveauté de Session V2 concerne la prise en compte explicite de la menace dite “store now, decrypt later”, dans laquelle un adversaire enregistre aujourd’hui des messages chiffrés pour les casser plus tard à l’aide d’outils quantiques. L’équipe de Session considère que ce scénario doit être traité dès maintenant, avant que l’attaque ne soit réaliste en pratique. Et cela en intégrant des briques de cryptographie post‑quantique (PQC) dans le protocole. L’objectif est de faire en sorte que même un attaquant disposant éventuellement, un jour, d’un ordinateur quantique puissant ne puisse pas revenir sur les anciennes conversations simplement en cassant les schémas classiques utilisés aujourd’hui.
Ce positionnement diffère de la V1, davantage centrée sur la simplification de l’architecture et la réduction de la complexité applicative, sans ambition explicite de se préparer à ces scénarios de long terme. Avec la V2, Session ne se contente donc pas de rehausser son niveau de sécurité actuel, elle tente de se donner plusieurs années d’avance sur une classe d’attaques qui menace toutes les messageries chiffrées. Pour l’utilisateur final, ce travail de fond est largement invisible dans l’interface, mais il vise à garantir que les messages envoyés aujourd’hui restent protégés demain, même si le paysage cryptographique change profondément.
Gestion des appareils : visibilité et réactions rapides en cas de fuite
La V2 utilise intelligemment ses nouvelles clés par appareil pour résoudre un autre point soulevé par la communauté : la visibilité sur les devices liés. Chaque appareil possède désormais une clé publique qui lui est propre, qui peut servir de base à un identifiant distinct visible dans l’interface. Ce qui permet à l’utilisateur de voir clairement quels appareils ont accès à ses messages. Cette granularité n’existait pas vraiment dans la V1, où tous les clients partageaient un modèle de clé plus monolithique, moins propice à une gestion fine des accès.
Surtout, la V2 prévoit un système de notifications lorsqu’un nouveau device est lié au compte, de manière à alerter immédiatement en cas de liaison non autorisée. Si un utilisateur constate la présence d’un appareil inconnu, il peut alors supprimer son compte et purger ses messages, puis repartir sur du matériel sain, ce qui offre une réponse claire à un scenario de compromission. Les fondations sont également posées pour une future fonctionnalité où les appareils déjà liés devront approuver explicitement l’ajout d’un nouvel appareil, transformant le parc de devices en véritable cercle de confiance plutôt qu’en simple liste technique. Là encore, par rapport à la V1, on passe d’une gestion implicite et assez opaque à un contrôle utilisateur qui donne des leviers concrets en cas de doute.
Une V2 en conception, mais un cap très net
Il est important de noter que le protocole Session V2 est encore en phase de design, avec des spécifications plus détaillées prévues pour 2026, afin de permettre des revues approfondies par la communauté sécurité. Néanmoins, les axes majeurs sont clairement définis : réintroduire une Perfect Forward Secrecy compatible multi‑device, intégrer la cryptographie post‑quantique, renforcer la gestion des appareils liés et s’appuyer sur les briques d’infrastructure déjà déployées (libsession, config messages …) pour garantir la stabilité de l’ensemble. L’approche consiste à capitaliser sur l’anonymat et la protection de métadonnées déjà bien en place (routage en oignon, réseau de nœuds décentralisé, stockage chiffré côté service) en ajoutant ces garanties cryptographiques supplémentaires.
Au final, la différence entre la V1 et la V2 ne se résume pas à une simple mise à jour cosmétique, mais à un repositionnement stratégique. Ne plus choisir entre confort multi‑device et PFS, ne plus se contenter de protections classiques face à un futur quantique incertain, et donner aux utilisateurs davantage de visibilité et de contrôle sur leurs appareils. Session se présente ainsi comme une messagerie prête pour les exigences de demain, tout en conservant l’expérience directe et sans friction qui avait séduit sa base d’utilisateurs.
