HYVE Encryption:
Quantum-Analogous Security
on Classical Hardware

1.1 The Problem Space

Modern communications face adversaries operating at scale. State actors, corporate espionage networks, and automated threat systems share three primary attack vectors: (1) intercept traffic in transit, (2) compromise endpoints to read plaintext before encryption or after decryption, and (3) subpoena infrastructure providers who hold server-side keys.

Existing end-to-end encrypted solutions address (1) but systematically fail on (3) through centralized key management and server-side identity registries. More subtly, all current solutions fail on a fourth vector: (4) traffic analysis. Even when message content is encrypted, the size, timing, and frequency of packets reveals conversation patterns, active contacts, and communication behavior.

1.2 Scope of This Document

This document specifies the full cryptographic architecture of two products built on the HYVE protocol:

HYVE — a secure communications app for Android providing encrypted messaging, media transfer, and voice/video calls. No server holds any encryption key material at any time. All key generation occurs on-device.

HYVEGuard — a full-device VPN for Android that captures all IP traffic via the Android VpnService TUN interface, fragments it into HYVE cells, and routes it through the HYVE relay to a trusted peer exit node. The relay sees only ciphertext.

1.3 Quantum-Analogous Cryptography (QAC)

Quantum Key Distribution (QKD) provides security rooted in the laws of physics: any eavesdropper disturbs the quantum state, making interception detectable. However, QKD requires dedicated fiber-optic infrastructure, specialized hardware, operates only over short distances, and costs orders of magnitude more than classical systems.

HYVE does not use quantum mechanics. Instead, HYVE achieves the same six observable security properties through a layered classical architecture — Quantum-Analogous Cryptography. Two of these properties (§6.1 and §6.3) are provably information-theoretically secure, meaning they hold independent of any computational assumption, including future quantum computers.

HYVE uses only well-audited, standardized primitives. No novel or proprietary cryptographic algorithms are employed. The security of the system depends entirely on the composition of these primitives, not on any single algorithm.

The fundamental unit of HYVE is the cell — a fixed 512-byte packet carrying exactly one fragment of one message (or cover noise). Every packet transmitted through the HYVE relay is exactly 512 bytes, regardless of content type.

3.1 Cell Layout

HYVE Cell — 512 bytes total
────────────────────────────────────────────────
Bytes    Size   Field            Description
────────────────────────────────────────────────
[0-63]   64B    Header / AAD     Unencrypted; authenticated via AEAD AAD
  [0]    1B       version        Protocol version (0x01)
  [1]    1B       flags          CellFlags (cover | final | file | video)
  [2-17] 16B      swarm_id       Random 16-byte swarm identifier
  [18-21] 4B      epoch          DH ratchet epoch (uint32 big-endian)
  [22-23] 2B      cell_seq       Cell position within swarm (uint16)
  [24-25] 2B      total_cells    N for Shamir split (uint16)
  [26]   1B       shamir_k       K threshold for reconstruction
  [27-31] 5B      reserved       Zero-padded
  [32-63] 32B     routing_token  One-time blind routing token (HYVE-BRT)
────────────────────────────────────────────────
[64-75]  12B    AEAD Nonce       Random per-cell nonce (ChaCha20-Poly1305)
[76-495] 420B   Encrypted Payload
  [0]    1B       shamir_x       Shamir share x-coordinate (0 = cover cell)
  [1-32] 32B      shamir_share   Shamir share value (zeros for cover)
  [33-419] 387B   message_payload  Message bytes or random cover noise
[496-511] 16B   Poly1305 Tag    Authentication tag
────────────────────────────────────────────────
Total: 64 + 12 + 420 + 16 = 512 bytes ✓

3.2 Authentication

The 64-byte header is used as AEAD additional data (AAD). This means the header fields — version, flags, swarm ID, epoch, cell sequence, routing token — are authenticated but not encrypted. A relay can read the routing token to forward the cell without being able to decrypt the payload. Any modification of the header causes the Poly1305 tag to fail, and the cell is silently dropped.

3.3 Cover Cells

Two cover cells are added to every swarm. A cover cell sets flags = isCover, shamir_x = 0, shamir_share = zeros, and fills message_payload with cryptographically random bytes. The cell key for cover cells is derived from the same chain key as data cells — making cover cells computationally indistinguishable from real data without knowledge of the chain key.

HYVEGuard extends the HYVE cell architecture to the network layer. Using Android'sVpnServiceAPI, HYVEGuard captures all IP traffic from all applications on the device, encrypts it into HYVE cells, and tunnels it through the HYVE relay to a trusted peer device acting as the exit node.

5.1 TUN Interface

Android's VpnService creates a virtual TUN (tunnel) network interface. By routing 0.0.0.0/0 through this interface and assigning a virtual IP address (10.0.0.2/24), all IPv4 traffic from all apps on the device flows through HYVEGuard's packet processing loop — including apps that are not HYVE-aware.

// TUN setup (Android VpnService.Builder)
builder
  .addAddress("10.0.0.2", 24)     // virtual device IP
  .addRoute("0.0.0.0", 0)         // capture ALL IPv4
  .addDnsServer("1.1.1.1")        // Cloudflare DNS
  .addDnsServer("8.8.8.8")        // Google DNS fallback
  .setSession("HYVE Shield")
  .establish()                    // returns ParcelFileDescriptor

5.2 Cell Encapsulation

Raw IP packets read from the TUN file descriptor are fragmented into 359-byte chunks (fitting in the message_payload field after nonce and tag overhead). Each chunk is wrapped in a HYVEGuard cell — a simplified 512-byte cell format sharing the same header structure as HYVE messaging cells.

// HYVEGuard cell differences from HYVE messaging cells:
// - Header bytes [0-31]: zero-padded (no Shamir fields needed for VPN)
// - Header bytes [32-39]: 8-byte routing prefix (inbox lookup)
// - Header bytes [40-63]: zero-padded
// - Payload: 436-byte ChaCha20-Poly1305 encrypted IP fragment
// Total: 512 bytes — identical on-wire size to messaging cells

5.3 Key Derivation

Both peers independently derive the same symmetric VPN session key without transmitting it. The key is derived from both peer HYVE IDs, ensuring symmetry regardless of which peer initiates:

// Shared VPN key (both peers compute identically)
sorted   = sorted([myHyveId, peerHyveId])          // lexicographic sort
combined = SHA-256(sorted[0] + "|" + sorted[1])
vpnKey   = HKDF-SHA256(combined, "HYVE-VPN-KEY-v1.0", 32)

// Per-direction keys
outboundKey = HKDF-SHA256(vpnKey, "HYVE-VPN-OUT-v1.0", 32)
inboundKey  = HKDF-SHA256(vpnKey, "HYVE-VPN-IN-v1.0",  32)

5.4 Relay Bypass Socket

The WebSocket connection to the HYVE relay must not itself be routed through the TUN interface (which would create an infinite tunnel loop). HYVEGuard uses a custom BypassSocketFactory that calls VpnService.protect(socket) on every OkHttp socket before connection, marking it as exempt from the TUN routing table.

5.5 Peer Exit Node Model

Unlike commercial VPNs where the VPN provider operates the exit servers, HYVEGuard's exit node is the trusted peer's own device. The relay sees only HYVE cells (ciphertext) and routes them to the peer's inbox prefix. The peer device decrypts the IP packet and forwards it to the public internet on behalf of the originating device, then returns the response through the same path. The relay operator sees zero plaintext at any point.

The following table maps the six core security properties of quantum key distribution to their HYVE classical analogs. For each property, we describe the quantum mechanism and the HYVE protocol element that achieves the same observable security outcome.

8.1 What HYVE Protects Against

Network-level interception: All traffic is encrypted ChaCha20-Poly1305. The relay sees only ciphertext and routing tokens. A network observer sees only 512-byte cells with no content or metadata.

Relay compromise: The relay holds no keys and cannot decrypt any cell. A compromised relay can observe routing token usage (which is unlinkable across messages) and can attempt to drop or delay cells. It cannot read, modify (AEAD prevents undetected modification), or replay messages.

Server subpoena: No HYVE server holds any user encryption key, message content, or conversation data. The identity server (id.hyveapp.co) holds only public keys and FCM tokens. A legal order to produce encryption keys against HYVE servers would produce nothing usable.

Offline device theft: The DEK is protected by KEK_bio (hardware-bound, biometric-gated) XOR KEK_pin (PBKDF2-100k). An attacker without the user's biometric cannot extract KEK_bio from the TEE.

8.2 What HYVE Does NOT Protect Against

8.3 Information-Theoretic Guarantee Summary

The fundamental commercial advantage of HYVE over QKD is deployability. Achieving quantum-analogous security properties requires:

HYVE does not claim to replace QKD for high-assurance government or defense applications where quantum-physical guarantees are legally mandated. HYVE claims to deliver equivalent observable security properties at five orders of magnitude lower cost and with global internet deployability — making quantum-analogous privacy accessible to individuals, journalists, activists, and enterprises operating in adversarial environments worldwide.

HYVE demonstrates that quantum-analogous security properties are achievable on classical hardware through architectural innovation rather than physical principles. The five-layer HYVE protocol stack — HYVE-CST, HYVE-BRT, HYVE-UT, HYVE-Ratchet, and HYVE-Vault — collectively replicate the six key security properties of quantum key distribution without quantum hardware.

Two of these properties (HYVE-CST Shamir K−1 guarantee and HYVE-Ratchet key deletion guarantee) are provably information-theoretically secure and will remain so regardless of advances in classical or quantum computing.

HYVEGuard extends this architecture to the network layer, providing full-device IP traffic encryption with a trusted peer exit node model that eliminates the need to trust any VPN provider infrastructure.

All components described in this document are implemented in production code, have been tested on physical Android devices, and are available for review. The architecture is designed to be auditable, with no proprietary algorithms and no server-side key material.