Skip to content

The document

The protocol, written down.

A summary of the Asgard Protocol: the four layers, the primitives each one uses, and the standards they come from. It is written to be checked. Where something is specified and has not been built yet, the page says so.

Protocol
Asgard
Group extensions
intouch_hybrid_v1
Standards basis
CRYSTALS round 3 · RFC 9420
Protocol composition
Asgard hybrid profile

Four layers, and every one of them hybrid

Asgard combines classical and post-quantum primitives for identities, sessions, ratchets and groups. The group extension requires the relevant build features. Published primitives do not replace an independent review of their composition.

  1. 01

    Identity

    Ed25519 + CRYSTALS-Dilithium

    Identity material combines Ed25519 and CRYSTALS-Dilithium5. Private signing keys belong to participant endpoints. Verify which signature checks the released client and deployment enforce.

  2. 02

    Session

    Hybrid X3DH · X25519 + CRYSTALS-Kyber1024 · HKDF

    A hybrid session combines X25519 key exchanges and CRYSTALS-Kyber1024 encapsulation through HKDF. The recipient publishes public pre-key material so a sender can start a session while they are offline.

  3. 03

    Message

    Double Ratchet · new root = HKDF(DH_ratchet ‖ KEM_ratchet)

    AES-256-GCM and a Double Ratchet, with X25519 and CRYSTALS-Kyber1024 combined at asymmetric ratchet steps. Correct key erasure and fresh exchanges are required for the intended protection.

  4. 04

    Groups

    MLS (RFC 9420) + intouch_hybrid_v1

    MLS (RFC 9420), with the InTouch hybrid extension. Hybrid group protection requires the relevant build features and client support; verify the configuration of your deployment.

Published primitives, an InTouch composition

Asgard uses the published primitives below with an InTouch hybrid composition. Its CRYSTALS round-3 encodings are distinct from final ML-KEM and ML-DSA standards. This is not a claim of FIPS validation or independent audit.

Symmetric encryption
AlgorithmAES-256-GCM
StandardNIST
Strength256-bit
Key exchange
AlgorithmX25519
StandardRFC 7748
Strength~128-bit classical
Signatures
AlgorithmEd25519
StandardRFC 8032
Strength~128-bit classical
Post-quantum KEM
AlgorithmCRYSTALS-Kyber1024
StandardCRYSTALS round 3
StrengthNIST level 5
Post-quantum signatures
AlgorithmCRYSTALS-Dilithium5
StandardCRYSTALS round 3
StrengthNIST level 5
Key derivation
AlgorithmHKDF-SHA-512
StandardRFC 5869
Strength256-bit
Group protocol
AlgorithmMLS
StandardRFC 9420
Strength—

What the server holds

The relay handles encrypted content and public verification material. It also processes operational metadata, including Space membership and who posts. The lists distinguish that data from protected content and private keys.

Held

  • Account identifiers and public verification keys
  • Encrypted messages waiting for delivery
  • Space membership and who posts
  • Recipient routing, timing and traffic volume
  • Encrypted key backups where enabled

Out of reach

  • Protected message content
  • Encrypted message fields and values
  • Participants’ private decryption keys

What this does not protect

Protection depends on secure endpoints, correct build features and deployment settings. Authorised recipients and agents can retain what they receive. Metadata remains visible. The CRYSTALS round-3 algorithms are not the final FIPS-standardised ML-KEM and ML-DSA encodings; no certification or completed independent audit is claimed.

Contact discovery availability

A server-side blinded contact-discovery implementation has been confirmed in source review. Client integration and deployed availability remain unverified. Check the app version and Security page before relying on it.

What you can check today

Read the protocol summary, check the security status and compare important identities through a trusted channel.

  1. 01

    Read the security status

    Implementation evidence, deployment requirements and protections still awaiting independent verification.

  2. 02

    Watch the transparency log

    Clients check keys against signed log histories using inclusion and consistency proofs. Comparing histories between independent observers is needed to detect separate, internally consistent views of the log.

  3. 03

    Compare a safety number

    Compare safety numbers through an independent channel with someone whose identity you already know.

This is the shape of it, and not the whole of it.

Read the protocol summary and implementation notes. Public source publication and a completed independent audit are still pending.

The same thing in plain languageWhat a message can carry