White Paper · Draft for public peer review

HELIX: A post-quantum, AI-resistant private communications system

Pedro Gonzalez, Cryptographer

Version 1.0 · Released openly for public peer review · No NDA, no registration required

Abstract. HELIX is a closed, end-to-end encrypted communications system providing messaging, voice and video over a purpose-built, decentralized onion network. It is designed for adversaries who are well-resourced, persistent and patient: nation-state interception, mass metadata harvesting, "harvest now, decrypt later" against future quantum computers, and large-scale machine-learning analysis of intercepted content. HELIX combines a hybrid classical/post-quantum key agreement, a double cipher cascade with continuous re-keying, sender-anonymous onion routing with fixed-size cells and cover traffic, a closed app-to-app membership model, and an aggressively hardened endpoint. This document describes the architecture and threat model and invites scrutiny. Following Kerckhoffs's principle, the cryptographic design is stated openly; security rests on keys, not on secrecy of the mechanism. Operational and deployment details (network addresses, relay membership, endpoint anti-forensics specifics) are deliberately omitted as they bear on operational security, not on the soundness of the cryptography.

1. Threat model 2. Design principles 3. Identity & authentication 4. Hybrid post-quantum handshake 5. Message protection 6. Metadata protection 7. Closed network 8. Key management 9. Endpoint hardening 10. Real-time media 11. Limitations References

1. Threat model

We assume an adversary who can: observe and tamper with any network link; operate or compromise some relays; coerce third parties (hosting providers, registrars, app stores) into disclosure; record ciphertext indefinitely for future cryptanalysis; and apply automated, machine-learning-scale analysis to anything they intercept. We do not assume the adversary has fully compromised the user's endpoint at the hardware level; that case is addressed separately (§9, §11) and motivates the hardened-device option.

Security goals: confidentiality and integrity of content; authentication of peers; forward secrecy and post-compromise security; resistance to "harvest now, decrypt later"; sender–recipient unlinkability against any single network vantage point; minimization of metadata; and graceful failure (never falling back to an exposed channel).

2. Design principles

Kerckhoffs's principle. The system is secure even if everything but the keys is known. This paper states the design openly.
No third parties in the trust path. The transport, routing and key exchange are built in-house. There is no external messaging backend, conferencing service or analytics SDK to subpoena, breach or mine.
Post-quantum by default. Every long-lived secret is protected against future quantum adversaries from day one.
Fail-closed. If the protective transport is not established, nothing is sent. There is no fallback to a cleartext or attributable channel.
No machine-readable surface. No telemetry, no cloud, no on-device ML inference over user content. Intercepted data is dense ciphertext; local data is never exposed to a model.

3. Identity & authentication

Each device generates a long-term identity consisting of a classical signature key (Ed25519 [1]) and a post-quantum signature key (a NIST-selected lattice scheme, ML-DSA [2]). A peer's identity is summarized by a fingerprint over the concatenated public keys, which users verify out of band when adding contacts. Authenticating with both a classical and a post-quantum signature means a forgery requires breaking both; a future quantum break of the classical scheme alone does not enable impersonation.

4. Hybrid post-quantum handshake

Session establishment runs a hybrid key agreement that concatenates secrets from three independent mechanisms and feeds them through a KDF, so the resulting key is secure if any one remains unbroken:

X25519 elliptic-curve Diffie–Hellman [3] — fast, well-studied classical security.
ML-KEM-1024 (Kyber, FIPS 203) [4] — lattice-based key encapsulation for post-quantum security.
Classic McEliece [5] — a conservative code-based KEM with a decades-long cryptanalytic track record, included as a hedge against lattice-specific advances.

The three shared secrets are combined with a domain-separated KDF (HKDF) into the initial root key. Authenticity is bound into the transcript via the dual signatures of §3, preventing unknown-key-share and man-in-the-middle attacks. Using two distinct post-quantum families (lattice and code-based) avoids placing the entire post-quantum bet on a single hardness assumption.

5. Message protection

After the handshake, messages are protected by a continuously re-keyed ratchet in the spirit of the Double Ratchet [6], with two reinforcements:

Double cipher cascade. Each message is sealed under two independent AEADs — AES-256-GCM and XChaCha20-Poly1305 — with independent subkeys. A weakness later discovered in one cipher does not by itself expose plaintext.
Periodic post-quantum re-keying. The ratchet periodically folds in fresh post-quantum key material, restoring post-compromise security even against an adversary recording for the long term.

The construction provides forward secrecy (compromise of current keys does not reveal past messages) and post-compromise security (the session heals after a transient compromise).

6. Metadata protection: the HELIX onion network

Content encryption does not hide who is talking to whom. HELIX therefore routes traffic over its own onion network — not Tor and not any third-party network. The construction follows the Sphinx packet design [7]:

Layered encryption using per-hop keys derived via Diffie–Hellman with curve blinding (Ristretto255), so each relay learns only the previous and next hop.
Fixed-size cells. Every packet is padded to a constant length and re-padded at each hop, defeating length-based correlation.
Multi-hop, randomized circuits. Each message takes a fresh path several hops deep; no single relay sees both endpoints, and routes are not reused.
Constant-rate cover traffic blurs timing analysis.
Rendezvous delivery so the sender need not learn the recipient's network location.

This protects sender–recipient unlinkability against any single relay or network vantage point and against a relay operator. Its limits are stated honestly in §11.

7. Closed network & membership

HELIX is a closed system: only HELIX endpoints participate. There is no gateway to the public phone network or email, and no discovery directory exposing users. Membership is by explicit, mutually authenticated addition; groups are formed from already-verified members. An outside party therefore has no address to message, call or probe. This eliminates entire classes of spam, phishing and reconnaissance, and means a user's presence is not advertised anywhere.

8. Key management & self-custody

All long-term secrets live on the user's device, sealed at rest by a key stretched from the user's secret with Argon2id [8] and encrypted with an AEAD; nothing is escrowed. For inheritance-grade recovery, secrets can be split with Shamir's Secret Sharing [9] over GF(2⁸) with uniformly sampled coefficients, so that any m-of-n shares reconstruct the secret and fewer reveal nothing. The provider holds no key material and cannot decrypt data or recover funds for the user — by construction, not by policy.

9. Endpoint hardening

Because endpoints are the softest target, HELIX hardens the client: predictive-keyboard learning, autocorrect and spellcheck are disabled over sensitive fields; the clipboard self-wipes; screenshots and screen recording are blocked by the OS where supported; and a one-action "burn" irreversibly destroys on-device secrets. Plausible-deniability cover means a device under inspection reveals nothing. For adversaries capable of targeted device implants (e.g. Pegasus-class spyware), HELIX additionally offers a hardened mobile platform built on GrapheneOS, shrinking the attack surface beneath the application itself.

10. Real-time media

Voice and video frames are sealed with the same AEAD cascade as messaging and carried over HELIX's own transport, with no third-party conferencing server. The media codec is the device's hardware encoder/decoder; HELIX owns the protocol, transport and encryption around it rather than re-implementing a codec. Two operating modes are offered: a low-latency direct path for high-throughput calls between reachable peers, and a metadata-protected path over the onion network when unlinkability matters more than latency.

11. Security limitations (stated honestly)

No serious security document omits its limits. Peer reviewers should weigh the following:

Global passive adversary. An adversary who can observe all network links simultaneously may, in principle, perform end-to-end traffic-confirmation despite cover traffic. Onion routing defeats ordinary, regional and relay-level adversaries, not an omniscient global observer; we do not claim otherwise.
Endpoint compromise. If the adversary fully controls the device at the OS or hardware level, no application can guarantee confidentiality. This is the motivation for the hardened-device option and for endpoint hardening, not a claim of immunity.
User key custody. Self-custody means there is no recovery path for a lost unlock secret or seed. This is a deliberate trade-off in favor of the user holding sole control.
Cryptographic assumptions. Post-quantum schemes are younger than classical ones; the hybrid design is specifically intended to contain the failure of any single assumption.

12. Conclusion & invitation

HELIX composes well-studied primitives in a defense-in-depth arrangement: hybrid post-quantum key agreement, a double cipher cascade with healing re-keys, self-built onion routing for metadata, a closed membership model, self-custody key management, and a hardened endpoint. The design is published here so that it can be examined, challenged and improved. Critiques are welcome and will be addressed in revisions of this paper.

References

Bernstein et al. "Ed25519: high-speed high-security signatures." RFC 8032.
NIST FIPS 204, "Module-Lattice-Based Digital Signature Standard (ML-DSA)," 2024.
Bernstein. "Curve25519/X25519." RFC 7748.
NIST FIPS 203, "Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM)," 2024.
Bernstein, Lange, Peters et al. "Classic McEliece," NIST PQC submission.
Marlinspike, Perrin. "The Double Ratchet Algorithm," Signal, 2016.
Danezis, Goldberg. "Sphinx: A Compact and Provably Secure Mix Format," IEEE S&P 2009.
Biryukov et al. "Argon2." RFC 9106.
Shamir. "How to share a secret," Communications of the ACM, 1979.
Aumasson, Bernstein et al. "XChaCha20-Poly1305"; McGrew, Viega. "GCM." RFC 8439 / NIST SP 800-38D.