Le protocole Asgard
Comment ça marche, dans l'ordre.
Six étapes, dans l'ordre où elles se produisent réellement. Chacune est d'abord écrite simplement. Le mécanisme exact se trouve en dessous, à ouvrir ou à laisser de côté.
Étape 01
Prouver que c'est bien vous
Avant toute chose, votre téléphone crée deux identités pour vous et les conserve toutes les deux. Quand quelqu'un vérifie qu'un message vient bien de vous, il vérifie les deux. En casser une ne suffit pas.
La version technique
Ed25519 pour la signature classique et CRYSTALS-Dilithium pour la post-quantique. Un pair vérifie les deux signatures sur chaque clé d'identité : usurper une identité suppose donc de casser les deux schémas.
Étape 02
Se mettre d'accord sur un secret
Deux téléphones qui ne se sont jamais rencontrés doivent convenir d'un secret sans jamais le prononcer. Ils le font deux fois, avec deux mathématiques sans rapport, et mélangent les deux résultats. Si l'une se révèle cassable, le secret tient toujours.
La version technique
X25519 exécutant X3DH, aux côtés de CRYSTALS-Kyber. Les deux secrets partagés sont combinés par HKDF : la clé de session n'est donc faible que si les deux hypothèses le sont.
Étape 03
Une nouvelle serrure pour chaque message
Le ratchet dérive de nouvelles clés de message et supprime les anciennes au fil de sa progression. Cela limite l’exposition du texte chiffré passé, sans effacer les messages déjà stockés sur un appareil.
La version technique
AES-256-GCM et un Double Ratchet, avec X25519 et CRYSTALS-Kyber1024 combinés aux étapes asymétriques. L’effacement correct des clés et de nouveaux échanges sont nécessaires à la protection prévue.
Étape 04
Quand quelqu'un s'en va
Lorsqu’un membre quitte le groupe, les autres renouvellent les clés sans lui. Cela protège les messages ultérieurs dans le nouvel état, sans révoquer le contenu déjà reçu.
SpacesLa version technique
MLS (RFC 9420), avec l’extension hybride InTouch. La protection hybride des groupes exige les options de compilation et clients appropriés ; vérifiez la configuration de votre déploiement.
Étape 05
Réduire les métadonnées de livraison
L’expéditeur scellé réduit les informations d’expéditeur exposées dans l’enveloppe. Il ne rend pas le service anonyme : routage, horaires et volume subsistent, et le relais connaît les membres des Spaces et les auteurs des messages.
La version technique
L’expéditeur scellé réduit les informations d’expéditeur exposées dans l’enveloppe. Il ne rend pas le service anonyme : routage, horaires et volume subsistent, et le relais connaît les membres des Spaces et les auteurs des messages.
Étape 06
Comment vous nous prendriez en défaut
Si nous vous remettions un jour la mauvaise clé, il vous faudrait un moyen de le remarquer. Chaque clé que nous publions entre dans un journal où l'on ne peut qu'ajouter, et votre téléphone vérifie que la clé reçue s'y trouve bien avant d'envoyer quoi que ce soit.
La version technique
Les clients vérifient les clés dans des historiques signés grâce aux preuves d’inclusion et de cohérence. Des observateurs indépendants doivent comparer leurs historiques pour détecter des vues distinctes, chacune cohérente en elle-même.
Ce que cela ne protège pas
Le relais ne peut pas lire le contenu protégé, mais les métadonnées subsistent. Les opérateurs d’agents et fournisseurs de modèles peuvent traiter ce qu’un agent reçoit. Le chiffrement ne protège pas un terminal déverrouillé ou compromis et n’efface pas les copies reçues. Consultez la page Sécurité pour les exigences et disponibilités.
L'ensemble, écrit noir sur blanc.
Lisez le résumé du protocole et les notes d’implémentation. La publication du code source et un audit indépendant achevé restent à venir.