Le chiffrement indique quelles clés ouvrent un message ; il faut vérifier séparément qui a reçu ces clés.
Non ; le chiffrement de bout en bout d’un groupe ne suffit pas à empêcher la présence d’un membre caché. La réponse à « Le serveur peut-il ajouter un membre au groupe ? » dépend des mécanismes d’adhésion et de vérification des membres, pas seulement du chiffrement des messages. Selon la documentation de Livara, LGS1 chiffre le contenu des groupes privés compatibles qui fonctionnent réellement en mode E2EE. La rotation des clés après un changement de membres vise à limiter l’accès futur et nécessite l’application des mises à jour des membres et des clés sur les appareils ; elle ne récupère pas les copies déjà reçues.
Points essentiels
- Le chiffrement de bout en bout vise la confidentialité des messages, mais la sécurité de la liste des membres nécessite un mécanisme distinct.
- Dans un groupe privé Livara compatible dont le statut E2EE est confirmé, LGS1 couvre les messages, modifications et clés des pièces jointes ; n’étendez pas cette affirmation aux anciens groupes incompatibles.
- Comparer Signal, WhatsApp, SimpleX et Element sur la seule étiquette « chiffré » ne suffit pas : les notifications de changement de membres, le rôle de l’administrateur et les méthodes de vérification d’identité comptent aussi.
- L’interface ne peut pas détecter en toutes circonstances un compte autorisé contrôlé par un attaquant ; les membres doivent vérifier les identités et changements sensibles par une voie indépendante.
- Proof Lab de Livara propose une démonstration locale de P-256, HKDF et AES-GCM ainsi que la vérification d’empreintes de fichiers ; ce n’est ni une implémentation complète ni un audit indépendant de LVR1/LGS1.
Le chiffrement des groupes empêche-t-il les membres cachés ?
Non, sauf si le protocole coordonne aussi l’état des adhésions entre les membres de manière cryptographique et vérifiable, en plus du contenu. Ici, un « membre caché » désigne un compte qui accède aux futurs messages alors que les membres humains n’ont pas remarqué son arrivée ou n’ont pas correctement reconnu son identité.
Le chiffrement de bout en bout signifie que seuls les appareils des participants devraient pouvoir lire le contenu ; mais ces appareils doivent également savoir à qui ils envoient les clés. Si le serveur peut modifier la liste des destinataires, le chiffrement peut fonctionner correctement tout en chiffrant aussi un message pour un membre indésirable. Pour distinguer contenu et métadonnées, consultez le guide sur le chiffrement de bout en bout et ses limites.
Une « attaque du serveur contre un groupe chiffré » n’implique donc pas nécessairement de casser AES ou de résoudre un problème mathématique. En contrôlant les adhésions, le serveur pourrait ajouter un compte valide aux destinataires futurs. L’historique des messages dont ce compte ne possédait pas les clés est une question distincte ; le risque principal est l’accès après l’arrivée.
Que savons-nous des adhésions aux groupes Livara ?
La documentation de sécurité de Livara distingue le contrôle des adhésions et des rôles par le serveur du chiffrement du contenu. C’est une frontière importante pour l’évaluation, mais elle ne prouve à elle seule ni une attaque pratique réussie ni une entrée totalement invisible. Une telle affirmation nécessite de tester le comportement du client, la distribution des clés, les notifications d’adhésion et les conditions d’attaque.
La bonne question est : les appareils valident-ils indépendamment les changements de liste, et qu’affiche-t-on à l’utilisateur avant d’envoyer une clé à un nouveau membre ? Cet article ne présente pas de résultats d’audit ou de test d’intrusion de Livara.
Comment la sécurité de la liste des membres diffère-t-elle entre cinq messageries ?
Les différences principales concernent l’autorité qui approuve les changements, la manière dont les membres en sont informés et leur capacité à vérifier indépendamment l’identité d’un nouveau compte. Le seul chiffrement de bout en bout ne répond pas entièrement à la question de la confiance dans le serveur.
| Messagerie | Contenu du groupe | Adhésions et confiance pratique | Conclusion prudente |
|---|---|---|---|
| Livara | Dans un groupe privé compatible avec E2EE, LGS1 couvre le texte, les modifications et les clés des pièces jointes. | Les clés des expéditeurs sont automatiquement régénérées et redistribuées lorsque les membres changent. | Selon la documentation produit, le contenu des groupes privés compatibles et les clés des médias sont protégés avant livraison ; vérifiez l’état du groupe concerné. |
| Signal | L’assistance Signal sur les groupes indique que le service n’enregistre pas les membres, le titre, l’image ni les attributs du groupe. | La même source indique que l’administrateur peut définir qui ajoute des membres et activer son approbation pour les liens de groupe ; les membres doivent toujours observer les changements. | La conception limite les connaissances du service, mais les utilisateurs doivent vérifier les changements de membres et l’identité des comptes. |
| La présentation du chiffrement WhatsApp indique que les messages personnels et de groupe sont chiffrés de bout en bout. | La ressource d’aide WhatsApp décrit le partage facultatif d’une partie de l’historique avec un nouveau membre et le pouvoir de l’administrateur de le restreindre. | Le contenu est chiffré, mais la validité des adhésions doit être évaluée à travers les contrôles administratifs et les notifications de l’application. | |
| SimpleX | La documentation des groupes SimpleX indique que chaque membre possède des connexions séparées avec les autres. | La spécification décrit les groupes comme un ensemble de connexions entre membres avec des rôles et des messages de changement d’adhésion ; cela n’exclut pas un administrateur humain. | L’absence d’identifiant global ne supprime pas tous les risques liés aux membres ou aux appareils compromis. |
| Element / Matrix | La spécification E2EE de Matrix définit l’événement m.room.encryption et les algorithmes de chiffrement des salons. |
La spécification des adhésions Matrix modélise l’adhésion par des événements m.room.member dans l’état du salon, distribué par les serveurs d’hébergement. |
Le chiffrement du salon et l’état des adhésions sont deux couches distinctes ; les membres doivent vérifier les appareils et les changements du salon. |
Ce tableau n’est pas un classement absolu. Chaque système a un modèle de menace différent ; l’application, l’appareil, l’administration et le comportement des membres peuvent modifier le résultat. Pour choisir concrètement, utilisez les 12 questions de la liste de contrôle d’une messagerie sûre avec la documentation officielle de chaque produit.
Comment comparer la confiance accordée au serveur ?
Ne réduisez pas la confiance à oui ou non ; demandez précisément ce que le serveur voit et peut modifier. Un serveur qui ne lit pas le texte peut néanmoins contrôler les horaires de communication, les membres du groupe ou la distribution des clés initiales.
Premièrement, isoler la confidentialité du contenu
Vérifiez exactement où sont chiffrés les messages, modifications, réactions, titres, pièces jointes et clés de pièces jointes. Selon Livara, LGS1 couvre le texte, les modifications et les clés de pièces jointes des groupes privés compatibles avec E2EE ; cette affirmation ne concerne pas les canaux.
Deuxièmement, identifier l’autorité d’adhésion
Déterminez qui peut inviter, qui approuve les demandes et comment le client affiche les changements. Si le serveur impose l’état du groupe, sa compromission doit figurer explicitement dans le modèle de menace.
Troisièmement, distinguer identité et appartenance
Un nom familier ne prouve pas qu’une clé appartient à cette personne. Dans Livara, le numéro de sécurité permet de comparer les empreintes de clés en dehors de l’application ; cet outil ne signifie pas à lui seul que toute la liste des membres a été vérifiée. N’attribuez également la transparence des clés à un produit que si elle est documentée.
Quatrièmement, séparer les preuves des affirmations
Documentation produit, rapport d’audit et test indépendant ne sont pas équivalents. Un rapport fiable doit préciser version, périmètre, constatations et corrections. Le nom d’un algorithme ou l’accord entre deux implémentations ne suffit pas à prouver la sécurité de la gestion des adhésions.
Comment vérifier les membres d’une discussion de groupe ?
Les membres doivent examiner immédiatement les changements de liste et vérifier les identités sensibles par un canal indépendant. Pour une conversation à haut risque, voir un nom, une photo ou un numéro de compte ne suffit pas : ces signes peuvent être erronés, recyclés ou contrôlés par un attaquant.
Dans Livara, deux personnes peuvent comparer leur numéro de sécurité en personne, lors d’un appel connu ou par une voie indépendante. Cela peut révéler un changement de clé inattendu ; une comparaison entre deux personnes ne couvre toutefois pas automatiquement tous les membres d’un grand groupe à la fois. Le guide de vérification des discussions par numéro de sécurité explique les étapes pratiques.
Pour les groupes sensibles, cette courte procédure est utile :
- Réservez autant que possible l’ajout de membres aux administrateurs.
- Examinez immédiatement chaque notification d’arrivée, de départ ou de changement de rôle.
- Vérifiez l’identité d’un nouveau membre en dehors de ce même groupe.
- Après un changement suspect, cessez d’envoyer des informations sensibles et créez un nouveau groupe avec des membres vérifiés.
- Examinez périodiquement les appareils et sessions liés à chaque compte.
Ces mesures réduisent le risque, mais ne corrigent pas une faille de l’architecture d’adhésion. Si le serveur ou le compte administrateur est compromis et que l’interface affiche mal les changements, l’utilisateur peut toujours ne pas remarquer une arrivée.
Questions fréquentes
Le serveur peut-il ajouter un membre sans casser le chiffrement ?
Oui, si l’architecture de la messagerie lui confie le contrôle de la liste. Il n’a alors pas besoin de casser le chiffrement : il peut ajouter un compte aux destinataires futurs pour que les clients chiffrent aussi pour ce compte. La possibilité et la manière de le faire dépendent du protocole d’adhésion de chaque produit.
Comment LGS1 fonctionne-t-il dans les groupes Livara ?
Selon la documentation, dans les groupes privés compatibles avec E2EE, LGS1 emploie une chaîne de clés et des signatures d’expéditeur pour protéger le contenu et les clés des pièces jointes. La limitation de l’accès futur après un départ dépend de l’application du changement d’adhésion et de la distribution de nouvelles clés. Proof Lab ne fournit que des démonstrations locales de quelques composants cryptographiques et des vérifications d’empreintes ; ce n’est ni une implémentation complète de LGS1, ni un audit du protocole, ni une preuve de sécurité de la gestion des membres.
Comparer les numéros de sécurité prouve-t-il l’arrivée d’un membre caché ?
Non. La comparaison vérifie l’identité des clés entre deux personnes par une voie indépendante et peut révéler un changement inattendu. Mais elle ne prouve pas qu’aucun autre membre n’a rejoint le groupe ; il faut aussi vérifier séparément la liste, les notifications d’adhésion et l’identité des comptes sensibles.
Quelle messagerie possède la liste de membres la plus sûre ?
Ces sources ne permettent pas de désigner un vainqueur absolu, car Signal, WhatsApp, SimpleX, Element et Livara ont des modèles d’adhésion et de menace différents. Le bon choix dépend de vos risques : vérifiez qui contrôle les adhésions, comment les changements sont annoncés et si les identités sont vérifiables indépendamment du serveur.



