Independent Pi/OpenRouter review: z-ai/glm-5.3-flash

Source: a10323dede4413fbf295916b8ad12e3dbad7514e. Status: completed.

Independent Security Review: timelock-proxy v2 (a10323dede4413fbf295916b8ad12e3dbad7514e)

Executive Summary

Two properties are assessed against the stated adversary model (malicious operator/host/front-end, trusted AWS/Nitro, trusted RandomX primitive, trusted client verifier):

Neither verdict is a proof of impossibility. Both are conditional on the enclave implementation being free of exploitable bugs and practical side channels — an assumption the code cannot demonstrate by itself.

Q-A: Content Confidentiality Before Delay

Attack surface inventory

An in-scope adversary (host, parent, Cloudflare, network) observes and controls:

• Outer HTTP relay traffic (/relay?reqid=...&payload=base64(tls_record))
• vsock byte streams to the enclave
• Storage of encrypted artifacts
• Network connections made by the enclave (via CONNECT tunnel)

The adversary does not directly read enclave memory, enclave TLS plaintext, or enclave NSM responses.

Code-grounded confidentiality mechanisms

1. Inner TLS termination in enclave (v2_main.rs:181–197) The enclave listens on vsock 8443 (or dev TCP), terminates TLS with a fresh ephemeral P-256 key generated per boot (tls.rs:69–70). All request/response bytes traverse this TLS session. Host sees only TLS ciphertext.

2. Upstream TLS verified in-enclave (net.rs:110–154) DNS is resolved in-enclave via DoH over TLS to pinned IP resolvers (dns.rs:188–193). Connection goes through the parent's CONNECT tunnel (transport.rs:135–141), but TLS certificate verification uses webpki_roots::TLS_SERVER_ROOTS against the real hostname (net.rs:58–59). ECH is used when available (net.rs:77–92). Without a relay, the parent sees destination IP and (absent ECH) SNI — acknowledged in threatmodel.md §6.

3. Record encryption before publication (v2_proxy.rs:98–107) The audit record (request URL, response status, headers, body, trailers) is serialized to canonical CBOR, encrypted with XChaCha20Poly1305 under a key derived via HKDF from the epoch key and the manifest ID (timelock/src/lib.rs:81–91). Only ciphertext is published to the parent (v2_proxy.rs:107). The response is not returned to the client until the record is persisted (30s timeout with 3 retries, v2_proxy.rs:107; parent ACK required, v2_epoch.rs:64–66).

4. Static-only diagnostics (v2_diagnostics.rs) Every log call uses a &'static str (v2_diagnostics.rs:33). The e2e test (test_v2_e2e.py:338–339) asserts that request URLs and response bodies do not appear in host-received diagnostics. Error paths in v2_main.rs:130 suppress any nested error context.

5. No plaintext record on persistence failure (v2_proxy.rs:107 + e2e test 287–292) If the parent refuses the record write, the client receives a 502 error, not the upstream body. The upstream has already been contacted, but no plaintext record or response escapes.

Metadata that IS leaked (by design, not concealed)

• Outer request sizes/timing reveal approximate TLS record sizes and timing
• The host sees artifact names ({sha256-of-ciphertext}.record.json) via the x-attested-relay-record header (v2_proxy.rs:116) and the public artifact index
• Record file size approximates response body size (within CBOR + AEAD overhead)
• Without Mullvad relay and ECH, the parent sees the upstream IP and SNI
• Session timing and count are observable via the relay protocol

These are acknowledged in threatmodel.md §6 and do not constitute content recovery. I find no code path that converts any of this metadata into content plaintext.

Findings

Conditional guarantees for Q-A

I would state SUPPORTED CONDITIONALLY with the following conditions explicitly:

1. The enclave implementation (Rust + native FFI + TLS + HTTP parsing) contains no exploitable vulnerability that allows an adversary to read enclave memory or intercept plaintext before encryption.
2. Timing/cache side channels in the enclave do not allow practical content recovery from an adversary who controls the parent.
3. The XChaCha20Poly1305 primitive with per-record random 24-byte nonces provides the assumed security level.

These are not proven; they are the assumptions under which the code produces the claimed property.

Q-B: Early Epoch-Key Recovery / Pre-Solved Puzzle

Chain structure

The puzzle is a 7-segment sequential chain (timelock/src/lib.rs:287–398):

seed_1 (published in manifest)
   ↓ 43.7M iterations of RandomX (strictly dependent chain)
y_0
   ↓ HKDF → ChaCha20Poly1305 unwrap wrapped_keys[0]
seed_2 (secret until y_0 is computed)
   ↓ 43.7M iterations
y_1
   ↓ unwrap wrapped_keys[1]
seed_3
   ...
   ↓ segment 6 output y_6
epoch_key (decrypts all records)

Only seed_1 is published in the clear (timelock/src/lib.rs:361). Seeds 2–7 and the epoch key are AEAD-wrapped under keys derived from prior segments' RandomX outputs (timelock/src/lib.rs:365–387). The AEAD authentication tag means an adversary cannot verify a guessed y_i without computing the full chain.

Generation vs solving parallelism

• Generation (enclave): 7 threads, one per segment, running in parallel (timelock/src/lib.rs:327–351). Each segment takes ~43.7M / 506.6 hashes/s ≈ 86,400s ≈ 24h. Total wall-clock: ~25.14h (calibrated on c9g.4xlarge).
• Solving (external): Only seed_1 is known. Must solve segment 0 (~24h sequential), then decrypt seed_2, then solve segment 1 (~24h), etc. Total: 7 × 24h = ~7 days sequential work on one core.

This is the intended gap: 25h to generate, ~168h to solve from publication. The gap is ~6 days.

Key lifecycle and publication ordering (v2_epoch.rs)

The run() function (v2_epoch.rs:104–151):

loop {
    generate (25h, blocking)
    wait for publication_not_before (old epoch's expiry, trusted NSM time)
    clear active epoch
    activate (60s timeout):
       attest → publish attestation → publish puzzle → publish bundle → set active
    set publication_not_before = new epoch's expiry
}

Key properties verified in code:

1. The puzzle is published BEFORE activation (v2_epoch.rs:88 vs 99). No request can use a key whose puzzle hasn't been disclosed.
2. publication_not_before prevents the next epoch from starting before the current one's lifetime ends (v2_epoch.rs:110, 133–140). Even if the host delays the puzzle ACK, the next epoch can't start early.
3. The 60s timeout on activate() (v2_epoch.rs:144) bounds the host's ability to stall. If the host withholds the puzzle ACK for >60s, activation fails and the enclave closes (v2_epoch.rs:146).
4. The ensure!(active.accepts(now), "published candidate expired before activation") (v2_epoch.rs:98) prevents activation if the epoch's wall-clock lifetime has already been consumed during the delayed ACK window. The e2e test (test_v2_e2e.py:345–361) verifies that a delayed ACK causes fail-closed rather than rebasing.

Attack scenarios analyzed

S-1: Host replays an old puzzle manifest No code path accepts an external manifest. generate_with_rng() is the only puzzle creation function; it uses NSM entropy for all seeds and the epoch key. The enclave's activate() only consumes GeneratedPuzzle from its own generation. Blocked.

S-2: Host causes enclave to encrypt under a pre-known key The epoch key is generated with NSM entropy (timelock/src/lib.rs:320–321 calls fill() which calls attester.fill_random() in v2_main.rs:122–125). The parent cannot influence NSM entropy (AWS is trusted). Blocked under the AWS-trust assumption.

S-3: Host intercepts the epoch key during generation The epoch key is held in Zeroizing<[u8; 32]> inside GeneratedPuzzle. It is used to derive the record key (inside encrypt_record, timelock/src/lib.rs:81–91) and stored in the Epoch struct. It is never serialized or sent over any channel. The host sees only the signed manifest and encrypted records. Blocked by Nitro isolation assumption.

S-4: Host kills enclave between generation and publication, then restarts enclave The enclave's signing key is ephemeral per boot (v2_main.rs:169–172). A restarted enclave has a different signing key. Old puzzles are signed with the old key; clients verify the signing key against the current attestation's service_signing_public_key (v2_proxy.rs:85, archive.py:139–140). A replayed old puzzle would fail signature verification against the new attested key. Blocked.

S-5: Host replays old records from a previous epoch Records are bound to epoch and puzzle_id via AEAD AAD (timelock/src/lib.rs:73–80). A record from epoch N cannot be decrypted with epoch N+1's key, and vice versa. Blocked by AEAD authentication.

S-6: Host uses fast hardware to solve the puzzle early This is the assumed RandomX primitive strength (per the review brief). Each segment is 43.7M sequential RandomX hashes. Even with faster hardware, the chain is strictly sequential within each segment, and segments are sequential across the chain (only seed_1 is published). No code-path parallelism exists for an external solver. Assumed blocked by RandomX assumption.

S-7: Host obtains seeds or intermediate values via side channels Not ruled out by code. Timing or cache side channels during RandomX evaluation inside the enclave could potentially leak intermediate state. This is explicitly a review target (threatmodel.md §5). INSUFFICIENT EVIDENCE — no side-channel countermeasure is implemented in application code.

S-8: Sequence counter reuse / nonce collision The sequence counter is AtomicU64 per epoch, monotonically increasing (v2_proxy.rs:87, 122–125). It never wraps (checked_add, v2_proxy.rs:123). XChaCha20Poly1305 nonces are random 24 bytes per record (OsRng.fill_bytes, timelock/src/lib.rs:103–104). With a 24-byte random nonce, collision probability is negligible for any realistic number of records. Blocked.

S-9: Host replays a checkpoint to skip work Checkpoints are local solver state (client-side), not enclave state. The enclave never reads checkpoints. This doesn't affect the enclave's key lifecycle. Not applicable to Q-B.

S-10: Host makes the enclave use a stale dataset_key The dataset_key is generated fresh with NSM entropy per generation (timelock/src/lib.rs:312–313). It's published in the manifest, which the enclave signs. An adversary cannot substitute a different dataset_key without breaking the Ed25519 signature over the canonical manifest bytes. Blocked.

Key erasure and lifetime bounds

The expiration_watchdog (v2_epoch.rs:40–52) runs every 100ms and clears the active epoch reference when monotonic time exceeds the lifetime. Existing request leases hold Arc<Epoch> clones, so the key survives until those leases drop (bounded by the 30s record-publish timeout). After all leases are released, the Epoch (and its Zeroizing<[u8; 32]> key) is dropped. Zeroizing wipes on drop.

However, Zeroizing only zeroes the Rust-managed buffer. Copies of the key may persist in:

• CPU registers or cache during RandomX/AEAD computation
• Compiler-spilled stack slots (LLVM may spill constants to stack)
• Kernel page cache (if the enclave's memory is swapped — Nitro enclaves don't swap by default)

The threat model (§5) explicitly acknowledges this: "This is not proof of erasing every compiler, allocator, library, kernel or hardware copy."

Findings for Q-B

Conditional guarantees for Q-B

SUPPORTED CONDITIONALLY under:

1. RandomX primitive is strong: no shortcut to evaluate 43.7M dependent iterations faster than sequential computation
2. Enclave memory is not readable by the parent (Nitro isolation)
3. NSM entropy is trusted (AWS trusted)
4. Ed25519 signing key is unforgeable
5. XChaCha20Poly1305 authentication prevents substitution of wrapped seeds or records

The code does not provide a side-channel countermeasure; the assumption of "no exploitable side channel" is a separate claim not demonstrated by this code.

Missing Evidence / Unresolved Questions

1. Full-duration production generation has not been observed end-to-end. The 25.14h estimate comes from calibration on the same hardware type. Whether rollover, key publication, and offline recovery work at production scale remains unverified (threatmodel.md §7).

2. Per-record origin binding is absent. Individual encrypted records are not signed by the enclave. Once the epoch key is public, anyone can forge a valid-looking record for that epoch. The threat model acknowledges this (§5, §7). This limits post-release provenance.

3. Storage durability depends on an untrusted ACK. The enclave treats the parent's OK\n as proof of persistence (v2_epoch.rs:64–66). The parent can lie. Object Lock is not enabled on the S3 copy (threatmodel.md §7). Records may be lost.

4. The RandomX FFI surface has not been independently audited. randomx_calculate_hash is called with attacker-controlled-length inputs (up to input.len() bytes of the concatenated epoch/segment/iteration/x data, timelock/src/lib.rs:238–245). The input length is always DOMAIN.len() + 8 + 4 + 8 + 32 = 16 + 52 = 68 bytes (fixed), so there's no variable-length attack surface in the hash input itself. But the C library's internal memory management is unreviewed here.

5. The --dev flag is accepted by the production binary (v2_main.rs:119). If --dev were passed in production, hardware verification would be skipped, NSM would be replaced by OS RNG, and the enclave would use dev-mode random TLS keys. The code does gate hardware verification (ensure!(config.require_graviton5, ...) at v2_main.rs:142), but the --dev flag itself bypasses the Attester::new(dev) check. An operator running with --dev would have a service that provides no attestation and uses OS randomness. The Python client requires allow_dev=True for dev endpoints, and dev endpoints must be loopback. So this is gated for clients, but the enclave binary itself would run.

6. No formal verification or fuzzing evidence is presented for the HTTP relay parser (http_relay.rs), the CBOR serialization (v2_proxy.rs:29–33), or the NSM ioctl path (attest.rs:217–233). These parse untrusted input from the parent/network.

7. Post-release provenance of individual records cannot be established without a pre-trusted digest receipt. The x-attested-relay-record header gives the client a SHA-256 of the ciphertext, but proving that ciphertext was actually stored (and not later replaced by a forged one under the same epoch key) requires holding that digest and comparing it to the artifact after recovery.

Would I rely on this for sensitive content?

Under the explicit assumptions stated in the review prompt, yes, with caveats.

The code carefully implements:

• Inner TLS isolation for client↔enclave
• In-enclave upstream TLS with verified certificates
• AEAD-sealed records under an epoch key that requires sequential RandomX work to recover
• Static-only diagnostics that don't leak request content
• A correctly anchored publication-before-activation ordering
• Bounded key lifetime with independent watchdog expiration

The caveats that prevent an unconditional "yes":

1. The conditional nature of the confidentiality: it's temporary (until puzzle is solved), not permanent. This is by design and acknowledged.
2. Metadata leakage (destination IP without ECH, timing, sizes) is inherent and acknowledged but may be unacceptable for some use cases.
3. Implementation risk: No fuzzing, formal verification, or independent native-code audit evidence is presented. A bug in the HTTP parser, CBOR encoder, or NSM ioctl path could potentially leak content or crash the enclave.
4. Storage durability is not independently confirmed. Records could be lost if the parent lies about persistence.
5. Post-release provenance of individual records is not cryptographically bound; a sophisticated adversary could substitute records after the epoch key is public.

For genuinely high-sensitivity content, I would require additional evidence: independent native-code audit, fuzzing results for the relay parser, and an operational storage-verification mechanism before accepting the confidentiality interval as reliable.