La sécurité est divisée en couches testables, limites documentées et preuves reproductibles.
Tests automatisés de cryptographie et du service de clés, 308 contre-tests associés, 19 exécutions dans de vrais navigateurs avec 189 vérifications, scénarios multi-appareils et de retour arrière, attribution des prékeys à usage unique et parcours contrôlé en production le 6 septembre 2026 ; réexécution le 9 septembre 2026.
Le composant post-quantique protège l’établissement de session, pas un ratchet continuellement post-quantique. Le déploiement reste dépendant de l’appareil et n’a pas encore fait l’objet d’un audit externe indépendant.
Logique de session et tests automatisés de réutilisation/révocation.
Un point d’extrémité déjà compromis et déverrouillé reste un risque distinct.
Pas de senderId dans les lignes de messages, un auteur signé dans le texte chiffré, des valeurs HMAC pour les chats directs, des marques de destinataire au lieu d’identifiants d’appareil dans les enveloppes de clés, memberRef pour les réactions, favoris et mentions, et un nouvel état de lecture sans nouvelles lignes d’accusé de réception. Dans l’état actuel du code et des tests, le chemin de démarrage à froid reconstruit l’annuaire des identifiants à partir de l’état de compte chiffré et ne considère pas un ensemble de preuves vide comme un succès. Les transferts d’historique y utilisent une seule marque de destination opaque calculée et ignorent les anciennes enveloppes non marquées au lieu de deviner leur destination.
Le service en fonctionnement a toujours besoin de métadonnées limitées sur les comptes, les relations et la technique pour l’autorisation et la distribution. L’environnement d’exécution signé en ligne n’a pas été mis à jour par cette tâche sur le site ; les nouvelles corrections du démarrage à froid et du transfert d’historique n’y s’appliqueront qu’après une livraison séparée de l’application et une migration. Les références historiques d’horaires/d’appareils et les registres de sécurité conservés restent visibles jusqu’à l’exécution de leur chemin de renouvellement ou de nettoyage défini. Minimiser les métadonnées ne signifie pas qu’elles sont absentes.
Chaque installation possède une identité cryptographique. Les clés de signature restent non exportables. Les clés d’échange sont de préférence conservées comme CryptoKey non exportables ; si iOS/WebKit ne peut pas les persister, le client utilise un repli JWK documenté puis remigre dès que possible.
Les jetons d’accès courts reposent sur des refresh tokens rotatifs. La réutilisation d’un ancien jeton bloque toute la famille de sessions.
Depuis le 6 septembre 2026, la voie contrôlée de version 3 combine X25519 et ML-KEM-1024 dans un établissement de session PQXDH hybride pour les appareils compatibles, puis poursuit la protection des messages avec Double Ratchet. Une protection par paire d’appareils empêche le downgrade silencieux ; les conversations comprenant des appareils non encore compatibles suivent une voie de compatibilité versionnée et documentée.
Les lignes de message ne stockent plus de senderId : l’auteur signé voyage dans le contenu chiffré. Les enveloppes de clés utilisent des marques opaques plutôt que l’identifiant de l’appareil ; réactions, favoris et mentions utilisent des références propres à la conversation, liées à des preuves de possession. Les noms et données de compte scellés réduisent encore le texte lisible. Le service actif requiert toujours des métadonnées limitées d’autorisation, de routage et de temps.
La version web est signée hors du serveur, reconstruite indépendamment et vérifiée par le service worker avant mise en cache.
Intégré dans un flux contrôlé et vérifiable.
Intégré dans un flux contrôlé et vérifiable.
Intégré dans un flux contrôlé et vérifiable.
Intégré dans un flux contrôlé et vérifiable.
Intégré dans un flux contrôlé et vérifiable.
Intégré dans un flux contrôlé et vérifiable.
“Un test vert ne vaut que la règle qu’il vérifie réellement.”
Principe de sécurité VENTEX
Les limites et travaux d’audit ouverts sont documentés.
