Un test hors ligne doit produire un résultat précis ; un hachage ou une démonstration cryptographique ne constitue pas un audit complet du produit.
Un test hors ligne peut montrer qu’un calcul précis s’effectue sans réponse en direct du serveur. C’est utile, mais cela ne prouve pas la sécurité de toute la messagerie. Pour obtenir un résultat exploitable, notez exactement le fichier, la version, l’entrée et la sortie testés.
Le hachage d’un fichier, la signature d’une publication, les vecteurs de test, les compilations reproductibles et les audits de sécurité répondent à des questions différentes. Croiser les preuves est plus utile que transformer l’une d’elles en « label de sécurité totale ».
Que montre chaque preuve ?
| Preuve | Conclusion limitée et correcte | Ce qui n’est pas automatiquement prouvé |
|---|---|---|
| SHA-256 du fichier | Le fichier correspond à l’empreinte de référence | La source de référence est honnête ou le code est parfait |
| Signature APK | La signature est valide pour le paquet et associée à la clé de signature | Cette clé appartient à l’éditeur voulu, sauf vérification séparée |
| Vecteurs de test | Les cas couverts donnent la sortie attendue | Tous les états et erreurs du produit sont couverts |
| Compilation reproductible | Un code source et un environnement précis produisent une sortie identique | Le code source ne contient aucune vulnérabilité |
| Audit | Un périmètre et une version précis ont été examinés | Les modifications ultérieures et les composants hors périmètre ont aussi été approuvés |
La définition d’une compilation reproductible repose sur des entrées et un environnement précis. L’outil officiel Android apksigner vérifie les signatures APK ; ce n’est pas la même opération que calculer un hachage.
Quel est le périmètre actuel du Proof Lab de Livara ?
La page Proof Lab présente un outil local de hachage APK et des démonstrations d’opérations P-256, HKDF et AES-GCM, notamment la modification d’un bit pour observer l’échec de la vérification d’authenticité. La page indique explicitement que la combinaison complète LVR1/LGS1 sort du périmètre de ce banc d’essai.
Formulez donc la conclusion correcte ainsi : « Ce fichier correspondait à l’empreinte de référence » ou « Cette démonstration cryptographique a rejeté l’altération testée ». Ne dites pas : « L’ensemble du protocole hybride et toute la version installée ont été audités indépendamment ». Cet article ne rapporte pas de nouveau test pratique de cet outil.
Comment préparer un test hors ligne reproductible ?
- Définissez l’objectif. Voulez-vous vérifier l’identité d’un fichier ou le comportement d’une opération cryptographique ?
- Consignez la version et la source. Le nom de l’APK, le numéro de version, l’adresse de téléchargement et l’empreinte de cette publication doivent correspondre.
- Préparez l’outil et l’entrée à partir d’une source fiable. Se déconnecter ne rend pas fiable un code malveillant dès l’origine.
- Utilisez des données de test non sensibles. Une démonstration cryptographique ne nécessite ni messages privés ni secrets réels.
- Déconnectez-vous et répétez le test. Cette étape mesure la dépendance à une réponse en direct, pas la confiance dans le code téléchargé auparavant.
- Consignez les résultats et les erreurs. Ne remplacez pas des différences de version, échecs de chargement ou sorties non conformes par « réussi ».
Si l’empreinte diffère, arrêtez l’installation et vérifiez d’abord la version, le fichier et la source de référence. L’écart peut venir du choix d’une autre publication ; sans enquête, ne le qualifiez ni de logiciel malveillant certain ni d’écart certainement anodin.
Quelle différence entre vecteurs de test et certification officielle ?
Un vecteur de test définit l’entrée et la sortie attendue d’un comportement. Des collections telles que Wycheproof sont utiles pour tester les bibliothèques sur des cas liés à des attaques connues. Les réussir ne prouve pas la couverture des cas inconnus.
Le NIST CAVP prévoit une procédure de validation des algorithmes. Exécuter quelques vecteurs publics dans un navigateur n’équivaut pas à obtenir un certificat de validation ; utiliser un algorithme standard ne certifie pas non plus automatiquement un produit.
Que demander pour comparer les messageries ?
Pour Livara, Signal, WhatsApp, Session ou Element, posez les mêmes questions : quelle est la version exacte ? Quel fichier est officiel ? Comment la clé de signature ou l’empreinte de référence est-elle vérifiée ? Quels tests peut-on exécuter ? Quels codes et composants figuraient dans le rapport d’audit ?
Cet article n’est pas un classement de ces produits fondé sur des tests. L’absence d’un outil sur une seule page ne prouve pas l’absence de preuves de sécurité ; sa présence ne prouve pas non plus la supériorité du produit entier. Comparez la documentation officielle de cette version et un rapport reproductible.
Une fiche de résultats utile
Dans un court rapport, consignez l’objectif, la version, la source du fichier, le hachage, l’outil et sa version, l’état du réseau, l’entrée non sensible, la sortie attendue, la sortie observée et les limites. Si un autre test n’a pas été réalisé, indiquez « non testé ».
Vérifier la clé d’un contact est également une vérification distincte. Un outil local peut montrer une opération, mais ne vérifie pas à votre place l’identité de votre interlocuteur ni l’état de son téléphone. Lisez les limites de sécurité de Livara avec les résultats, au lieu de considérer une note parfaite dans un outil comme une garantie couvrant toutes ces limites.
