1. Threat Modeling

// 1.1 Why the threat model comes first

The README asserts two properties: "relay blindness" and "zero-knowledge." Neither is meaningful until you specify the adversary. A vulnerability finding is only actionable relative to a concrete attacker with concrete capabilities. Auditing against "everything possible" produces a report of unsorted paranoia instead of a prioritized remediation list. So before reading a line of crypto code, the adversary was fixed in writing.

// 1.2 Adversary capabilities

The adversary model used is an Extended Dolev-Yao model — an active and passive adversary with network control, not a passive eavesdropper. Four concrete parameters:

The 30% figure is not arbitrary: it is the standard threshold used in onion-routing anonymity research to model an adversary who can plausibly compromise a meaningful fraction of a circuit's nodes.

// 1.3 Deployment scenarios

The same codebase has different security properties depending on where it runs. This matters because it changes what a finding actually means:

The "zero-trust" claim only holds under (a) with a benign operator. This is stated explicitly up front so the findings are not misread as applying uniformly to all three deployments.

// 1.4 Exclusions

These are stated so the reader can assess whether the audit's scope matches their own threat model.

2. Whitebox Static Analysis

// 2.1 Reading the code

Static analysis gives full visibility into the code, which can obscure architectural defects behind an apparent completeness. Three systematic checks were applied:

// 2.2 H2 — Admin code served without integrity check

The admin panel is a web page served by the same relay that hosts the chat. The entry point:

<!-- src/admin.html, line 170 -->
<script src="admin-client.js"></script>

The <script> tag has no integrity attribute. There is no Subresource Integrity (SRI) hash binding admin-client.js to a value the browser trusts.

The project has an integrity mechanism, but it is incomplete and circular. GOLD_HASH.txt stores a SHA-512 hash, but it covers only omega-worker.js — the crypto worker — not the admin UI. Worse, the client fetches that hash from the same relay it is supposed to be verifying. The relay is both the thing being verified and the source of the verification data. This is a circular trust anchor.

Why static analysis is where this surfaces. The crypto primitives (RSA-PSS, AES-GCM) are correct. The defect is in the supply chain: a relay should not serve the code that is used to verify the relay's claims.

// 2.3 H3 — ECDH keys are not authenticated

Client and operator agree on ephemeral ECDH keys at the start of a session. These keys are supposed to prove the other party's identity:

// client.js
const pubKey = frame.publicKey;  // sent by the server
// used directly to compute the shared secret
// never verified against the operator's long-term key

The key arrives on the wire without a signature, a fingerprint, or a nonce binding it to the session. There is no Trust-On-First-Use (TOFU) step: no fingerprint is displayed, nothing for the user to confirm manually.

Severity framing. The attack is a silent MITM: it produces no failure and no warning. That is what makes it high severity — not just that it is possible, but that it is undetectable by design.

// 2.4 Rating findings in context

Severity is not a property of the code alone. It depends on exploitability, impact, and the deployment context.

Example — H1: server_secrets.enc in plaintext. server_secrets.enc stores the admin HMAC secret in plaintext JSON. In isolation that reads as HIGH. In context:

The finding is downgraded to MEDIUM. It is still a defect — secrets should not sit on disk in plaintext — but it does not, on its own, elevate the attacker's capability in any realistic scenario.

3. Verification in Live Traffic

// 3.1 Why blackbox

Static analysis states what the code claims. Live capture states what the server actually does. When the two disagree, that discrepancy is data: it reveals undocumented code paths, environment-specific behavior, or mitigations that live outside the code (a reverse proxy, a WAF, a TLS termination point). Static and blackbox are both incomplete; only comparing them is complete.

// 3.2 Lab setup

Separate machines, not localhost, so the relay is observed as a remote service over the actual network path, not through the loopback interface where behavior can differ. Capture was passive: download assets, observe WebSocket frames, and cross-check against the code. No frames were modified and no session was actively hijacked during capture.

// 3.3 H2 confirmed in traffic

The admin assets were downloaded and hashed:

GOLD_HASH.txt (server):   d794bcc6bc37ebe593cd2c0f366da52b...
omega-worker.js (actual): d794bcc6bc37ebe593cd2c0f366da52b...   # match
admin-client.js (actual): 7f0e0fb783...                         # NOT covered by GOLD_HASH

admin.html on the wire carried no integrity attribute. The static analysis conclusion holds on the live service: the admin UI is served without a verifiable integrity anchor, and the only existing hash does not cover it.

// 3.4 H3 confirmed in traffic

The server's ECDH_EXCHANGE frame, captured from the wire:

{"type":"ECDH_EXCHANGE","publicKey":"1c64c6e3...","signature":null}

The public key travels unsigned. A grep of the client bundle for crypto.subtle.verify finds it only in the ADMIN_AUTH path — never in the ECDH handshake. There is no code path that authenticates the key before the shared secret is derived.

// 3.5 M4 — Session hijacking confirmed

A random, never-registered sessionId was sent in a handshake:

{"type":"HANDSHAKE","sessionId":"3ecc60724c654fc039b98ec38e8044ca"}
> {"type":"HANDSHAKE_ACK"}

No cookie, no token, no proof of possession, no binding of the session identifier to any key. The sessionId is a self-declared value.

4. Root Cause

The design goal was a stateless relay: clients and operator share the same protocol code, and the relay simply forwards ciphertext. The implicit design shortcut was to authenticate nothing and rely on encryption alone — the reasoning being "if the relay cannot read the ciphertext, it does not matter whether it is trusted."

That reasoning is wrong at one specific point: a compromised relay substitutes code and keys before the ciphertext is produced. Integrity and authenticity must be established before encryption begins, and they cannot be delegated to the entity being authenticated.

The contradiction is then visible: the README declares a zero-trust relay, but the implementation assumes a trusted operator. Zero-trust means no assumptions; this code assumes control of the host.

5. Remediation

// 5.1 Admin panel integrity (H2) — five layers

A single verification layer would be a single point of failure. The fix layers five independent controls; an attacker must break all five, not one.

Content-Security-Policy: default-src 'none';
  script-src 'self' blob:;
  connect-src 'self' ws: wss:;
  style-src 'self';
  base-uri 'none'; form-action 'none'; frame-ancestors 'none'

<script src="admin-client.js"
        integrity="sha512-__HASH_ADMIN_CLIENT__"
        crossorigin="anonymous"></script>

// admin-sw.js
const PINNED = {
  'admin.html':        'sha512-__HASH_HTML__',
  'admin-client.js':   'sha512-__HASH_CLIENT__',
  'master_public.pem': 'sha512-__HASH_PEM__'
};
self.addEventListener('fetch', e => {
  const name = new URL(e.request.url).pathname.split('/').pop();
  if (!PINNED[name]) return;
  e.respondWith((async () => {
    const resp = await fetch(e.request);
    const buf = await resp.arrayBuffer();
    const digest = await crypto.subtle.digest('SHA-512', buf);
    const hex = [...new Uint8Array(digest)].map(b => b.toString(16).padStart(2,'0')).join('');
    if (hex !== PINNED[name].replace(/^sha512-/, '')) {
      return new Response('INTEGRITY FAILURE', { status: 500 });
    }
    return new Response(buf, resp);
  })());
});

app.get('/:token', (req, res, next) => {
  if (isValidAdminPath(req.params.token))
    return res.sendFile(path.join(__dirname, '../admin/admin.html'));
  next();
});

An attacker must defeat CSP, SRI, the Service Worker pin, the route separation, and the operator's offline record simultaneously. Breaking any single layer is insufficient.

// 5.2 Sign the ECDH key (H3)

The operator signs their ephemeral ECDH public key with their long-term RSA private key, using a domain-separated string that binds the key to the session:

// Admin's browser
signature = RSA_PSS_sign('OMEGA_ECDH:' + sessionId + ':' + publicKeyHex, masterPrivateKey);

// Client side, before deriving the shared secret
ok = RSA_PSS_verify(masterPublicKey, signature, 'OMEGA_ECDH:' + sessionId + ':' + publicKey);
if (!ok) throw 'ECDH_AUTH_FAIL';

The domain prefix OMEGA_ECDH: prevents the signature from being reused in another protocol context that shares the same long-term key. Two properties follow:

The relay does not need to understand the signature — it only forwards it as opaque bytes.

// 5.3 Bind sessionId to the ECDH key (M4)

The session identifier is bound to the client's ECDH public key by a fingerprint:

fp = SHA256(clientEcdhPublicKey);
sessionEcdhFp.set(sessionId, fp);

On a second registration of the same sessionId with a different key, the server rejects it:

const prior = sessionEcdhFp.get(sessionId);
if (prior && prior !== fp) return ws.close(1008, 'SESSION_KEY_MISMATCH');
sessionEcdhFp.set(sessionId, fp);

Once a session is bound, its ECDH key is locked. Substitution and hijacking both fail.

6. Report Structure

// 6.1 Sections

The final report followed six sections so each finding is auditable end to end:

// 6.2 Severity calibration — the M5 example

M5 (vault write amplification) was first written as "500 writes per second, the vault file is rewritten entirely on each message." Before rating it, context was checked:

The finding was rated MEDIUM — an availability issue under specific conditions — rather than HIGH, which would have implied a compromise of a core security property.

// 6.3 Residual risk documentation

Post-remediation risks are listed rather than hidden:

Documenting residuals does three things: it confirms the threat model was actually applied, it prevents a false sense of completeness, and it feeds the remediation roadmap.

7. Notes

8. Verdict and Recommendations

// 8.1 Verdict

The cryptographic implementation is correct. The PFS (Perfect Forward Secrecy) property holds: even if the relay is compromised, messages recorded before the compromise remain encrypted, because the session tokens are wrapped in RSA-OAEP and the ephemeral ECDH secrets never cross the relay.

The "zero-trust against the relay operator" claim does not hold. The system required trust in three things the claim said it would not:

Post-remediation these are addressed, with three conditions: deployment (a) self-hosted with a benign operator is the only scenario that justifies use; (b) VPS requires additional monitoring; (c) onion adds anonymity but does not change the host's trust level. TOFU on the first visit remains; it is inherent to a web-based admin model. PQC is pending: ECDH P-256 and RSA-4096 remain vulnerable to a quantum computer.

// 8.2 Deployment recommendations

// 8.3 For developers of E2EE systems

Appendix: Findings Matrix

Findings audited: 22 · Remediated: 21 · In roadmap: 1

Verification Summary

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