SECURITY · POSTURE

Sovereignty is not a feature. It is the substrate.

HYVE Ether OS is designed to keep your AI and your data on your machine. This page documents our security principles, the cryptographic primitives, how we handle known issues, and our compliance status. HYVE is not yet certified under any compliance framework.

Our principles.

1. 01

   Local-first by default

   Your conversations, memory, provider keys, and connector secrets live in ~/.hyve/ on your machine as files only your user account can read. They are protected by file permissions, not encrypted at rest, so we recommend full-disk encryption. The OS registers your license once with hyveether.com at activation (the key and a machine identifier are sent over HTTPS, and our server can read them) and collects no telemetry or usage data. Standard system services such as network time sync and local-network discovery use the network, and so do features you start, like web search and model downloads.

2. 02

   Post-quantum by design

   HYVE's design uses ML-KEM-768 post-quantum key exchange, ChaCha20-Poly1305 AEAD, and Ed25519 signatures; it is not yet in the shipped build. Today files in ~/.hyve/ are not encrypted at rest, and device-to-device messaging is still in development.

3. 03

   Cryptographic recovery

   DataCore archives are encrypted per chunk with AES-256-GCM under a key derived from your vault, with an Ed25519-signed root hash you can verify entirely offline — so you can prove an archive is authentic and untampered.

4. 04

   Auditable decisions

   Omega's decide() function is deterministic — same input, same output, every time, under 200 ns per rule. Every decision is reconstructible in Observatory. Auditors can replay any decision exactly.

Security features index.

Security features in the HYVE Ether OS design and patent filings. Not every item is in the current build.

• Post-Quantum Encryption by Design

  HYVE's design uses ML-KEM-768 post-quantum key exchange; it is not yet in the shipped build. The designed substrate seals data in fixed 512-byte encrypted cells (ChaCha20-Poly1305 AEAD, Ed25519 signatures, blind routing tokens); today the cell format is used only by HYVE's device-to-device messaging, which is in development.

• Sovereign Data Protocol (.hyvedata)

  Per-chunk Brotli + AES-256-GCM encryption with an Ed25519-signed root hash you can verify offline, plus SQLite-indexed metadata; one vault unlock decrypts every archive. (NOT yet in the shipped build: Reed-Solomon GF(256) parity shards + Particle-Swarm-Optimized layout for partial-corruption survival — the designed next layer.)

• HYVE Uniform Transport (HYVE-UT)

  Every message in HYVE's device-to-device messaging (in development) is a fixed 512-byte cell — header, nonce, encrypted payload, Poly1305 tag. Same size regardless of payload, eliminating size-based traffic analysis attacks.

• HYVE Cell-Sharded Transport (HYVE-CST)

  Part of HYVE's device-to-device messaging, which is in development: messages exceeding 387 bytes are split via Shamir K-of-N secret sharing applied per byte position over GF(256). Any K cells reconstruct the original; any K-1 cells reveal nothing.

• HYVE Blind Routing Tokens (HYVE-BRT)

  Part of HYVE's device-to-device messaging, which is in development: routing tokens are HKDF-SHA256 over the chain key, swarm identifier, and cell sequence index, so a relay without the chain key cannot link cells of the same conversation.

• HYVE Ratchet (Forward Secrecy at Message Granularity)

  Part of HYVE's device-to-device messaging, which is in development: per-conversation epochs with chain-key rotation via HKDF-SHA256 and zeroized prior keys, designed so that compromising the current state does not expose past traffic.

• Sovereign OS Architecture

  Two-tier key hierarchy (PIN → KEK → DEK), multi-organ topology, .hyvedata signed archive, deterministic decide() runtime — all in one architecture.

• Tarpit + Tor + Sentinel Defensive Triad

  A tarpit organ that drips fake banners to attackers for hours, a Tor controller organ with pluggable transports (obfs4, meek_lite, snowflake), and a sentinel kill organ for cross-platform process termination — all audit-logged.

• .hyvedata Generation Pipeline

  SHA-256 hash, Brotli compression, AES-256-GCM per-chunk encryption, SQLite metadata, Ed25519-signed root hash — the shipping archive flow. (Reed-Solomon parity + PSO layout are the not-yet-shipped corruption-recovery layer.)

• Per-Organ Identity Isolation

  Designed so each organ presents an authentication record at startup (organ name, epoch counter, ML-KEM-768 key encapsulation token, Ed25519 signature) and unsigned organs are refused. (NOT yet in the shipped build: today organs are local web services on your machine, and most write routes are gated by an owner token.)

• PIN, Password and Gesture Unlock

  PIN, password and gesture unlock.

• Cover-Cell Traffic Analysis Defense

  Designed for HYVE's device-to-device messaging, which is in development: network-indistinguishable decoy cells with cryptographically random payload bytes and AEAD encryption identical to real cells, so operators can keep a constant traffic rate against passive observers.

• Civic Credential Verification Gate

  Constant-evaluation credential check before any civic sub-surface accepts operator documents — no document reaches encrypted storage until the unlock gate validates.

• Federal Compliance Phased Installer

  Planned, not in the shipped build: an operator-paced, phased federal-compliance installer. Designed phases: banner, audit, sysctl, MAC, strict, all — each adding a coherent set of system-hardening primitives.

• Civic Chat Redaction Filter

  Operator-visible chat output of any civic sub-surface is filtered through a redaction function before display — protects against accidental leakage of sensitive civic data.

• Shell-Script Generation Injection Defense

  Operator parameters validated against per-parameter constraint sets (URL scheme allowlists, control-character rejection, length caps). Validated values written to mode-0600 sidecar env files; scripts read via shell builtins, never heredoc-interpolated.

• Timing-Leak-Free Credential Verification

  Unlock verification with length-capped inputs, parallel Argon2id derivations without short-circuit, bitwise-AND combination, and uniform error message on failure — defends against side-channel timing attacks.

• Staged Operator-Paced OS Hardening

  Planned, not in the shipped build: a hardening installer with a phase argument (banner / audit / sysctl / mac / strict / all), designed so each phase is auditable and reversible via a revert phase that restores the prior baseline snapshot.

• Cross-Device Pairing Without Centralized Server

  Designed for HYVE's device-to-device messaging, which is in development: a pairing token and ephemeral Ed25519 keypair encoded in a QR code; the second device scans it, opens a TCP handshake, and exchanges cell-substrate messages to establish a HYVE-Ratchet keyed by the operator's long-lived identity, with no centralized pairing service.

• Operator-Controlled Signaling Relay

  The signaling relay URL is operator-configurable; the relay service is not public yet, and device-to-device messaging is in development. The setter validates the URL and saves it to a mode-0600 env file.

• Capability-Bounded LLM Execution

  Tactical-tier LLM execution where the model's available actions are bounded by a capability manifest at invocation time. In the 3.0 build now in testing, agent actions pass a default-deny policy check, and code the agent writes for apps runs in a Linux Landlock + seccomp sandbox.

• Time-Locked Decryption (Verifiable Delay Function)

  Evidence sealed under a verifiable-delay-function gate that mathematically resists early decryption — useful for legal evidence chain-of-custody where reveal time must be controllable and provable.

• Mesh-Distributed Persona With Duress Auto-Shred

  Operator persona threshold-sharded across a mesh of devices. A duress signal silently triggers persona auto-shred — coercion against any single device cannot reconstruct the persona.

• Typing-Rhythm Duress Detection

  Anomaly detection over the operator's typing-rhythm baseline — sudden departure from established patterns triggers a silent duress signal across the persona mesh.

• Self-Mutating Defenses With Bounded Mutation

  Defensive postures evolve under bounded mutation — the system varies its own surface to resist signature-based attacks without exceeding operator-set safety boundaries.

• Deterministic Classification Inheritance for ML Training

  Training data inherits classification labels deterministically — derived models cannot accidentally produce outputs at lower classification than their inputs.

• Decoupled Binary/Policy Accreditation Signing

  Threshold signing for accreditation that decouples the signed binary from the signed policy — binaries can be re-accredited without re-signing policy, and vice versa.

• AEAD-Nonce-Bound Caveat Enforcement

  Wire-layer caveat enforcement bound into AEAD nonce material — caveats cannot be stripped without invalidating the cell's authentication tag.

• Classification-Aware Multi-Audience Briefing Synthesis

  Single source briefing rendered for multiple audiences (operator, command, allied, public) with per-audience classification awareness — automatic redaction at each tier.

• Sentinel Hardware Kill-Switches

  A designed camera and microphone cut-off at the kernel-module level. (NOT yet in the shipped build.)

• HYVE Identity

  Sovereign on-device identity: X25519 master keypair and HKDF-derived scoped tokens. No cloud account required.

Reporting a vulnerability.

If you discover a security issue in the OS or the website, please email Dev@vibesoftwaresolutions.com with details. We aim to acknowledge security reports within 48 hours, fix confirmed issues in new builds, and credit reporters unless you ask otherwise.

We follow coordinated-disclosure norms: please give us a chance to patch before public disclosure. We do not litigate good-faith security research.