Skip to main content

HITE Encryption

Encrypt a payload with AES-256-GCM, get back ciphertext + IV + auth tag, and decrypt it again. Standard authenticated encryption, exposed as a clean two-endpoint API.

  • Live app → /apps/hite-encryption/
  • Source → shared/api-core/src/routes/hite.ts + shared/api-core/src/lib/zeqField.ts
  • Construction → AES-256-GCM · PBKDF2-SHA256 (200,000 iterations) · 96-bit random IV · 16-byte GCM tag
  • Verifies against → NIST SP 800-38D (AES-GCM) and NIST SP 800-132 (PBKDF2) test vectors

What it actually does​

HITE is the framework's at-rest cipher, exposed as an API. It is ordinary authenticated encryption: you hold the key, you can decrypt at any time. The construction:

  1. Key derivation — PBKDF2-SHA256 over a 32-byte master key (ZEQ_FIELD_KEY, required in production) with a fixed, versioned salt string built from the published HULYAS constants (f=1.287 Hz, τ=0.777 s, α=1.29×10⁻³). 200,000 iterations, 32-byte output. The salt string is frozen by construction: changing a single character rotates the key and renders prior V1 ciphertexts undecryptable, so it is treated as immutable.
  2. Encryption — AES-256-GCM with a fresh random 96-bit IV per call. The 16-byte GCM authentication tag is computed over the ciphertext; decryption that fails the tag check is rejected (code: DECRYPTION_FAILED). This is what guarantees integrity — not any clock.
  3. Zeqond stamp — each response records the zeqond and phase the call ran at, and publishes a hash-only kernel event to the entangled state. This is metadata for auditability, not a decryption gate: the ciphertext can be decrypted at any later time given the key.
  4. Landauer certificate — each encrypt returns the thermodynamic minimum energy to erase the input (E_min = k_B · T · ln 2 · bits, Landauer's principle). This is a real physics fact reported for interest; it is not part of the cipher.

The cipher's security rests entirely on AES-256-GCM and the secrecy of the master key. The HulyaPulse cadence anchors when an operation happened and seeds the KDF salt — it does not, and is not claimed to, add cryptographic strength on its own.

TESC — temporal-bound channel tags​

The same route file exposes POST /api/tesc/send, a channel primitive that attaches a Phase-Locked Authentication Tag (PLAT): an HMAC-SHA256 keyed by sha256("TESC." + channelId + "." + zeqond) over the channel, Zeqond, phase, and a ciphertext prefix. The tag is scoped to a single Zeqond window, so a relayed message is only authenticatable for ~0.777 s — a genuine, classical temporal-binding feature built from HMAC, not physics.

The construction, step by step​

StageMechanismStandard
Key derivationPBKDF2-SHA256, 200,000 iterations, frozen HULYAS-constant saltNIST SP 800-132
EncryptionAES-256-GCM, fresh 96-bit IV per callNIST SP 800-38D
Integrity16-byte GCM authentication tag (verified on decrypt)NIST SP 800-38D
AuditZeqond + phase stamp → hash-only kernel event on the entangled stateSHA-256 (FIPS 180-4)

Runnable worked example — encrypt + decrypt​

HITE encryption is exposed as two authenticated endpoints — POST /api/hite/encrypt and POST /api/hite/decrypt. Both take a Bearer API key (zsm_…) for your machine.

# 1. Encrypt a payload
curl -s -X POST https://zeqsdk.com/api/hite/encrypt \
  -H "Authorization: Bearer $ZEQ_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "plaintext": "the envelope is sealed" }'

The response is the HITE envelope:

{
  "protocol": "HITE",
  "version": "2.0",
  "ciphertext": "…",
  "iv": "…",
  "tag": "…",
  "algorithm": "AES-256-GCM",
  "keyDerivation": "PBKDF2-SHA256, 200,000 iterations",
  "zeqond": 2289605442,
  "phase": 0.7012,
  "encryptedAt": "…"
}
# 2. Decrypt — pass back ciphertext, iv, and tag
curl -s -X POST https://zeqsdk.com/api/hite/decrypt \
  -H "Authorization: Bearer $ZEQ_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "ciphertext": "…", "iv": "…", "tag": "…" }'

The decrypt response returns { "plaintext": "the envelope is sealed" }. Every encrypt also stamps the zeqond and phase it ran at, so the operation is anchored to the HulyaPulse cadence and shows up on the entangled state. Decryption succeeds whenever you hold the correct ciphertext, IV, and tag — the stamp is a record of when it was sealed, not a lock on when it can be opened.

Extend it​

  • At-rest field encryption — the same zeqEncryptRecord primitive encrypts PII fields (name, email, message) before they hit the database, each with its own fresh IV to avoid GCM nonce reuse.
  • TESC channel tags — wrap a relayed message with a POST /api/tesc/send PLAT so its HMAC-SHA256 authentication tag is only valid for one Zeqond window.
  • Audit-chained ciphertext — every encrypt/decrypt publishes a hash-only event to the entangled state, so the fact of the operation is tamper-evident even though the plaintext is never stored.

Seeds​

  • Key rotation — ZEQ_FIELD_KEY_PREV lets you decrypt under the old key while encrypting under a new one, so you can roll the master key with zero downtime.
  • Forensic timestamping — because each operation is Zeqond-stamped and hash-linked, you get an auditable record of when a payload was sealed without trusting a central time server.
  • Domain-separated keys — the frozen, versioned salt string keeps the HITE key cryptographically distinct from other framework key contexts.

Papers​

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