1. Scope and Status

This specification describes the OMEGA reference implementation. It defines normative behavior for interoperability and informative behavior for operational security. The document is versioned v1.1 and reflects the audited, remediated codebase.

2. System Architecture

OMEGA consists of three logical parties connected by a single transport channel:

The relay's identity is volatile: a fresh .onion address is generated on every boot and previous key material is destroyed. The relay binds to 127.0.0.1:3000 by default; Tor publishes the hidden service.

3. Identity and Key Management

// 3.1 Master identity

A one-time keygen step generates an RSA-4096 master key pair:

master_private.enc is protected with a user passphrase via PBKDF2 (600,000 iterations) + AES-256-GCM. The passphrase is irrecoverable: loss of the passphrase permanently destroys the identity.

// 3.2 Ephemeral session material

The client and the operator each generate an ephemeral ECDH P-256 key pair per session. The shared secret is computed locally on both ends and never transits the relay.

4. Transport and Frame Format

All traffic — signals and noise — travels as fixed 4096-byte binary frames over a single WebSocket connection:

A client MUST send constant-size noise frames on a random interval (1–6 s) while connected. The relay MUST drop frames whose length field is zero or greater than 4092. Every frame must be exactly 4096 bytes on the wire.

5. Wire Protocol

Messages are JSON objects with a type field. The following message types are normative:

// 5.1 Session lifecycle

A session is identified by a 128-bit random sessionId (32 lowercase hex). The relay accepts at most 2 concurrent connections per session and expires sessions after 1 hour. A client MUST complete the ECDH exchange within 5 s of the handshake or the relay closes the connection.

CLIENT            RELAY             OPERATOR
  |  HANDSHAKE(sid)  |                 |
  |---------------->|                 |
  |  HANDSHAKE_ACK   |                 |
  |<----------------|                 |
  |  ECDH_EXCHANGE   |  ECDH_EXCHANGE  |
  |  pubKey (C)      |---------------->|
  |                  |  ECDH_EXCHANGE  |
  |                  |<----------------|
  |  ECDH_EXCHANGE   |  pubKey+sig (A) |
  |<----------------|                 |
  |        E2EE derived locally         |
  |        (relay never sees secret)   |

6. Cryptographic Construction

// 6.1 Message key derivation

The AES message key is derived in two stages, identical on the client worker and the operator:

// Stage 1 — PBKDF2: brute-force resistance
pbkdfBits = PBKDF2(password=token, salt=sessionId, iters=600000, sha256, 256);

// Stage 2 — HKDF: binds the ephemeral ECDH secret (PFS)
hkdfSalt  = ecdhSecret || zeroes(32);
msgKey    = HKDF(ikm=pbkdfBits, salt=hkdfSalt, info="omega-v1-msg-key", sha256)
            -> AES-GCM 256, non-extractable

A hard failure occurs if the ECDH secret is absent at worker initialization (SEC_FAULT_NO_ECDH). No message key is ever derived without the ephemeral secret.

// 6.2 Domain separation

All RSA signatures are bound to their purpose with a domain prefix, preventing cross-protocol signature reuse:

// Admin authentication (VULN-03 mitigation)
signedNonce  = "OMEGA_ADMIN_AUTH:" + nonce;

// ECDH public key authentication (H3)
signedKey    = "OMEGA_ECDH:" + sessionId + ":" + publicKeyHex;

// Replay to another session fails on the sessionId component.

7. Access Control and DoS Resistance

// 7.1 Admin authentication

The admin route is a rotating HMAC path derived from a daily/hourly nonce:

dayNonce   = floor(now / 86400000);
hourNonce  = floor(now / 3600000);
adminPath  = HMAC-SHA256(secret, dayNonce + ":" + hourNonce + ":" + serverNonce);
// The previous hour's path is accepted to avoid logout at hour rollover.

Authenticating as admin requires completing adaptive PoW, then signing a challenge nonce with the RSA-PSS master key. Admin assets are served only via the token route — never as static files — and are integrity-pinned with CSP, SRI, and a Service Worker pin.

// 7.2 Proof of work

PoW is adaptive to connection load. Difficulty is the number of leading zero bits of SHA-256(nonce + challenge):

PoW is required before the admin challenge, before INIT, and before client-initiated vault writes. Challenges expire after 60 s; the message rate is limited to 50 frames per 10 s per socket.

8. Vault and Persistence

The vault stores only ciphertext records with minimal metadata. Records are truncated to the most recent 5000 and purged every 24 hours, or on admin command (PURGE).

{
  "id":   "<16 random bytes hex>",
  "type": "ASYNC_MSG | SERVER_MSG | BROADCAST",
  "payload": "<base64 AES-GCM ciphertext>",
  "ts":   "<epoch ms>"
}

Vault writes are coalesced with a 1-second write-behind to prevent disk amplification under load. On shutdown, the vault is flushed before the process exits.

9. Operational Parameters

10. Security Properties