The Asgard Protocol
How it works, in order.
Six steps, in the order they actually happen. Each one is written plainly first. The exact mechanism sits underneath it, and you can open it or leave it alone.
Step 01
Proving it is you
Before anything else your phone makes two identities for you and keeps both. When somebody checks that a message really came from you, they check both of them. Breaking one is not enough.
The technical version
Ed25519 for the classical signature and CRYSTALS-Dilithium for the post-quantum one. A peer verifies both signatures on every identity key, so forging an identity means breaking both schemes rather than either one.
Step 02
Agreeing on a secret
Two phones that have never met need to agree on a secret without ever saying it out loud. They do it twice over, using two unrelated pieces of mathematics, and mix the two results together. If one of them turns out to be breakable, the secret still holds.
The technical version
X25519 running X3DH, alongside CRYSTALS-Kyber. The two shared secrets are combined with HKDF, so the session key is only as weak as the stronger of the two assumptions.
Step 03
A new lock for every message
Every message gets a lock of its own. Once it has been sent, that lock is thrown away and the next one is made. Somebody who takes your phone tomorrow cannot open what you sent yesterday.
The technical version
AES-256-GCM under a Double Ratchet, with an CRYSTALS-Kyber encapsulation at every ratchet step rather than only at session setup. That gives forward secrecy and post-compromise security, and the per-step encapsulation is the line that separates this from PQXDH.
Step 04
When somebody leaves
In a group everybody holds a piece of the key. When somebody leaves, the remaining pieces change, and everything sent from that moment on is unreadable to them. It costs the same whether the group is five people or five hundred.
SpacesThe technical version
MLS as specified in RFC 9420, extended with the hybrid post-quantum profile intouch_hybrid_v1. Membership changes cost O(log N), and the tree heals itself after a compromise.
Step 05
Who talks to whom
Hiding what you wrote is the easy half. The list of who you wrote to is usually the more revealing one. Delivery here is attached to a temporary token instead of to your account, so that list is never ours to hold.
The technical version
Sealed sender. The sender identity is not attached to the envelope, and delivery uses a short-lived token issued to the recipient. The relay sees ciphertext and a token, and can tie neither of them to an account.
Step 06
How you would catch us
If we ever handed you the wrong key, you would need some way of noticing. Every key we publish goes into a log that can only be added to, and your phone checks that the key it was given really is in there before it sends anything.
The technical version
Mandatory Key Transparency. Keys are entered in an append-only Merkle log, and clients verify inclusion and consistency proofs against a signed tree head before sending. A substituted key breaks the proof for every observer, not only for the person targeted.
What this does not protect
Metadata is reduced and not eliminated: when a message was sent, and roughly how large it was, still exist. Private contact discovery is on the roadmap and has not shipped. And a compromised device is a compromised device — nothing on this page protects a conversation from somebody holding an unlocked phone.
The whole thing, written down.
Every step above is specified in full, including the hard parts and the unfinished ones. The library that implements it is open.