Visk Ops Deployment Brief

Scope

Visk Ops is the dedicated deployment path for regulated and critical operators. It separates high-assurance traffic from the consumer network by using customer-hosted infrastructure and a customer-run ZK-RAM relay layer.

Web sessions are linked to a Visk Quantum client through an encrypted tunnel so relay nodes only handle ciphertext.

Deployment Boundary

• Single-tenant Visk Ops instance per organization.
• Dedicated ZK-RAM relay servers operated by the customer.
• No dependency on shared public ZK-RAM relays for ops traffic.
• Geographic residency follows the deployment location you choose.

Architecture Philosophy: Why Federated Zero-Knowledge over Pure P2P?

A common question from security purists is why Visk Ops utilizes a federated relay architecture rather than a pure peer-to-peer (P2P) decentralized network. While pure P2P networks (like those relying on DHTs or Gossip protocols) offer theoretical architectural purity, they introduce fatal practical flaws for mobile and enterprise environments.

• The Latency & Battery Crisis: In a pure P2P network, every client must act as a routing node. For a mobile device, constantly maintaining connections, participating in background DHT lookups, and routing encrypted traffic for strangers results in severe battery drain and unusable message latency.
• The IP Leakage Problem: Standard P2P networks require direct connections, instantly exposing the origin IP addresses of both communicating parties. Mitigating this requires Onion/Garlic routing, which further multiplies the latency and bandwidth costs.
• The Visk Compromise: Visk Ops solves this by decoupling the trust model from the network topology. By routing through a federated server, mobile clients gain instant, asynchronous message delivery and near-zero background battery drain. However, because the server strictly utilizes Zero-Knowledge RAM (ZK-RAM) and the Aetherion payload pipeline, the relay remains mathematically blind.

The Result: Visk provides the performance, reliability, and asynchronous delivery of a centralized enterprise platform, while mathematically enforcing the trustless, zero-knowledge privacy guarantees of a P2P protocol.

Bulk Data Encryption After PQC

Current post-quantum strategies often rely on hybrid approaches that wrap classical AES keys with quantum KEMs. While effective for transport, this leaves bulk data encryption reliant on classical assumptions. Aetherion (ML-NGES) explores applying the mathematical hardness of the Module-LWE problem as an additional shielding layer around the AES payload data in an experimental construction.

The Valkyrie Protocol (WDES)

The Valkyrie Protocol implements a "Wrap-Derive-Encrypt-Sign" (WDES) pipeline to achieve holistic security:

• Transport: ML-KEM establishes a shared secret.
• Hardening: Argon2id derives the session key, preventing related-key attacks.
• Encryption: ML-NGES encrypts the AES-GCM payload via lattice noise.
• Identity: ML-DSA signs the ciphertext to ensure non-repudiation.

Technical Characteristics

Aetherion operates as a chunked lattice encryption construction:

• Chunked parallelism: Payload data is split into fixed-size chunks for independent, parallel encryption.
• Deterministic randomness: Per-chunk noise is derived from message compression and the public key hash with explicit counter separation.
• Integrity: A full-ciphertext HMAC is used for integrity checks, with ML-DSA signatures used for non-repudiation.

Parameter Sets

Aetherion defines variable-degree polynomial rings R_(q,n) as profiles:

Status and Claims

ML-NGES is an experimental encryption construction. While it reuses post-quantum primitives standardized by NIST, the overall scheme is not standardized and does not inherit the formal security proofs of ML-KEM or ML-DSA. Treat it as research-grade until formal cryptanalysis and proofs are available.

Control And Policy Ownership

Operational settings are owned by the deploying organization. ZK-RAM relay behavior, routing boundaries, and retention windows are defined locally to align with internal policy.

Identity Management & Access Verification

Visk Ops maintains absolute anonymity at the relay level, requiring no emails, phone numbers, or corporate IDs. To satisfy high-assurance Identity and Access Management (IAM) requirements, Visk Ops uses a decoupled, blind provisioning model:

• Internal Authentication: Organizations authenticate users via their existing IAM providers (e.g., Microsoft Entra ID, Active Directory) through an internal, customer-built issuance portal.
• Blind Provisioning: Upon successful IAM authentication, the internal portal requests a cryptographic Launch Key from the Visk Ops API.
• Zero-Knowledge Access: The employee inputs the Launch Key into the Visk client. The relay burns the key and whitelists the device's ML-KEM public key hash.

Result: The enterprise retains strict control over who gets access, but the Visk Ops relay only registers mathematical proofs. The infrastructure remains completely oblivious to the user's real-world identity.

Audit Logging & Regulatory Compliance

To meet stringent compliance frameworks (e.g., NIS2, CMMC) without violating Zero-Knowledge principles, Visk Ops enforces a strict separation between operational telemetry and payload data:

• Operational Audit Trail: The relay persists a tamper-evident, ML-DSA signed log of all administrative actions. This includes admin authentication, SIGRUN policy modifications, access control issuance, and SKULD consensus votes. These logs are structured for standard SIEM integration.
• Payload Blindness: The relay is physically incapable of logging communication graphs, payload metadata, or origin IP addresses. All user data remains entirely opaque, sealed within the WDES pipeline.

Responsibility Snapshot

Exact responsibilities are defined by contract and deployment scope.