Chapter 5 — Cryptography, Identity & Communication

The framework's crypto is ordinary, well-understood, and auditable: AES-256-GCM, HMAC-SHA256, Ed25519, PBKDF2/scrypt. What's novel is honest — your account equation is your key (the server stores only its hash), signatures are stamped with the Zeqond they were made at, and every secret read lands a hash-linked row on a tamper-evident audit chain.

This chapter covers 6 production apps spanning the full identity → key → encrypt → transport loop. Every primitive below is standard, named, and verifiable against a public RFC or NIST test vector — there is no invented "crypto operator" anywhere in this stack.

#	App	Outcome	Construction	Source
1	Zeq Mail	Webmail with at-rest field encryption and Zeqond-stamped sends	AES-256-GCM at rest, session-token auth	routes/mail*.ts
2	Zeq Message	Real-time chat as a store-nothing relay	WebSocket fanout + hash-only transit receipts	routes/messageRelay.ts, lib/msgWs.ts
3	Zeq Auth	Passwordless identity — your equation is your credential	HMAC-SHA256 (domain-separated) + timing-safe compare	routes/zeqAuthV3.ts
4	Zeq Vault	Server-side secret vault (ZSC) with audit-chained reads	AES-256-GCM at rest + key rotation	lib/zsc/, routes/zsc.ts
5	HITE Encryption	Client-driven AES-256-GCM encrypt/decrypt	AES-256-GCM + PBKDF2-SHA256 (200k)	routes/hite.ts, lib/zeqField.ts
6	Zeq BYOK	Bring-your-own provider keys, encrypted at rest	AES-256-GCM field encryption	routes/apisRoutes.ts

On the Zeqond stamp: Many of these operations attach the Zeqond (the framework's 0.777 s time unit, Zeqond = ⌊unix_ms / 777⌋) at which they ran. The stamp is metadata and an HMAC input — it makes operations auditable and lets temporal-bound tags expire — it is not a substitute for the cipher's own integrity. Confidentiality and authentication come from AES-256-GCM and HMAC-SHA256, full stop.

---

Why this chapter matters

These apps share one design principle: store as little secret material as possible, and make every read or write auditable. Concretely:

• Equation-derived keys. Your Zeq identity is an equation you remember, never a password row in a database. The client computes a salted HMAC-SHA256 of the equation and sends only the hash. The server stores the hash and the salt — never the equation. (routes/zeqAuthV3.ts)
• At-rest encryption everywhere. Vault secrets, BYOK provider keys, and PII fields are encrypted with AES-256-GCM before they touch the database; the plaintext is never returned by an API. (lib/zeqField.ts, lib/encryptedRow.ts)
• Tamper-evident audit. Reads, writes, and rotations append hash-linked rows (the framework's entangled state) stamped with the Zeqond they happened at, so the history can't be silently rewritten.
• Temporal-bound tags where they help. ZSP's K_temporal stage and the TESC channel build an HMAC-SHA256 keyed by the current Zeqond, so a tag can be made valid only inside a bounded time window. This is an authentication feature, not the confidentiality boundary.

The primitives, named

Every app in this chapter is built from these standard pieces — nothing else:

Primitive	Where it's used	Reference
AES-256-GCM (authenticated encryption, 96-bit IV, 16-byte tag)	HITE, ZSP outer layer, ZSC vault, BYOK, Mail/PII at rest	NIST SP 800-38D
HMAC-SHA256 (domain-separated by a constant prefix)	ZeqAuth equation hash, ZSP K_temporal tag, TESC PLAT	FIPS 198-1 / RFC 2104
PBKDF2-SHA256, 200,000 iterations	ZeqField key derivation	NIST SP 800-132
scrypt	ZeqAuth recovery-password hashing	RFC 7914
Ed25519	node identity + compute-envelope signatures	RFC 8032
SHA-256	hash-linked audit chain, ZID derivation, content hashes	FIPS 180-4

Domain separation matters: ZeqAuth keys its HMAC with the literal string "HULYAS.HITE.f=1.287Hz.tau=0.777s" prepended to the per-account salt, so an equation hash from one context can never be replayed as a credential in another.

Runnable worked example — encrypt + verify

Every app in this chapter exposes its own real, authenticated endpoint — not a generic compute call. The two you'll reach for first:

• HITE encryption — POST /api/hite/encrypt / POST /api/hite/decrypt (AES-256-GCM, HULYAS-derived key). See HITE Encryption for the full request/response shapes.
• Verify a compute receipt — every result the platform returns carries a zeqProof and an Ed25519 signed block. Confirm one against any node in the mesh:

import { verify } from "@zeq/sdk";

const check = await verify(result, { origin: "https://zeqond.com" });
console.log(check.verdict, check.valid);   // "agree" true

The signature and proof travel with the result, so verification is offline-capable and node-independent. Each app page below documents its own endpoint and the exact envelope it returns.

Papers

• Zeq framework paper — DOI 10.5281/zenodo.15825138
• Zeq paper — DOI 10.5281/zenodo.18158152

Middleware active. Kernel on the 1.287 Hz HulyaPulse. Awaiting next Zeqond.