En bref

Un compte est une paire de clés. Ni numéro de téléphone, ni e-mail, ni nom obligatoire ; la découverte est désactivée par défaut. Une requête à l’opérateur télécom ne donne rien : il n’y a pas d’opérateur dans la chaîne.

gRPC bidirectionnel : sur iOS au-dessus de QUIC avec repli sur HTTP/2, sur Android au-dessus de HTTP/2 — un seul flux de longue durée, qui survit à un changement de réseau sans nouvel établissement de connexion (handshake).

Le post-quantique est déjà dans le protocole. ML-KEM-1024 est encapsulé dans la préclé Kyber du destinataire lors de l’établissement de la session (PQXDH) et entre dans sa clé initiale. Le premier message d’une conversation est lui aussi protégé, et sans la partie post-quantique la session n’est pas établie du tout. Cela protège ce qui est écrit dans les messages et les pièces jointes. L’identité de l’expéditeur d’un message est elle aussi masquée de façon post-quantique, de même que les appels lorsque les deux applications prennent en charge DTLS post-quantique. Restent classiques : les signatures du serveur (certificats d’expéditeur, journal de transparence des clés), la connexion de l’appareil et la récupération du compte ; les groupes n’existent pas encore — toutes les couches sont listées dans la spécification du protocole.

L’expéditeur n’est pas dans l’enveloppe. La protection de l’expéditeur* est inconditionnelle pour le trafic ordinaire. Pour la remise, le serveur dispose d’un identifiant de compte opaque**, d’une taille et d’une heure.

  • * La protection de l’expéditeur (sealed sender) — le message part sans indication de son auteur. Seul le destinataire peut la lever, le serveur ne le peut pas. Dans l’application, elle est toujours active (dans les paramètres de sécurité, « furtivité »), il n’y a rien à activer ou désactiver.
  • ** Un identifiant opaque est une chaîne qui ne dit rien de vous : un ensemble de caractères attribué à la création du compte.

Ce qui existe aujourd’hui

Pour l’instant, la messagerie existe comme un second canal de communication, en complément du canal principal. Les fonctionnalités sont minimales — conversations et appels en tête à tête. Pas de groupes, pas de canaux, pas de synchronisation entre appareils.

Architecture technique

En bref : les messages sont chiffrés sur votre appareil. Le serveur transporte du texte chiffré sans pouvoir le lire ; ci-dessous, les couches dont cela se compose.

Konstruct repose sur la conception du protocole Signal (X3DH + Double Ratchet), réécrite de zéro en Rust et complétée par un accord de clés post-quantique (ML-KEM-1024).

Konstruct utilise gRPC avec Protocol Buffers pour un cadrage binaire efficace et maintient ouvert un MessageStream bidirectionnel permanent pour la livraison en temps réel, sans polling requête/réponse. Le backend est découpé en services indépendants (identity, messaging, signaling, media) pour isoler les pannes. Sur iOS, le chemin de production est gRPC bidi sur QUIC avec repli automatique sur HTTP/2 ; Android fonctionne sur HTTP/2.

Pile cryptographique

  • X3DH + Double Ratchet (conception du protocole Signal) : chiffrement de bout en bout avec confidentialité persistante (forward secrecy) et sécurité après compromission (auto-réparation).
  • Accord de clés post-quantique (PQXDH) : à l’établissement de la session, l’initiateur encapsule un secret ML-KEM-1024 (NIST FIPS 203) dans la préclé Kyber du destinataire, et ce secret entre dans la clé initiale de la session avec les résultats X25519 — si bien qu’une session enregistrée ne peut pas être reconstituée en cassant X25519 seul. La protection post-quantique s’applique dès le tout premier message, et il n’existe aucune voie classique d’établissement de session. En plus de cela, chaque session entretient un ratchet ML-KEM-768 espacé — du matériel post-quantique frais est mélangé au fil de la conversation (tous les 16 changements de sens ou tous les 7 jours), et non une seule fois à l’établissement, et une clé post-quantique propre à chaque message en est dérivée.
  • Signatures : hybrides Ed25519 + ML-DSA-65 (Dilithium-3, NIST FIPS 204) sur chaque préclé post-quantique — les deux sont vérifiées : le client n’accepte pas une préclé sans les deux signatures. La clé hybride elle-même est garantie par une signature Ed25519 et épinglée au premier contact. La connexion de l’appareil, la récupération du compte et les certificats d’expéditeur émis par le serveur ne sont pour l’instant signés qu’avec Ed25519.
  • AEAD : ChaCha20-Poly1305 pour le chiffrement des messages. KDF : HKDF-SHA256 avec des étiquettes de séparation de domaines pour chaque section du protocole. PoW anti-spam : Argon2id.
  • Le serveur ne voit pas le contenu : les messages ne sont stockés que sous forme de texte chiffré, que le serveur ne peut pas déchiffrer. Des jetons Privacy Pass peuvent accompagner les envois scellés ; le contrôle de ces jetons côté serveur est encore en cours de déploiement.
  • Agilité cryptographique : le protocole porte une version de la suite d’algorithmes, de sorte qu’une nouvelle suite peut être introduite sans changer le format des messages. Les dernières migrations (PQXDH v2, ratchet suite 4) ont été des bascules brutales : les sessions sur l’ancienne suite sont rejetées et rouvertes à l’envoi suivant. Tant que nous sommes en alpha, nous choisissons cette voie plutôt qu’une longue compatibilité.

Couche de transport

  • MessageStream gRPC bidirectionnel sur QUIC — chemin de production sur iOS (construct-transport). Un seul flux durable transporte les heartbeats, les messages entrants et les accusés de réception sans handshake TCP à chaque événement, survit à un changement de réseau et bascule automatiquement sur gRPC au-dessus de HTTP/2 + TLS 1.3 lorsque QUIC est bloqué. Le chiffrement de bout en bout se situe au-dessus : le transport ne transporte que du texte chiffré scellé, donc en changer ne modifie en rien les garanties.
  • Résistance à la censure : lorsque la connexion TLS directe est bloquée, le client passe par une couche d’obfuscation — automatiquement et sans action de l’utilisateur. L’implémentation est ouverte, la conception est publique. Les détails opérationnels — quels transports sont actuellement opérationnels, quels points d’entrée existent et où ils se trouvent — ne sont pas publiés, et ni l’application ni ce site ne les affichent.

Ce que voit le serveur

Toute plateforme centralisée part d’un même postulat : « vous » êtes une ligne dans sa base de données. Un numéro de téléphone, un profil, un graphe de contacts qui lui appartient et qu’elle peut transmettre. Konstruct part de moins. Le serveur conserve un identifiant de compte, vos clés publiques et un jeton push. Du message lui-même, il ne voit qu’un identifiant opaque du destinataire, l’heure de livraison et la taille ; la protection de l’expéditeur (sealed sender) supprime l’identifiant de l’expéditeur, de sorte que seul le destinataire peut révéler qui a écrit. C’est exactement ce qu’il faut pour acheminer du texte chiffré.

Sans carnet d’adresses, pas de messages « à froid » : une conversation commence par un code QR ou un lien d’invitation — à usage unique et valable douze heures. La recherche par nom d’utilisateur existe, elle est facultative et désactivée tant que vous ne l’activez pas.

La cryptographie ne vous rend pas inobservable. La corrélation par l’heure et l’IP reste visible sur le réseau, et un adversaire disposant de ressources suffisantes agit à ce niveau-là, pas à celui-ci. Pour autant, aucun composant de notre système n’est conçu pour accumuler vos données.

Aucune télémétrie. Pas même « anonymisée ».

Konstruct ne collecte ni analytique, ni métriques d’usage, ni événements comportementaux, ni rapports de plantage, ni identifiants publicitaires. Il n’y a aucun SDK tiers — ni Firebase, ni Crashlytics, ni Sentry — pas plus que de demande ATT ou de SKAdNetwork. Les versions de production n’écrivent aucun journal. Il y a une chose que nous ne contrôlons pas : tant que la bêta est sur TestFlight, Apple nous transmet ses métriques de test standard — date d’installation, version du build, nombre de sessions et de plantages. Ce sont les métriques d’Apple, pas les nôtres, et elles cesseront avec la sortie sur l’App Store. Pour le routage, le serveur ne conserve qu’un petit ensemble fixe de métadonnées — destinataire, heure, taille, vos clés publiques, sur iOS un jeton push — et la protection de l’expéditeur retire aussi l’expéditeur lui-même de l’enveloppe. Ce que cela ne résout pas, la corrélation temporelle et par IP, nous l’avons décrit dans la Politique de confidentialité.

Fonctionnalités clés

  • Chiffrement de bout en bout par défaut — les serveurs ne voient que des données chiffrées.
  • Confidentialité persistante (forward secrecy) — les messages passés restent protégés même en cas de compromission des clés.
  • Protection anti-censure — activée par défaut. Tant que la connexion directe fonctionne, c’est elle qui est utilisée ; le basculement n’a lieu qu’en cas d’échec avéré.
  • Interface zen — pas de spam de notifications, pas de bruit social, seulement une communication paisible.
  • Accord de clés post-quantique — ML-KEM-1024 (Kyber-1024) est encapsulé dans la préclé Kyber du destinataire à l’établissement de la session (PQXDH) et entre dans la clé initiale ; sans lui, la session ne s’établit pas. Ensuite, chaque session continue de renouveler les clés au sein du Double Ratchet avec ML-KEM-768, et chaque message a sa propre clé post-quantique. Les signatures sont hybrides, Ed25519 + ML-DSA-65 (Dilithium-3) : chaque préclé post-quantique est signée par les deux, et une session n’est pas établie avec une préclé dépourvue de ces signatures.
  • Transport live moderne — MessageStream gRPC bidirectionnel sur QUIC (repli sur HTTP/2), contournement des blocages lorsque le chemin direct est fermé, P2P direct prévu lorsque les deux interlocuteurs sont en ligne.
  • Open source — clients, serveur et transport, sous licences à copyleft faible. Héberger son propre serveur figure sur la feuille de route : l’application ne peut pas encore être dirigée vers un serveur personnel.

Principes de conception

Deux positions sur lesquelles nous ne transigeons pas :

1. Il n’existe pas de porte dérobée sûre. Tout affaiblissement délibéré du chiffrement crée une brèche, et celui qui s’y engouffrera ne sera pas celui pour qui on l’a laissée.

2. La confidentialité par défaut. Elle doit fonctionner sans aucune action de l’utilisateur : c’est une propriété du protocole, pas un réglage.

Ce que nous ne ferons pas. Aucune porte dérobée, quel que soit le prétexte invoqué pour la réclamer. Aucun mécanisme d’engagement : ni fil infini, ni séries, ni appâts dans les notifications. Aucune revente de données : il n’y a rien à vendre, et pas de modèle publicitaire à nourrir.

Spécification et code source

Tout ce qui est décrit sur cette page est détaillé dans la spécification du protocole — le whitepaper. Elle est versionnée avec le code et ne contient que ce qui peut être vérifié sur l’implémentation de référence.

NB : il n’y a pas eu d’audit externe. Tout ce qui précède est notre propre lecture de notre propre code. Personne en dehors du projet ne l’a vérifié, et tant que ce sera le cas, considérez ces propriétés comme des affirmations que nous sommes prêts à défendre, et non comme les résultats d’une vérification.