Skip to main content

Zeq Mail

A complete webmail surface — register, log in, send, read. Stored fields are encrypted at rest with AES-256-GCM, and every delivered message records the exact Zeqond at which it was sent, so the send is auditable on the entangled state.

  • Live app → /apps/mail/
  • Source → shared/api-core/src/routes/mail*.ts + shared/api-core/src/lib/zeqField.ts
  • Construction → session-token auth · AES-256-GCM at-rest field encryption · Zeqond-stamped sends
  • At rest → zeqEncryptRecord (AES-256-GCM, per-field IV)

What it actually does​

Zeq Mail is a working webmail app, not a novel cipher. The construction:

  1. Accounts — register / login issue a session token; subsequent calls authenticate with Authorization: Bearer <token>.
  2. Encryption at rest — stored message fields and contact PII are encrypted with AES-256-GCM before they touch the database, via the zeqEncryptRecord primitive (a fresh 96-bit IV per field, so there's no GCM nonce reuse across records). The plaintext is never stored.
  3. Zeqond stamp — each delivered message records the zeqond and phase it was sent at and publishes a hash-only event to the entangled state. This is an auditable send-time record — it does not gate delivery or substitute for the cipher's integrity.

Confidentiality at rest is AES-256-GCM under the framework master key. Transport security is ordinary TLS. The Zeqond stamp is metadata for the audit trail.

The construction, step by step​

StageMechanismStandard
Authsession token (Bearer) issued at register/login—
At-rest encryptionAES-256-GCM, per-field random IV (zeqEncryptRecord)NIST SP 800-38D
Send auditzeqond + phase stamp → hash-only event on the entangled stateSHA-256 (FIPS 180-4)
TransportTLSRFC 8446

Runnable worked example — register, send, receive​

Zeq Mail is a full end-to-end webmail app with its own authenticated API under /api/mail/*. You register an identity, log in, then send and read mail — each message sealed and stamped with the zeqond it was sent at.

# 1. Register a mail identity
curl -s -X POST https://zeqsdk.com/api/mail/register \
  -H "Content-Type: application/json" \
  -d '{ "username": "zeq", "password": "…" }'

# 2. Log in → returns a session token
curl -s -X POST https://zeqsdk.com/api/mail/login \
  -H "Content-Type: application/json" \
  -d '{ "username": "zeq", "password": "…" }'

# 3. Read the inbox (Bearer the session token from step 2)
curl -s https://zeqsdk.com/api/mail/inbox \
  -H "Authorization: Bearer $MAIL_TOKEN"

Each delivered message carries the zeqond and phase it was sent at, so the send is anchored to the HulyaPulse cadence on the audit trail. The full send / inbox / sent / contacts surface is exercised in the live app — open it from the App Store and drive the flow end to end.

Extend it​

  • At-rest field hardening: every PII field uses its own random IV via zeqEncryptRecord, so a leaked database row never exposes plaintext.
  • Envelope wrap: pair with HITE Encryption to AES-256-GCM-wrap an attachment before sending it.
  • Auditable sends: the Zeqond-stamped, hash-only send event lets you prove when a message was sent without storing its body in the clear anywhere extra.

Seeds​

  • Master-key rotation: stored fields re-encrypt under a rotated ZEQ_FIELD_KEY (old key in ZEQ_FIELD_KEY_PREV) with zero downtime.
  • Mesh delivery: route peer-to-peer rather than through a centralised SMTP, while keeping the same at-rest encryption.
  • Post-quantum at rest: AES-256-GCM is a sound long-term choice for confidentiality; no envelope-format change needed.

Papers​

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