Technical Whitepaper v1.0
We present AETHER, the communication fabric of the Genesis platform: an end-to-end encrypted transport for messages, files, and real-time calls between humans and their AI agents. AETHER is post-quantum on both axes: confidentiality uses a hybrid ML-KEM-1024 ⊗ X25519 key agreement, and authentication uses a hybrid Ed25519 ⊕ ML-DSA-87 signature. Beyond the initial handshake, AETHER runs a continuous post-quantum double ratchet that folds a fresh lattice secret into every message chain — not only the handshake. The relay is blind: it forwards opaque ciphertext and never holds a decryption key. This document specifies the protocol, states the exact primitives and parameters, and defines the trust boundary precisely. The relay is disposable by design: it holds no keys and no identity, so if you do not trust ours, you run your own — AETHER is federatable and the client is yours to inspect.
Keywords: Post-Quantum Cryptography, ML-KEM (FIPS 203), ML-DSA (FIPS 204), Double Ratchet, Forward Secrecy, Post-Compromise Security, Sealed Sender, Hybrid Cryptography, End-to-End Encryption, NIST ACVP
Two shifts make existing secure messaging insufficient for the Genesis thesis. First, the quantum transition: an adversary can record encrypted traffic today and decrypt it once a cryptographically-relevant quantum computer exists ("harvest now, decrypt later"). Regulators have responded — the EU's coordinated roadmap requires member states to begin the post-quantum transition by end of 2026 and secure critical systems by 2030; NIST deprecates classical asymmetric cryptography on a comparable timeline. Second, the agent shift: in Genesis, the participants are not only humans but their AI agents, which negotiate, delegate, and act across machines. A comms fabric for that world must authenticate agents as first-class, sovereign identities.
AETHER is designed against an adversary who can:
AETHER is not designed to defend a fully compromised endpoint (see §11). Security is defined at the boundary of a genuine, uncompromised client.
| Role | Primitive | Parameters / Standard |
|---|---|---|
| PQ key encapsulation | ML-KEM-1024 | NIST FIPS 203, security level 5 |
| Classical key agreement | X25519 | RFC 7748 |
| PQ signature | ML-DSA-87 | NIST FIPS 204, security level 5 |
| Classical signature | Ed25519 | RFC 8032 |
| Authenticated encryption | AES-256-GCM | quantum-resistant by nature (Grover leaves 128-bit) |
| Hash / KDF / XOF | SHA-3 / SHAKE / HKDF | FIPS 202 / RFC 5869 |
Every layer is quantum-resistant. The asymmetric layers — where a quantum computer would otherwise break RSA or elliptic curves — are hybrid: they combine a lattice primitive with a classical one so that the construction is no weaker than the stronger of the two. The symmetric layer, AES-256, was never quantum-broken: Grover's algorithm reduces its effective security to 128 bits, which remains infeasible. There is no quantum-vulnerable path through AETHER.
The ML-KEM-1024 and ML-DSA-87 implementations are written directly from the FIPS specifications, with no third-party cryptographic library in the trust core, and validated two ways: (1) byte-for-byte against NIST's ACVP test vectors, and (2) cross-checked against an independent reference implementation used only as an offline oracle. We state plainly what this validation means and does not mean in §10.
Post-quantum encryption is now shared by several systems (for example Signal's PQXDH and Apple's PQ3 both incorporate a lattice KEM); we do not claim it as unique. Post-quantum authentication is the rarer property: at the time of writing, Apple PQ3 and Signal both still sign with classical elliptic-curve signatures. AETHER signs identity with a hybrid that includes ML-DSA-87. On the authentication axis, AETHER is ahead of both. We deliberately avoid "only us" or "world's only" claims — other post-quantum-signature systems exist. The defensible position is: hybrid post-quantum on both axes, at NIST level 5, implemented sovereignly and validated against NIST vectors.
An AETHER identity is a keypair, not an account — there are no phone numbers, no email, no central user database. A user's Comm ID is derived from their Ed25519 public key; the identity additionally carries an X25519 key (for encryption) and an ML-DSA-87 key (for post-quantum signing), all bound together.
Public key bundles are self-authenticating: the bundle is signed such that the ML-DSA-87 public key is cryptographically bound to the Ed25519 identity the Comm ID derives from. On first contact a peer's post-quantum key is pinned (trust-on-first-use); on every later contact, key substitution, downgrade (a previously-PQ peer presenting only a classical bundle), and tampering are all rejected. An out-of-band safety number folds both the classical and post-quantum keys, so a manual verification covers the PQ key as well.
AETHER has two distinct handshakes, and conflating them is a common source of confusion.
When a client comes online it announces its Comm ID so the relay knows where to route. The relay holds no identity and no key material of its own — all identity, all key material, and all verification that protects a conversation live in the client (ARIA). The relay maps a Comm ID to a live connection and forwards sealed envelopes; it is a router, not a party to your cryptography. It does not need to vouch for identity, because every message is sealed end-to-end to the recipient's keys: a spoofed Comm ID at the router still cannot open a single byte.
When two parties first communicate, their clients exchange verified key bundles (§4) and establish a per-pair ratchet session. This handshake is end-to-end: the relay only forwards the sealed bytes and is never a cryptographic party to it. The shared root is derived from a hybrid ML-KEM-1024 ⊗ X25519 key agreement using a transcript-bound KDF (the standard NIST/IETF hybrid pattern, provably no weaker than the stronger input).
AETHER's session layer is the Signal Double Ratchet, made post-quantum. The root key is seeded by the hybrid handshake of §5.2. The continuous Diffie-Hellman ratchet — which provides forward secrecy (FS) and post-compromise security (PCS) — runs over X25519. On top of that, every ratchet step encapsulates a fresh ML-KEM-1024 secret to the peer and folds it into the root KDF, so each sending and receiving chain carries a fresh lattice contribution, not only the initial handshake. Per-message keys are derived from a one-way chain and deleted after use; out-of-order and lost messages are handled by bounded skipped-key storage.
To operate without a prekey server, the fresh ML-KEM encapsulation targets the peer's static ML-KEM key, and the ciphertext travels inside the message header. This design has two consequences we state openly. First, it sidesteps the state-desynchronization and prekey-exhaustion problems that make lattice KEMs awkward in asynchronous ratchets — the header is self-contained, decryptable in any order, and ML-KEM-1024's decryption-failure rate is cryptographically negligible. Second, because the encapsulation targets a static key, the post-quantum layer's independent forward secrecy is bounded by that static key; the rotating FS and PCS are provided by the X25519 ratchet. The net effect is strong hybrid protection — an attacker must defeat both the classical ratchet and the lattice layer — with the PQ contribution focused on defeating "harvest now, decrypt later." We consider a per-session ephemeral-PQ-key variant future work.
A double-ratchet decryption may need to advance root and chain state before the message's authenticity can be checked. Historically this ordering has produced desynchronization and denial-of-service bugs in real messaging protocols. AETHER makes decryption atomic: the full session state is snapshotted on entry and rolled back on any failure, so a forged or tampered packet — even one crafted to trigger a ratchet step — can neither desynchronize nor deny-of-service a session. State commits only when a message genuinely authenticates. This property is covered by a dedicated adversarial regression suite.
The relay's job is to forward a sealed envelope to a recipient's live connection, or to hold it briefly if the recipient is offline. It never opens the envelope body. Message content is end-to-end encrypted; the relay operator, the network, and Genesis itself cannot read it.
We are precise about metadata, because "the relay sees nothing" would be an overstatement. What the relay cannot see: message content, and — thanks to sealed-sender delivery — the sender's identity, which is authenticated inside the sealed payload rather than exposed to the hub. What the relay can observe, because it must route: the recipient's Comm ID, the source IP address, and the timing and size of traffic. And here is the sovereign answer: if routing metadata reaching a third-party relay is unacceptable for your threat model, do not use ours — run your own hub. AETHER is federatable and the relay is disposable; a hub you operate sees only what you allow it to. Metadata sovereignty is one deployment away, not a promise you have to take from us.
In a sovereign fabric the relay holds nothing durable, so the sender is the source of truth. Each message is retained by the sender until the recipient acknowledges it; retries fire on reconnect, on a periodic sweep, and the instant the relay signals that a previously-offline recipient has returned. A duplicate-suppression record ensures retries are processed once. The consequence is strong: even a total loss of relay state loses no messages, because delivery is reconstructed from the sender's device.
Group audio, video, and screenshare use a full-mesh WebRTC topology: each participant forms a direct peer-to-peer connection to every other, and media is encrypted end-to-end with DTLS-SRTP. No media server ever holds a frame of a call — there is no SFU or MXU that could decrypt media. Screenshare rides the same encrypted senders as an additional track. The mesh has an honest ceiling: because the number of connections grows as n(n-1)/2, group calls are capped at 8 participants; larger calls are a future direction requiring an end-to-end-encrypted selective-forwarding design.
We are equally precise about infrastructure. Peer-to-peer connectivity across NATs requires STUN/TURN servers for address discovery and, when direct connection fails, relaying. AETHER uses a self-hosted (sovereign) TURN relay with ephemeral, time-limited credentials. That relay forwards only encrypted DTLS-SRTP packets — it cannot decrypt media — but, like any TURN server, it does observe participant IP addresses. "No middleman" is therefore accurate for media content (no server sees a frame) and inaccurate as a claim of zero infrastructure (NAT traversal requires it). Current real-time calls are best-effort: a dropped peer connection is torn down, and automatic ICE-restart/reconnection is an area of active improvement; asynchronous messaging (§8), by contrast, is loss-proof.
A single default relay is a stateless router: it holds no identity and performs no cryptography on a user's behalf. Identity enters only at the operator level, and only when independent relays federate so organizations can run their own hub while staying reachable. For that hub-to-hub layer, each federated hub carries an operator identity (hybrid Ed25519 ⊕ ML-DSA-87) and peers authenticate one another with mutual post-quantum challenge-response and an explicit trust policy before accepting each other's routing claims. This is control-plane, operator-to-operator authentication — it never touches user keys or message content, which stay end-to-end sealed no matter how many hubs a message crosses. Multi-hop routing uses path-vector loop prevention with a hop limit, so data-plane loop-safety does not depend on the control plane; discovery does not imply trust.
Every protocol has a boundary. Here is AETHER's, stated exactly — so you can decide with full information, not so we can ask for the benefit of the doubt.
| Property | Signal | Apple iMessage (PQ3) | AETHER |
|---|---|---|---|
| PQ key exchange | Yes (PQXDH, handshake) | Yes (PQ3) | Yes, hybrid, and continuous in the ratchet |
| PQ authentication | No (classical) | No (classical ECDSA) | Yes (hybrid Ed25519 ⊕ ML-DSA-87) |
| Sealed sender | Yes | Partial | Yes |
| Self-hostable / sovereign relay | Limited | No | Yes (federatable) |
| Ownership model | Nonprofit service | Vendor service | Owned, local-first |
The honest summary: on post-quantum encryption, AETHER is in the same class as the best; on post-quantum authentication, it is ahead of both Signal and Apple; and it is uniquely sovereign and owned rather than rented. This table describes protocol properties, not a formal security proof — see §13.
This whitepaper is a protocol specification, not a peer-reviewed cryptographic proof. The primitives are standardized (FIPS 203/204) and validated against NIST ACVP vectors; the protocol composition is built on the well-studied Double Ratchet and standard hybrid-KDF patterns. Open items, stated plainly: a formal security-model proof of the continuous-PQC-ratchet composition; a per-session ephemeral-PQ-key variant for stronger PQ forward secrecy (§6.1); constant-time hardening of the native client (§11); automatic call reconnection (§9); and an independent third-party audit. The specification is public and the client is yours to inspect — verify it, or run it. Both are open to you.
AETHER is part of AETHERION, the Genesis security shield: FORTRESS (data at rest), VEIL (code integrity), SERAPHUM (hardware-bound sealing), and AETHER (communications). See the FORTRESS whitepaper for the data-layer architecture.