La bonne question n’est pas de savoir si le chiffrement paraît puissant, mais ce qu’il protège, qui détient les clés et quelles preuves étayent l’affirmation.
« Chiffrement de niveau militaire » ne fournit pas assez d’informations pour évaluer une application de messagerie. Cette expression ne précise pas qui détient les clés, quelles conversations sont protégées, si les sauvegardes exposent du texte en clair ni ce qui se passe lorsqu’un appareil est compromis.
La réponse utile n’est pas de rejeter le chiffrement. Elle consiste à remplacer une étiquette impressionnante par des affirmations précises et vérifiables.
AES-256 est un choix d’algorithme, pas un modèle de sécurité complet
AES est une norme publique, pas une technologie militaire secrète. La norme FIPS 197 du NIST spécifie AES-128, AES-192 et AES-256 ; le suffixe indique la longueur de la clé. La norme a fait l’objet d’une mise à jour rédactionnelle en 2023, sans modification de l’algorithme.
Un algorithme de chiffrement robuste peut néanmoins être utilisé dans un système qui donne au service accès au texte en clair. Demandez qui peut déchiffrer, pas seulement quelle est la longueur de la clé. Demandez aussi comment les clés sont générées et stockées, comment les identités sont authentifiées et quelles conditions d’échec conduisent l’application à s’arrêter plutôt qu’à continuer de manière non sécurisée.
Lorsqu’un fournisseur cite AES-GCM, il est plus précis qu’en mentionnant AES seul : GCM combine chiffrement et authentification. La gestion correcte des nonces, la vérification des étiquettes d’authentification et les autres exigences d’implémentation restent importantes. La spécification GCM du NIST est la référence technique ; un logo ne prouve pas qu’une application l’implémente correctement.
Quatre affirmations différentes que le marketing mélange souvent
| Affirmation | Ce qu’elle concerne | Ce qu’elle ne démontre pas |
|---|---|---|
| Chiffrement du transport | Protection sur une connexion, par exemple entre l’application et le serveur | Que le serveur ne peut pas lire le contenu |
| Chiffrement au repos | Protection des données stockées selon un modèle particulier de clés et d’accès | Que l’opérateur ne possède pas la clé de déchiffrement |
| Chiffrement de bout en bout | Protection du contenu entre des terminaux désignés | La sécurité d’un terminal compromis ou l’honnêteté d’un destinataire |
| Établissement de clés post-quantique | Résistance à des menaces quantiques spécifiées lors de l’établissement des clés | Un audit complet de l’application, l’anonymat ou une sécurité future garantie |
Le chiffrement du transport n’implique pas que toutes les bases de données du fournisseur stockent du texte en clair brut. Un service peut aussi chiffrer les données stockées. La distinction pertinente est de savoir si le fournisseur contrôle les clés ou dispose autrement d’un accès au contenu lisible. Soyez précis au lieu de remplacer un slogan par un autre.
Pour une introduction plus générale, consultez ce que protège le chiffrement de bout en bout.
« Utilise une norme du NIST » ne signifie pas « validé FIPS »
FIPS 203 définit ML-KEM, un mécanisme d’encapsulation de clés. Une messagerie peut déclarer utiliser cet algorithme sans que l’ensemble de l’application soit certifié ou ait fait l’objet d’un examen indépendant. Normes, tests d’algorithmes, validation de modules cryptographiques et audits de sécurité des produits constituent des formes de preuves différentes.
Le programme de validation des modules cryptographiques du NIST précise que l’implémentation de fonctions approuvées ne suffit pas à établir la validation d’un module selon FIPS 140. Si un produit annonce une validation, demandez le certificat, le module et sa version exacte, l’environnement d’exploitation et la configuration approuvée. Déterminez ensuite quelle partie du produit ce certificat couvre réellement.
C’est aussi pourquoi « sécurité de 256 bits » ne devrait pas servir de note globale pour une messagerie entière. La composition des protocoles, la gestion des clés et l’implémentation peuvent imposer des limites différentes.
L’authentification par mot de passe n’est pas le chiffrement des messages
Un mécanisme de connexion détermine si un utilisateur peut accéder à un compte. Le chiffrement de bout en bout détermine qui peut lire le contenu protégé des messages. Aucun des deux n’apporte automatiquement les propriétés de l’autre.
Par exemple, SRP est conçu pour authentifier sans transmettre le mot de passe lui-même. Cela ne signifie pas qu’une base d’authentification volée est sans danger. L’analyse de la sécurité de SRP dans la RFC 5054 explique qu’un vérificateur volé permet des attaques par essais de mots de passe et entraîne d’autres risques. Évitez de conclure : « Il n’y a pas de mots de passe à voler, donc une compromission du serveur ne peut pas avoir d’importance. »
En pratique, les lecteurs devraient poser des questions sur la récupération du compte, les sessions actives et le lien entre l’accès au compte et les clés de chiffrement. Une réponse qui se contente de répéter « connaissance nulle » laisse les questions importantes sans réponse.
Cinq questions pour évaluer la page de sécurité d’une messagerie
- Quels usages sont couverts ? Conversations individuelles, groupes, fichiers, appels, publications publiques et sauvegardes peuvent avoir des périmètres différents.
- Qui détient des clés utilisables ? Incluez les clés de récupération, les appareils liés et les modes de traitement côté serveur.
- Comment l’autre terminal est-il authentifié ? Recherchez une vérification des clés, des avertissements de changement pertinents et un modèle de confiance documenté.
- Quelles preuves existent ? Spécifications, compilations reproductibles, vecteurs de test et audits indépendants répondent à des questions différentes. Demandez la version et le périmètre de chacun.
- Qu’est-ce qui reste visible ou vulnérable ? Métadonnées, appareils compromis, messages copiés et contenu public ne doivent pas disparaître de l’explication.
Appliquez le même examen à Livara. Sa documentation de sécurité cite LVR1 et LGS1 et publie les limites opérationnelles. Considérez-les comme des affirmations du produit à évaluer, pas comme une certification indépendante. Le Proof Lab propose des démonstrations limitées et des vérifications d’artefacts, pas la preuve que chaque fonctionnalité ou version est sûre.
Comment lire un audit indépendant
Vérifiez la date, l’auditeur, la révision du code, les plateformes incluses et les composants exclus. Lisez les constats et l’état des corrections, pas seulement le badge de synthèse. L’audit d’une bibliothèque cryptographique ne couvre pas automatiquement la récupération de compte, l’application web, les notifications ou la sécurité opérationnelle.
L’absence d’audit est une lacune dans les éléments d’assurance, pas la preuve d’une vulnérabilité précise. Inversement, un audit n’est pas une garantie à vie. Une comparaison utile consigne les preuves et leurs limites au lieu de désigner un vainqueur universel « le plus sûr ».
Questions fréquentes
« De niveau militaire » est-il toujours un autre nom pour AES-256 ?
Non. Ne déduisez pas de cette expression un algorithme ou une certification spécifique. Demandez au fournisseur de préciser exactement ce qu’il entend par là.
Un chiffrement plus puissant bloque-t-il les captures d’écran ou les logiciels malveillants ?
Il n’empêche pas un destinataire de copier du contenu ni un appareil compromis d’exposer les données auxquelles il a accès. Il s’agit de menaces différentes.
Quel signe vaut mieux qu’un slogan de sécurité ?
Un périmètre clair, un protocole nommé, des limites explicites et des preuves examinables concernant l’implémentation distribuée. L’explication doit vous aider à décider à quoi faire confiance et ce qui reste à vérifier.
