Skip to main content
  • Company
    • About Us
    • Projects
    • Startup Lab
    • AI Solutions
    • Security Expertise
    • Contact
  • Knowledge
    • Blog
    • Research
hello@horizon-dynamics.tech
Horizon Dynamics
Company
  • About Us
  • Projects
  • Startup Lab
  • AI Solutions
  • Security Expertise
  • Contact
Contact Ushello@horizon-dynamics.tech
Horizon Dynamics
© 2013 - 2026 Horizon Dynamics LLC — All rights reserved.

Right Solution For True Ideas

Messaging Layer

Ecliptix Protection Protocol

Hybrid post-quantum protocol: Double Ratchet + X3DH + ML-KEM (Kyber-768). End-to-end encryption with quantum resilience.

Messaging Layer

What is Ecliptix Protection Protocol?

A cryptographic communication protection protocol implementing hybrid post-quantum end-to-end encryption. The architecture is based on the Double Ratchet algorithm with X3DH (Extended Triple Diffie-Hellman) extension, augmented by NIST-standardized ML-KEM (Kyber-768) key encapsulation mechanism to ensure cryptographic resilience against HNDL (Harvest Now, Decrypt Later) attacks in the era of quantum computing.

01

Hybrid Post-Quantum Cryptography

HNDL attack mitigation through hybrid X25519 + ML-KEM (Kyber-768) protocol with dual key derivation

02

Post-Compromise Security

Automatic cryptographic material rotation via asymmetric ratchet operation with adaptive interval

03

Perfect Forward Secrecy

Deterministic ephemeral key derivation through symmetric ratchet with immediate destruction of predecessors

04

Mutual Cryptographic Authentication

Bilateral verification through cryptographic binding of identifiers to session context with SHA-256 hashing

05

Cryptographic Secret Isolation

Key material protection through page-locked memory with deterministic zeroing upon deallocation

Messaging Layer

Protocol Features

Ecliptix Protection Protocol provides comprehensive communication protection at every level

Forward Secrecy

Compromise of current keys cannot decrypt past messages. Old keys are automatically destroyed.

Break-in Recovery

Fresh keys on every direction change. 1-step classical PCS, 2-step hybrid PCS. Automatic security restoration.

Hybrid Quantum-Safe

X25519 + Kyber-768 hybrid construction. Secure if either classical OR post-quantum crypto is unbroken.

Identity Binding

Messages cryptographically bound to both parties' identities. Prevents identity substitution attacks.

Out-of-Order Support

Messages can arrive out of sequence. Skipped key cache handles network reordering gracefully.

Secure Memory

All secrets in guarded memory. RAM-locked, automatically zeroed on destruction. No memory fragmentation.

Cryptographic Architecture

Key Types & Sizes

Four-level key hierarchy with hybrid post-quantum protection. From long-term identity keys based on elliptic curves and lattices to short-lived symmetric message keys — each level ensures protection for its communication stage.

Long-term

Identity Level

Long-term identity cryptographic keys for asymmetric authentication and trust establishment between participants. Combination of classical elliptic curve cryptography (Ed25519/X25519) and post-quantum lattice-based cryptography (Kyber-768).

Classical Cryptography

Ed25519 Public KeySigning & verification
32 bytes
Ed25519 Secret KeySigning operations
64 bytes
Ed25519 SignatureMessage authentication
64 bytes
X25519 Public KeyKey exchange
32 bytes
X25519 Private KeyKey derivation
32 bytes
X25519 Shared SecretDH output
32 bytes

Post-Quantum Cryptography

Kyber-768 Public KeyKEM encapsulation
1,184 bytes
Kyber-768 Secret KeyKEM decapsulation
2,400 bytes
Kyber-768 CiphertextEncapsulated key
1,088 bytes
Kyber-768 Shared SecretKEM output
32 bytes
Medium-term

Session Level

Medium-term session establishment keys with limited lifetime. Signed pre-keys and one-time ephemeral keys for secure channel initialization with forward secrecy.

Session Establishment Keys

Signed Pre-Key PublicMedium-term key exchange
32 bytes
Signed Pre-Key SignaturePre-key authentication
64 bytes
One-Time Pre-KeySingle-use key exchange
32 bytes
Ephemeral KeyPer-handshake key
32 bytes
Ephemeral

Encryption Level

Short-lived symmetric encryption keys with automatic rotation. Root/Chain/Message keys for Double Ratchet algorithm with per-message forward secrecy and post-compromise security.

Encryption & Rotation Keys

AES-256 KeySymmetric encryption
32 bytes
AES-GCM-SIV NonceUnique per message
12 bytes
AES-GCM-SIV Auth TagMessage integrity
16 bytes
Root KeyKey material
32 bytes
Chain KeyPer-chain derivation
32 bytes
Message KeyPer-message encryption
32 bytes
Defense Architecture

Session State Structure

Integration of OPAQUE and Protection Protocol ensures protection from authentication to message delivery

01

Identity Verification

User initiates access — system verifies identity without collecting or storing password in any form

  • session_id 16 bytes
  • root_key 32 bytes
  • send_chain_key 32 bytes
  • recv_chain_key 32 bytes
  • dh_local_private 32 bytes
  • dh_local_public 32 bytes
02

Zero-Knowledge Authentication

OPAQUE protocol performs asymmetric key exchange — server never receives or stores password, eliminating database breach risk

  • kyber_local_secret 2,400 bytes
  • kyber_local_public 1,184 bytes
  • kyber_remote_public 1,184 bytes
  • dh_remote_public 32 bytes
  • identity_binding_hash 32 bytes
  • metadata_key 32 bytes

Message Envelope Structure

SecureEnvelope format for encrypted message transport

FieldSizeDescription
version4 bytesProtocol version
encrypted_metadata~56 bytesMetadata + auth tag
encrypted_payloadVariablePlaintext + auth tag
header_nonce12 bytesMetadata encryption nonce
ratchet_epoch8 bytesDH rotation epoch
dh_public_key32 bytesNew DH key (optional)
kyber_ciphertext1,088 bytesNew Kyber (optional)
sent_at12 bytesTimestamp
Minimum envelope~130 bytesWithout key rotation
With key rotation~2,250 bytesIncluding new DH + Kyber keys

Nonce Construction

AES-256-GCM-SIV 12-byte nonce format ensuring uniqueness

Prefix4 bytesRandom per session
Counter4 bytesIncrements per msg
Index4 bytesMessage index
Total: 12 bytes (96 bits) — AES-256-GCM-SIV standard nonce size

X3DH Key Agreement

Hybrid X3DH + Kyber-768

Initial Key Exchange

Initiator
Identity Ed25519 PK (32B) + X25519 PK (32B)64 bytes
Ephemeral X25519 PK + Kyber-768 PK1,216 bytes
PreKey Bundle + Kyber Ciphertext~2,400 bytes
Shared Root Key (32 bytes)
Responder

Diffie-Hellman Computations

4× ECDH + post-quantum KEM

DH1ECDH(Ephemeral, Signed Pre-Key)32 bytes
DH2ECDH(Identity, Signed Pre-Key)32 bytes
DH3ECDH(Ephemeral, Identity)32 bytes
DH4ECDH(Identity, One-Time Pre-Key)32 bytes (optional)
KEMKyber-768 Decapsulation32 bytes
SK = HKDF(DH1 || DH2 || DH3 || DH4 || KEM, "Ecliptix-Hybrid-X3DH")

Double Ratchet Protocol

Symmetric Ratchet (Per Message)

ChainKey[N]
HKDF
"Ecliptix-Msg"
MessageKey[N]
"Ecliptix-Chain"
ChainKey[N+1]
Every message derives new keys. Old keys destroyed immediately via sodium_memzero().

Asymmetric Ratchet (Per Direction Change)

Root Key
+
DH Secret
+
KEM Secret
HKDF "Ecliptix-Hybrid-Ratchet"
New Root Key
New Chain Key

Additional Authenticated Data (AAD)

AAD binds ciphertext to session context, preventing cross-session attacks

Metadata AAD (60 bytes)

Session ID16 bytes
Identity Binding Hash32 bytes
Ratchet Epoch8 bytes
Protocol Version4 bytes

Payload AAD (68 bytes)

Session ID16 bytes
Identity Binding Hash32 bytes
Ratchet Epoch8 bytes
Message Index8 bytes
Protocol Version4 bytes

Full Protocol Flow

From session initialization to message encryption

1Pre-Key Bundle Publication
PreKey BundleIdentity Keys (Ed25519 + X25519)Signed Pre-Key + SignatureOne-Time Pre-KeysKyber-768 Public Key
2X3DH Key Agreement
DH1IK_A × SPK_B
DH2EK_A × IK_B
DH3EK_A × SPK_B
DH4EK_A × OPK_B
SS = HKDF(DH1 || DH2 || DH3 || DH4)
3Hybrid Key Derivation
X3DH Secret32 bytes
+
Kyber KEM32 bytes
RK0 = HKDF(SS || KSS)
4Session Initialization
Immutable
IPK_selfIPK_peerMDK
Mutable
RKCK_sendCK_recv
5Symmetric Ratchet
CK[N]
HKDF
MK[N]Encrypt
CK[N+1]Next
6Message Encryption
Plaintext+MK+AAD
AES-256-GCM-SIV
Ciphertext + Tag (16 bytes)

Cryptographic Stack

LanguageRust
Key ExchangeX25519
Post-QuantumKyber-768
SigningEd25519
AEADAES-256-GCM-SIV
KDFHKDF-SHA256
Protocol BaseX3DH
Crypto Librarylibsodium + liboqs

Cryptographic Guarantees

Formal security properties proven by the protocol

Forward Secrecy

Each message uses a unique encryption key derived from the ratchet. Past messages remain secure even if long-term keys are compromised.

Post-Compromise Security

Break-in recovery on every direction change via hybrid ratchet. 1-step classical PCS (fresh X25519 DH), 2-step hybrid PCS (+ fresh Kyber-768 KEM).

Quantum Resistance

Hybrid construction with Kyber-768 ensures security against both classical and quantum attackers. NIST-standardized algorithms.

Identity Binding

SHA-256 hash of all identity keys binds every message to both parties. Prevents identity misbinding attacks.

Protocol Comparison

Technical comparison with Signal protocol variants — the industry baseline for secure messaging

FeatureEcliptixSignal PQXDHSignal X3DH
Per-Ratchet PQ Protection✓✗✗
Handshake PQ (Kyber-768)✓✓✗
Metadata EncryptionPer-epoch rotating keySealed SenderSealed Sender
AEAD CipherAES-256-GCM-SIVAES-256-CBC + HMACAES-256-CBC + HMAC
Nonce-Misuse Resistance✓✗✗
Post-Compromise Recovery1-step DH / 2-step hybrid1-step DH only1-step DH only
Perfect Forward Secrecy✓✓✓
Formal Proofs6 theorems + 10 Tamarin lemmasHigh-level analysiseCK sketch
Cryptographic Identity Binding✓✓✓

Formal Verification

All security properties verified by three independent methods: symbolic provers (Tamarin, ProVerif) and game-based reductions under a Dolev-Yao adversary with quantum oracle

Tamarin

Tamarin Prover 1.10.0

10 / 10 lemmas verified (handshake 6 + ratchet 4)

ProVerif

ProVerif 2.05

4 / 6 queries verified (Q5/Q6: known DH overapproximation)

Game-Based

Game-Based Proofs

6 theorems + 8 lemmas with concrete security bounds

01Verified

Session Key Secrecy

The hybrid root secret remains computationally indistinguishable from random for any PPT adversary, provided neither party's long-term key is compromised during the handshake.

SKC(A,B,sk) ∧ ¬Corrupt(A) ∧ ¬Corrupt(B) ⟹ ¬K(sk)
02Verified

Mutual Authentication

Bilateral HMAC-SHA256 key confirmation prevents Unknown Key Share (UKS) attacks. Both parties derive identical session keys and confirm via MAC exchange.

Confirm(A,B,mac) ⟹ ∃ Session(A,B,sk) ∧ Session(B,A,sk)
03Verified

Hybrid Forward Secrecy

Compromise of long-term X25519 keys after session completion does not break past sessions. Ephemeral keys are zeroized; Kyber-768 KEM provides quantum-resilient FS.

SKC(A,B,sk)@i ∧ Corrupt(A)@j ∧ i < j ⟹ ¬K(sk)
04Verified

Key Confirmation

Both initiator and responder derive identical root keys from the same X3DH + KEM inputs. HMAC confirmation ensures key agreement before any message encryption.

Confirm(A→B) ∧ Confirm(B→A) ⟹ RK_A = RK_B
05Verified

Post-Compromise Security

After full state compromise, security recovers in 1 step for classical (fresh X25519 DH) and 2 steps for hybrid (fresh DH + fresh Kyber-768 KEM). Each direction change triggers ratchet.

Compromise(A)@i ∧ Ratchet(A)@j ∧ i < j ⟹ ¬K(mk_j)
06Verified

Ratchet Key Secrecy

Each ratchet step derives a fresh root key via HKDF over new DH + KEM secrets. The ratchet key remains secret unless both parties' states are simultaneously compromised.

RatchetKey(A,B,rk) ∧ ¬(Corrupt(A) ∧ Corrupt(B)) ⟹ ¬K(rk)
07Verified

Key Agreement

Both parties derive the same root key from the hybrid X3DH output. Session ID binding and identity hashes prevent cross-session and misbinding attacks.

Session(A,B,sid) ⟹ RK_A(sid) = RK_B(sid)
08Verified

Message Confidentiality

Per-message keys derived via symmetric ratchet (HKDF-SHA256) provide IND-CPA+ security under AES-256-GCM-SIV (MRAE). Keys are destroyed immediately after use.

Adv^{IND-CPA+} ≤ Adv^{eCK} + q·Adv^{PRF} + Adv^{MRAE}
09Verified

Replay Resistance

Bounded nonce cache (2048 entries) with monotonic counters prevents message replay. INT-CTXT of AES-256-GCM-SIV ensures ciphertext integrity.

Adv^{Replay} ≤ Adv^{INT-CTXT} + 2^{-n_cache}
10Verified

Nonce-Misuse Resistance

AES-256-GCM-SIV (RFC 8452) degrades gracefully on nonce reuse — only leaks equality of plaintexts, not plaintext content. SIV construction provides MRAE security.

NonceMisuse(n) ⟹ Leak ≤ EqualityOracle(m₁,m₂)

Threat Model

Dolev-Yao adversary with full network control, adaptive long-term key corruption, and quantum oracle breaking classical Diffie-Hellman. Hybrid combiner follows the OR-model: security holds if EITHER X25519 (Gap-CDH) OR Kyber-768 (IND-CCA2) remains unbroken.

Group Messaging Protocol

MLS-inspired group messaging with hybrid PQ TreeKEM — X25519 + Kyber-768 per node

Hybrid PQ TreeKEM

Left-balanced binary tree with X25519 + Kyber-768 per node. parent_hash chain verification on every UpdatePath.

Sender Keys

Per-member symmetric hash ratchet for O(1) encrypt/decrypt. Each member maintains independent key chain.

Epoch Advancement

Commit + Welcome messages drive epoch transitions. External Join and PSK injection supported.

Membership Control

Add, Remove, Update, ExternalInit proposals. Full proposal validation and application pipeline.

Group Forward Secrecy

Epoch advancement via Commit; old epoch keys erased

Group Post-Compromise Security

TreeKEM UpdatePath re-encrypts with fresh X25519 + Kyber-768

Sender Authentication

Sender keys bound to leaf index; per-member symmetric ratchet

Tree Integrity

parent_hash chain from root to leaf verified on each UpdatePath

Shield Mode

Enhanced security policy cryptographically bound to group context hash — not configuration, but enforcement at key schedule level

Double-KDF Key Schedule

Two HKDF-Expand passes with different info strings. Compromising one pass is insufficient.

Mandatory Franking

Every message carries HMAC commitment for abuse reporting. E2E-compatible moderation.

Block External Join

Prevents uninvited members from joining via external commits.

Reduced Skip Window

Max skipped keys per sender reduced from 32 to 4, limiting flood attacks.

ParameterDefaultShield
Enhanced key schedule (2-pass KDF)OffOn
Mandatory frankingOffOn
Block external joinOffOn
Max messages per epoch100,0001,000
Max skipped keys per sender324

Sealed Messages

Double-layer encryption: recipient sees metadata and hint, but content stays encrypted until explicit reveal

Sealed Messages

Double-layer encryption: recipient sees metadata and hint, but content stays encrypted until explicit reveal

seal_key = HKDF-Expand(message_key, "Ecliptix-Group-SealKey", 32)
Inner AES-256-GCM-SIV with separate seal_key
seal_key derived from message_key, which is wiped after use
seal_key and message_key use different HKDF-Expand info labels
Outer AAD binds group_id, epoch, sender, generation

Disappearing Messages

Protocol-level TTL enforcement — not a UI trick, but cryptographic key destruction

TTL and timestamp stored inside encrypted payload. Protocol refuses decryption after expiry. message_key consumed by hash ratchet — re-decryption impossible.
decrypt() refuses to return plaintext after TTL
Hash ratchet destroys message_key; re-decryption impossible
TTL and timestamp inside AES-GCM-SIV authenticated encryption
On new epoch all sender chain keys destroyed

Message Franking

E2E-compatible abuse reporting — sender commits to content via HMAC, enabling selective disclosure to moderators

franking_tag = HMAC-SHA256(franking_key, content). Tag is outside ciphertext (visible to relay). Key is inside E2E payload (only recipient sees).
HMAC-SHA256 binds franking_key to specific plaintext
Only the reported message is revealed to moderator
Recipient cannot fabricate content (key was inside E2E)
Moderator verifies one message only, no access to others

Edit & Delete Messages

Protocol-native message editing and deletion with cryptographic binding to original message ID

Attack Coverage

38 attack proof-of-concept tests + 307 integration tests + 46 API tests

Attack VectorProtectionStatus
Harvest-Now-Decrypt-LaterKyber-768 on every ratchet stepAll epochs protected
Real-time Quantum AdversaryPer-ratchet Kyber-768 KEMPer-ratchet protection
Compromised Session StateHybrid ratchet (DH + KEM)1-step classical / 2-step hybrid PCS
Nonce Reuse (implementation bug)AES-256-GCM-SIV nonce-misuse resistanceSafe — leaks only equality
State RollbackHMAC-SHA256 anti-rollback on serialized stateDetected
Metadata Traffic AnalysisPer-epoch encrypted metadata + key rotationProtected
Replay AttackBounded nonce cache (2,048) + monotonic countersPrevented
Identity SubstitutionSHA-256 identity binding hash in every message AADPrevented

Detailed Protocol Comparison

Technical comparison with Signal protocol variants — the industry baseline

FeatureEcliptixSignal PQXDHSignal X3DH
PQ-protected handshake✓✓✗
PQ-protected ratchet✓✗✗
HNDL defense scopeHandshake + all epochsHandshake onlyNone
PQ forward secrecyPer-epochInitial session onlyNone
PQ post-compromise security✓✗✗
AEAD cipherAES-256-GCM-SIVAES-256-CBC + HMACAES-256-CBC + HMAC
Nonce-misuse resistance✓✗✗
Metadata privacyPer-epoch rotating keySealed SenderSealed Sender
State anti-rollback HMAC✓✗✗
Session teardown ceremony9-step key wipeNoNo
Secure memory (mlock)✓✗✗
Shamir secret sharing✓✗✗
Replay nonce cache (bounded)✓✗✗
Group messaging protocolHybrid PQ TreeKEMN/AN/A
Shield mode✓✗✗
Sealed / Disappearing / Frankable✓✗✗
Formal proofs6 theorems + 10 TamarinHigh-level analysiseCK sketch
Cryptographic identity binding✓✗✗
Multi-device support✗✓✓
Production deploymentResearch protocolBillions of usersBillions of users

Performance Benchmarks

Criterion benchmarks on Apple M-series

OperationTime
Full handshake (keygen + X3DH + Kyber + confirm)~1.1 ms
Hybrid ratchet step (X25519 + Kyber-768)~259 µs
Encrypt 256 bytes~17 µs
Decrypt 256 bytes~21 µs
Burst throughput (no ratchet)~15 µs/msg
Alternating throughput (256B)~524 µs
Out-of-order decrypt (20 msgs)~292 µs
Session export (sealed)~105 µs
Session import (sealed)~185 µs

Hybrid Ratchet Overhead

X25519 DH scalarmult
13%
~34 µs
Kyber-768 encap+decap
36%
~94 µs
HKDF + key derivation + state update
51%
~131 µs

Wire Format & Bandwidth

Message sizes and bandwidth trade-offs for hybrid PQ protection

MetricSizeNotes
Handshake init~1,170 bytes+Kyber-768 ciphertext
Pre-key bundle~1,400 bytes+Kyber-768 public key
Message overhead~80 bytesKey + metadata AEAD + nonce
Ratchet message (with PQ)~1,300 bytes+Kyber PK + ciphertext
Max envelope size1 MiBEnforced limit
Max handshake size16 KiBEnforced limit

Threat Model

Security posture against classical and quantum adversaries

ThreatEcliptixSignal PQXDHSignal X3DH
Passive eavesdropper (classical)✓✓✓
Active MITM (classical)✓✓✓
Harvest-now-decrypt-later (quantum)All epochsHandshake onlyVulnerable
Quantum adversary (real-time)Per-ratchetHandshake onlyVulnerable
Compromised session stateHybrid ratchetClassical onlyClassical only
Nonce reuseGCM-SIV safeCBC leaksCBC leaks
State rollbackHMAC anti-rollbackNo detectionNo detection
Metadata traffic analysisEncrypted + rotationSealed SenderSealed Sender

Security Audit & Testing

421 tests covering crypto primitives, protocol correctness, adversarial inputs, and attack PoCs

307Integration Tests
46API Tests
30FFI Tests
38Attack PoC Tests
421 tests, 0 failures•0 clippy warnings

Fuzz Testing

32 libfuzzer targets covering all protocol layers

Handshake & Session
fuzz_handshake_init, fuzz_handshake_ack, fuzz_session_state, fuzz_e2e_proto
Group Protocol
fuzz_commit_processing, fuzz_welcome_processing, fuzz_group_message_decrypt, fuzz_key_schedule, fuzz_sender_key, fuzz_tree_kem, fuzz_membership
Crypto Primitives
fuzz_aes_gcm, fuzz_hkdf, fuzz_kyber, fuzz_dh_validator, fuzz_shamir, fuzz_padding
Serialization
fuzz_protobuf_decode, fuzz_sealed_state_deserialize, fuzz_envelope_decrypt, fuzz_tree_deserialize
Identity & FFI
fuzz_identity, fuzz_nonce, fuzz_secure_memory, fuzz_master_key_derivation, fuzz_ffi, fuzz_relay

Use Cases

The Ecliptix protocol is ideal for industries with the highest privacy requirements

Secure Messaging Apps
Healthcare Communications
Financial Transactions
Government Systems
IoT Device Communication
Enterprise Collaboration
Legal Document Exchange
Whistleblower Platforms
Ecliptix Protocol

The Future of Communication is Quantum-Safe

Implement next-generation cryptography into your messaging infrastructure

Discuss Integration