[ 01 / 01 ]

[ SECURITY ]

SECURITY MODEL

[01/01]
🔒 Post-Quantum Security · HITE-Sealed · AES-256-GCM

Security &
Zero Exposure.

Every zeq_ak_ API key is stored as a SHA-256 hash — plaintext never persisted. HITE-sealed certificates bind each key to its issuance Zeqond counter with AES-256-GCM tamper detection.

HITE · ZEQ3 Format · Zeqond-Bound · ZEQDrop ID · AES-256 Post-Quantum
1056 J
Estimated classical energy cost to brute-force the AES-256 key layer
Classical theoretical minimum per Landauer's principle (300 K) for an exhaustive AES-256 key search (2²⁵⁶ operations). Surpasses the estimated total energy output of the Sun over its entire 10-billion-year lifespan.
Overview

What is HITE encryption?

HITE (Hulya Integrated Temporal Encryption) is the proprietary key-certificate scheme used by Zeq.dev. API keys issued through the portal are stored as SHA-256 hashes and authenticated by hash match. HITE additionally produces a sealed certificate: an AES-256-GCM envelope that encodes the key and its issuance Zeqond counter, providing a cryptographic proof of origin. The HITE pipeline has four conceptual stages:

Step 1
AES-256-GCM
Encryption
Symmetric key wrapped with a server-side master secret. 256-bit key, random 96-bit IV, 128-bit auth tag.
›
Step 2
Zeqond
Temporal Embedding
The Zeqond counter at issuance time is concatenated into the plaintext before encryption (key|zeqond). The envelope is cryptographically bound to that specific issuance moment — any tampered or forged envelope fails GCM tag verification before key material is reached.
›
Step 3
GCM Auth Tag
Seal
The 128-bit AES-GCM authentication tag is computed over the full ciphertext. Any single-bit mutation to the stored blob invalidates the tag before any key material is processed.
›
Step 4
ZEQDrop
Identifier
The first 8 hex characters of the sealed output — derived from the AES-GCM IV — serve as the ZEQDrop: a short, fast key-lookup identifier. Envelope integrity is enforced by the GCM tag, not this field.
›
Output
ZEQ3 Format
Sealed Key
Never stored in plaintext. Only the SHA-256 hash of the full key is kept for fast bearer-token verification.
Security Pillars

Four layers of protection

🔑
AES-256-GCM — Symmetric Encryption
The industry-standard for symmetric authenticated encryption. AES-256-GCM provides both confidentiality and data integrity in a single pass. The 256-bit key space has 2²⁵⁶ possible values — computationally infeasible to brute-force with any known classical computing approach. The 128-bit authentication tag detects any in-transit modification.
⛰
AES-256 — Post-Quantum Security Margin
AES-256 provides a meaningful post-quantum security margin. Grover's algorithm — the strongest known quantum attack on symmetric ciphers — halves the effective key length from 256 to 128 bits, still computationally infeasible. Shor's algorithm does not apply to symmetric encryption. NIST explicitly recommends AES-256 for post-quantum use cases.
⏱
Zeqond Temporal Binding
The Zeq.dev framework operates in discrete 0.777-second intervals called Zeqonds. Every HITE envelope encodes the Zeqond value at the time of key creation. This temporal fingerprint ties the certificate to its exact issuance moment — any tampered or independently forged certificate will fail AES-GCM tag verification because the encrypted payload cannot match without the server secret.
📈
ZEQDrop Identifier
The ZEQDrop is the first 8 hex characters of the sealed HITE output — derived from the random AES-GCM IV — and serves as a short, fast key-lookup identifier. Tamper detection is provided by the AES-GCM 128-bit authentication tag, which immediately rejects any modification to the stored envelope on every authentication attempt.
🌍
Precision Verification — NIST / NASA / CERN Datasets
All ZEQ operator outputs are verified to ≤0.1% precision against authoritative scientific datasets: NIST fundamental physical constants (CODATA 2022), NASA Jet Propulsion Laboratory planetary ephemerides (DE440), and CERN particle physics benchmarks. Precision is enforced by the KO42 tensioner at runtime — every compute request returns a precision field in the ZeqState envelope, guaranteed ≤ 0.001 (≤0.1%).
Key Format

The ZEQ3 key envelope

When you receive your zeq_ak_ key, you are holding the full bearer token — it is presented once at issuance and never stored in plaintext. The database persists two protected representations: (1) a SHA-256 hash for fast authentication lookup, and (2) a ZeqField-encrypted ciphertext (AES-256-GCM with a unique random IV) that powers the one-time portal Reveal feature. The ZEQ3 format describes the logical structure of the sealed envelope:

zeq_version
Protocol version tag. Currently ZEQ3. Allows future format migration without breaking existing keys.
iv
96-bit (12-byte) random initialisation vector for AES-256-GCM. Unique per key issuance. Never reused.
ct
AES-256-GCM ciphertext of the raw API key material, hex-encoded.
tag
128-bit AES-GCM authentication tag. Verifies ciphertext integrity before any decryption attempt.
zeqond
The Zeqond counter at time of issuance. Binds the envelope to a specific 0.777 s time interval of the HulyaPulse clock.
drop
ZEQDrop identifier — first 8 hex characters of the sealed output, derived from the AES-GCM IV. Used as a fast short identifier for key lookup. Tamper detection is performed by the AES-GCM tag field above, not this field.
Comparison

HITE vs. industry standards

Scheme Symmetric Post-Quantum Temporal Binding Tamper Seal Bearer Token
Zeq.dev HITE AES-256-GCM AES-256 Grover-resistant Zeqond-bound GCM Auth Tag zeq_ak_ Bearer
Standard JWT (RS256) RSA-PKCS1 Not quantum-safe exp claim only Signature only Bearer token
Stripe API keys AES-256 at rest Not quantum-safe No temporal binding Bcrypt hash only sk_ prefix
GitHub PATs AES-256 at rest Not quantum-safe Expiry date only SHA-256 hash ghp_ prefix
SHA-256 only None Not quantum-safe No temporal binding Hash only Varies
Bcrypt only None Not quantum-safe No temporal binding Hash only Varies
Platform Security

Defence-in-depth

🔐
SHA-256 Key Hashing
The bearer token portion of your zeq_ak_ key is stored only as a SHA-256 hash. The full plaintext key is shown once, at issuance, and never stored. Authentication checks the submitted key against the stored hash, so even a database breach exposes no usable keys.
⚡
Rate Limiting
Every API endpoint is rate-limited by IP and by API key. Compute endpoints enforce plan-tier daily token limits. Waitlist and contact endpoints are throttled independently to resist enumeration and spam.
🔒
TLS in Transit
All traffic to zeq.dev is served over TLS 1.3 with mTLS at the Replit edge layer. Bearer tokens are never transmitted in plaintext. HSTS is enforced across the production domain.
🖌
Content Security Policy
The Zeq.dev portal enforces a strict Content-Security-Policy: script-src 'self'. No inline scripts are permitted. All JavaScript is served from the same origin only, preventing XSS injection.
📑
Encrypted Waitlist
Waitlist email addresses are encrypted at rest using AES-256-GCM (keyed from WAITLIST_ENCRYPTION_KEY) before being written to the database. No plaintext email is ever stored — only the encrypted ciphertext and a unique random 96-bit IV. Contact form PII uses the separate ZeqField PBKDF2-derived cipher.
📋
Stripe-Managed Payments
Payment card data is handled exclusively by Stripe — Zeq.dev never sees, stores, or processes card numbers. Subscription state is verified via signed Stripe webhooks on every request cycle.
ZeqField Cipher

Five ZeqField Protocols

Beyond HITE, Zeq.dev runs a second cryptographic layer — the ZeqField cipher — that protects all user PII at rest. ZeqField derives its encryption key from the same HULYAS framework constants that power the physics engine: HulyaPulse frequency 1.287 Hz, Zeqond interval 0.777 s, coupling constant α = 0.00129, and the 1,576 verified operator count. This mathematical binding means the cipher key is semantically anchored to the physics framework itself. Five protocols extend ZeqField into runtime operations:

🔑
ZFK — Key Activation
AES-256-GCM key derived via PBKDF2-SHA256 at 200,000 iterations from HULYAS constants. Encrypts all contact form PII (name, email, message, company, role) — each field independently with a unique random 96-bit IV embedded in the blob. The ZEQ_FIELD_KEY secret binds the cipher to the deployment instance. Waitlist emails use a separate AES-256-GCM path keyed from WAITLIST_ENCRYPTION_KEY.
⚡
ZeqPulse — Live Sync
Public endpoint exposes the live 1.287 Hz HulyaPulse state (Zeqond τ, phase φ, R_t). Authenticated SSE stream delivers a new tick every 777 ms for real-time agent synchronisation. MCP tool: zeq_pulse.
📈
ZeqProof — HMAC Seal
Every successful POST /api/zeq/compute response (HTTP 200) carries a zeqProof — a 64-char HMAC-SHA256 digest over operatorIds, R_t, zeqond, and keyPrefix, in that canonical order. Verify with POST /api/zeq/verify.
📋
ZeqLattice — Coherence Grid
Computes 2–5 nodes at staggered HulyaPulse phases sharing a common Zeqond. Returns a coherenceScore (1 = perfect sync) and lattice equation for distributed physics computation modelling.
⌛
ZeqShift — Time Projection
Projects R(t) forward up to 64 Zeqond steps (49.7 s of future HulyaPulse states). Because R(t) is deterministic, the projection is exact — not approximate. Returns phase, zeqond, and R_t per step.
🔗
Full Protocol Reference
All five ZeqField Protocols are documented with curl examples, response schemas, and MCP tool definitions on the Protocols page. Each protocol links to its corresponding REST endpoint.
⚡ View ZeqField Protocol Reference  →
Research Foundation

Verified mathematical basis

The Zeqond temporal binding in HITE is derived from the synchronisation mathematics published in the HULYAS framework paper — specifically the 1.287 Hz HulyaPulse and 0.777-second Zeqond interval. These constants are not arbitrary: they emerge from the master equation R(t) = S(t) × [1 + 0.00129 × sin(2π × 1.287 × t)], which describes physical synchronisation across quantum-to-relativistic scales. Embedding these constants as the HITE certificate's temporal fingerprint gives each key a mathematically unique issuance proof. The paper has received 4,000+ downloads on Zenodo in under 8 months — exceptional for a physics preprint.

📑 DOI: 10.5281/zenodo.15825138  ↗
Responsible Disclosure

Security contact

If you discover a security vulnerability in the Zeq.dev platform, API, or key infrastructure, please report it responsibly. We commit to acknowledging receipt within 24 hours and resolving critical issues within 72 hours.

✉ info@hulyas.org