Independent model reviews of the confidentiality objective

Date: 2026-09-09. Runtime source: a10323dede4413fbf295916b8ad12e3dbad7514e.

Status: all nine requested models have completed an assessment. All attempts in this panel have finished; incomplete attempts are retained separately. No runtime code was changed for this review.

Question and current assessment

The requested objective is a GET-carried proxy (upstream GET is acceptable for now) whose request and response contents remain confidential from the operator and other intermediaries until approximately one week of public RandomX work. AWS is trusted; the account owner is not. RandomX is assumed to resist shortcuts to the specified dependent computation. Its composition, native integration, secret handling, lifecycle and verification remain review targets.

Most completed reviews support the narrower cryptographic objective conditionally; Gemini and DeepSeek dispute it, with claims assessed below. No concrete path to an epoch key, later seed, terminal output or otherwise hidden plaintext has been identified in the reviewed v2 path. This does not establish that no such path exists. It does not establish seven days of wall-clock secrecy, immunity to content inference, or security against a plaintext recipient voluntarily sharing an exchange.

One native implementation bug was confirmed: seven concurrent RandomX VM creations race on the global AES probe variable. ThreadSanitizer reproduced it. No key disclosure or early-solving impact was demonstrated. It remains unfixed in the reviewed production revision; see finding 5.

Requested panel

The user's corrected shortlist contains nine models: eight through Pi/OpenRouter and GPT-5.6 Sol through Codex. Only these models form this panel. Raw assessments are retained even where the consolidation rejects a claim.

The selection record identifies the exact provider IDs, excluded models from the initial broader batch, and retry directories. Extra outputs already produced before the correction are retained for an honest execution record and excluded from the panel conclusions.

Grounded findings and limits

1. Known content can be inferred from public ciphertext length

Confirmed locally; confidentiality limitation, not key recovery. The enclave serializes the audit record without padding and encrypts it with XChaCha20-Poly1305. The public envelope exposes its ciphertext as hexadecimal (v2_proxy.rs, lines 98–107; timelock/lib.rs, lines 92–123). Ciphertext length is plaintext length plus a 16-byte tag. Known candidates with different lengths can therefore be distinguished before solving.

The local reproducer used the real dev host and enclave binaries, the same request URL and a local authenticated TLS fixture. Four requests alternated between known 32-byte and 1,024-byte response bodies. Their public ciphertext lengths were respectively 466 and 1,795 bytes on both repetitions. No solver or decryptor was invoked. Recorded evidence. This uses synthetic data and does not test Nitro isolation. Other unknown record fields can complicate inference in real workloads; the example establishes a counterexample to a universal claim that contents cannot be inferred.

Direct v2 networking also exposes destination IPs to the parent, DNS questions to the resolver, and often SNI to the parent. Automatically following an HTTPS redirect can promote response content into hostname metadata: for example, Location: https://SECRET.leak.example/. The code follows that hostname through DNS and TLS (v2_proxy.rs, lines 163–195; net.rs, lines 94–153). This redirect observation was checked statically; no production redirect experiment was run.

2. A colluding intended recipient can disclose the exchange immediately

Objective boundary, not an implementation bypass. The intended destination receives the GET URL and knows the response it sends. If it colludes with the operator, it can simply provide both. Trusting AWS and assuming a strong RandomX primitive cannot prevent a plaintext recipient from redistributing plaintext. The original threat model's unrestricted collusion wording did not make this boundary sufficiently explicit. The threat model now states it, alongside the content-inference limit. These documentation changes do not repair or strengthen runtime confidentiality; they describe its scope more accurately.

Malicious destinations still matter as potential attackers of enclave parsers, TLS, redirect handling and other users' secrets. This boundary does not declare their inputs safe or exclude implementation bugs.

There are also explicit trust conditions beyond AWS: the client's verifier and independently obtained measurement pin, ordinary cryptography, and upstream WebPKI authentication. In particular, net.rs builds its upstream TLS roots from webpki_roots::TLS_SERVER_ROOTS. A malicious trusted CA able to issue an accepted certificate for the target, colluding with the parent that routes its traffic, can impersonate that target and receive the request immediately. That does not require breaking AWS or RandomX. The supplied threat model already assumes correct WebPKI authentication; this review cannot establish the stronger literal claim that trusting AWS alone is sufficient. No CA-compromise experiment was performed; this follows from the configured upstream authentication boundary.

3. RandomX strength does not establish a seven-day wall-clock lower bound

Known design limit and missing timing evidence. Generation evaluates seven secret-seeded chains in parallel. The public puzzle releases only the first seed; each terminal output unlocks the next seed and the seventh unlocks the epoch key. That provides a serial dependency under the cryptographic assumptions (timelock/lib.rs, lines 301–397, 438–497).

It does not prevent faster hardware or implementation improvements from performing the required work sooner. Sharing completed work means every adversary benefits from the fastest successful solver. The hardware gate constrains enclave generation; it does not constrain external solver speed. The 43,768,124-iteration setting is calibrated, not a proven timing bound.

The delay begins when the parent first receives the puzzle, not independently for each request. With a 24-hour serving epoch and a solver taking seven days, late requests have about six days remaining. Full-duration production generation, rollover and recovery were not observed as part of this review.

4. The checked lifecycle blocks several obvious early-key strategies

Supporting evidence, not an impossibility proof. Production uses direct, fallible NSM entropy for the epoch key and private puzzle material. The v2 generation path does not accept host-supplied puzzles, seeds or checkpoints. Later seeds and terminal outputs have no identified export path. Chosen valid client requests yield AEAD ciphertext, which is not a key-recovery oracle under the assumed cryptography.

Activation anchors trusted NSM time and monotonic time before the first puzzle write. Delaying a persistence acknowledgement consumes the epoch's lifetime; it cannot start a fresh lifetime for an already disclosed puzzle. Future puzzle generation overlaps the current epoch, but future publication waits for its trusted deadline. Admissions require both clocks to be valid; the expiration watchdog and bounded admitted-request lifetimes limit key retention (v2_epoch.rs, lines 21–35, 76–150).

The live client verifies the AWS signature, exact independently selected PCR0, fresh nonce/time and attested SPKI against the actual inner TLS peer before sending the destination. Altering outer GET transport operations cannot forge valid records inside an established inner TLS connection (client.py, lines 143–180; verify.py, lines 52–142).

5. Confirmed native data race; other native safety remains insufficiently reviewed

Confirmed bug, no demonstrated confidentiality impact. Sol's independent native supplement found a shared non-atomic aesDummy in VmBase::allocate (virtual_machine.cpp, lines 98–116). Every hardware-AES VM loads and writes it as an instruction probe. The application creates seven VMs in concurrent workers. volatile does not make these accesses atomic or synchronized; the C++ execution has a data race.

The reproducer, linked against an otherwise unchanged ThreadSanitizer-instrumented native library, reported concurrent writes to global randomx::aesDummy from VmBase::allocate through randomx_create_vm. Full captured evidence. It uses local AArch64 light/interpreted hard-AES VMs, whose allocation probe is the same as production full/JIT VMs. It does not run the production enclave or show a key/plaintext leak. Symbolizer startup warnings occurred, but the sanitizer identified the function and global by name.

The probe operates on non-secret dummy data before the first hash. The confirmed consequence is undefined native behavior; no concrete crash or confidentiality exploit was established. Serialize VM creation in the wrapper, or synchronize the native probe with std::call_once, then repeat the sanitizer check and native correctness tests before accepting a new measured build. No such fix has been applied to runtime code during this review.

A second harness run serialized only randomx_create_vm calls with a mutex; the same instrumented library then exited successfully without a sanitizer race report. Mitigation-check evidence. This validates a narrow proposed mitigation in the harness; it is not a deployed fix or proof that the native library has no other races.

Reproduce from the repository root using a fresh build directory:

cmake -S vendor/randomx -B .local/randomx-tsan-review -DCMAKE_BUILD_TYPE=RelWithDebInfo -DCMAKE_C_FLAGS='-fsanitize=thread -fno-omit-frame-pointer' -DCMAKE_CXX_FLAGS='-fsanitize=thread -fno-omit-frame-pointer' -DCMAKE_EXE_LINKER_FLAGS=-fsanitize=thread -DCMAKE_POLICY_VERSION_MINIMUM=3.5
cmake --build .local/randomx-tsan-review --target randomx -j 4
clang++ -std=c++17 -g -O1 -fsanitize=thread -fno-omit-frame-pointer -pthread -I vendor/randomx/src reviews/check-randomx-vm-race.cpp .local/randomx-tsan-review/librandomx.a -o .local/randomx-tsan-review/check-vm-race
TSAN_OPTIONS=halt_on_error=1 .local/randomx-tsan-review/check-vm-race
TSAN_OPTIONS=halt_on_error=1 .local/randomx-tsan-review/check-vm-race --serialize

The first run is expected to fail with a data-race report. The second checks the proposed serialization in the harness. A machine without hardware AES exits 77 as a skip; that is not a successful race check.

App-owned key buffers and canonical plaintext use zeroizing owners, but ordinary JSON values, response and TLS buffers, compiler/library copies and native RandomX VM memory are not comprehensively erased. No reachable extraction path for the untrusted parent was demonstrated under trusted Nitro isolation. The absence of a demonstrated path is not evidence that all native memory-safety or microarchitectural attacks have been excluded.

The Pi snapshots include the Rust FFI and native header, not the entire RandomX C++ tree, dependency implementations or kernel. Sol and the consolidating agent followed relevant native allocation/VM/flag code locally. A native full-mode v2 known-answer test passed, but this is not a full native-code security audit. Reproducible measurements establish source-to-image evidence under the stated build trust; they do not establish source safety.

6. Storage and later provenance have separate gaps

A parent's OK\n persistence acknowledgement does not prove durable or public storage. The parent can withhold puzzle publication after receiving it; that does not move the enclave's first-disclosure time anchor, but gives the parent a lead over solvers that only see later public publication. Archived evidence does not independently attest the first public availability time.

The current S3 uploader lacks delete permission, but Object Lock is disabled. Individual record envelopes are not service-signed; after the epoch key becomes public, anyone can create a valid new AEAD envelope. Historical origin therefore requires a prior trusted ciphertext digest/receipt or publication record. These are retention/provenance limits, not early key-recovery findings.

Corrections to model claims

These corrections matter because a model's confidence is not a substitute for checking its premises. Original reports are preserved unchanged.

• GLM-5.3 F4: knowing the outer session identifier permits interference or denial of service. It does not let a front end inject authenticated victim HTTP requests or read plaintext responses through established inner TLS.
• GLM-5.3's operator-start comparison: the enclave's time anchor precedes first disclosure, but the operator can withhold public publication. It need not have the same starting time as independent public solvers.
• GLM-5.3 Flash S6: faster hardware is not excluded by the RandomX-strength assumption. The assumption forbids a computational shortcut, not a higher evaluation rate. GLM-5.3's final reference to the “slowest” solver should be read as the fastest successful adversarial solver.
• GLM-5.3 Flash wrap analysis: an AEAD tag is a cheap check of a guessed terminal output. The defense is that the 256-bit output is unpredictable; testing a guess does not itself require recomputing the entire chain.
• GLM-5.3 Flash lifecycle: publication_not_before gates publication of the next puzzle, not its generation. Generation starts after current activation.
• GLM-5.3 Flash ALPN/header claims: the legacy ACME challenge setter is not active in v2; response artifact headers travel inside inner TLS. The parent already knows artifact names through the publication channel.
• RandomX v2 cache flags: omission of a v2 flag from cache allocation is not an established algorithm mismatch. Native cache allocation does not use that flag to select the hash version; the VM receives the v2 flag. The checked full-memory v2 vector passed.
• Kimi's “non-upstream” v2 flag: the supplied header is byte-identical to tevador/RandomX at the pinned upstream commit and already contains RANDOMX_FLAG_V2 = 128. Calling that flag a custom local fork is incorrect. Header comparison evidence. This comparison does not fill the model's missing full-C++ audit coverage.
• Kimi B-F5 signing-key erasure: ed25519-dalek's zeroize feature is enabled through its default features, confirmed by cargo tree -p ed25519-dalek -e features -i --offline. Comprehensive memory erasure remains unproved, but the claimed missing feature is false.
• Kimi's future “complete solution” wording: future seeds and the epoch key exist during generation; all terminal chain outputs become available only as their workers finish. Incomplete generation is not a complete solution.
• Qwen finding 4 heading: the response is constructed only after the persistence ACK, as its own body correctly explains. The heading claims the opposite. An ACK still does not prove that a malicious host persisted bytes.
• Qwen finding 5 DNS rebinding: the enclave checks each resolved numeric IP and passes that same IP to connect_ip; it does not resolve the name again between this check and connection. The alleged rebinding window is not shown by this code. A malicious parent can reroute connections anyway, but upstream TLS still authenticates the requested hostname.
• Qwen's optional WireGuard protection: v2 initializes direct mode with no configured relays. The optional legacy path is not active protection here.
• Qwen's seven-day arithmetic: a record at hour 23 has 6 days and 1 hour remaining from its creation only if solving actually takes seven days from first disclosure; six days is not a hardware-independent minimum. Nor does a larger solver fleet automatically remove the serial dependency.
• Gemini's header leak: the forwarded upstream headers are in the response on inner TLS. Terminating outer HTTPS does not expose their plaintext. Length/traffic inference remains possible, but this is not the claimed plaintext-header path.
• Gemini's near-zero delay and day-6.9 request: the epoch accepts requests for 24 hours, not seven days. If the solver takes seven days, a last-hour request has about six days left; it cannot be admitted on day 6.9 under that same epoch. Arbitrarily faster hardware can shorten the actual interval, but seven independent solver cores do not unlock seven wrapped segments in parallel. Lack of client-supplied puzzle entropy does not establish the proposed bypass of internally fresh NSM entropy and epoch expiry.
• Gemini's delayed-ACK claim: activation has a 60-second timeout, and both lifetime anchors precede the first puzzle write. It cannot wait nearly 24 hours and then grant a fresh serving day. Host access before public publication is real; resetting the activation clock is not. The delayed-ACK integration test rejected exactly that expired-publication scenario.
• Gemini's permanent empty-poll stall: the Python transport increments its sequence after a valid empty response, and InnerTLS._pump issues subsequent polls until inner TLS completes or its deadline expires. It does not keep retrying the same cached empty reply forever. Anonymous session exhaustion remains an availability concern, not a content/key-recovery finding.
• DeepSeek's “confirmed diagnostic timing leak”: the proposed path depends on Net::set_mode being called for upstream failures. V2 initializes direct mode and does not call that method on this request path; connect_ip returns a connection result without changing mode. The claimed diagnostic event is therefore not established. No timing experiment was run by that reviewer, and a monotonic relationship between hostname length and network latency was asserted without evidence. Actual DNS/IP/length inference remains a separate, documented limitation.
• DeepSeek's large-flight failure: the report alternately claims every chunk has send=True and correctly observes the opposite. The client buffers all but the last chunk. The real dev-binary check successfully sent a 12,001-byte request path in payload chunks of 4,096/4,096/3,940 bytes with send=false/false/true, and returned the expected 3,968-byte response. Evidence. TLS is designed to consume a byte stream across transport fragments; such fragmentation does not itself corrupt records.
• DeepSeek's acceleration claims: the absence of a hardware-independent lower bound is valid. Claims that seven machines solve the seven wrapped segments simultaneously, or that a GPU farm is demonstrably 100 times faster, are unsupported. Its own report later recognizes the serial dependency. No faster-hardware benchmark was performed, and public dataset initialization does not reveal later private seeds.
• DeepSeek's asserted measured/deployed runtime mismatch: no supporting mismatch is identified. The snapshot freezes runtime at the deployed source commit and labels later documentation separately. Existing independent CI builds reproduced the production measurements; this review did not perform another live production attestation check.
• DeepSeek's signing-key and scheduling statements: the signing key's zeroization feature is enabled, as checked above. Future generation precedes the publication gate, not vice versa. The report does not show a parent capability that freezes trusted NSM time or otherwise defeats admission's trusted-time and monotonic checks.

Validation performed during consolidation

No production traffic was generated, production configuration was not changed, and no enclave restart was performed for these reviews. None of these checks is a proof of security or a substitute for an independent native-code audit.

Method and reproducibility

Runner. Each Pi model received the same line-numbered 542,023-byte snapshot, SHA-256 07ec105a70b1dfb77254f4fbf6ecbe439bddf6fac6fdaa1cff8dcbe6b2ae532e. Runtime was frozen at a10323d; documentation and CI were separately labelled at 85c61e96590b52ded80a995ef5d1e379b2287761 and are claims to evaluate, not measured runtime. The manifest records file hashes, prompts, model IDs and focus variants. No reviewer was given another model's report.

Pi had no tools, extensions, local context files or skills, and could not run tests. Credentials were kept out of prompts and argv. Provider calls used each requested model's exact catalog identifier. Sol used Codex and independently read the local repository and ran checks. This is independent prompting, not a claim of statistically independent model training or independent human audits.

The initial 32,768-token allowance was exhausted by four selected models before a complete final assessment. Those attempts remain marked incomplete. Retries use 65,536 output tokens; Qwen's retry uses medium reasoning, while the other three use high. Gemini's 65,536-token attempt failed with upstream idle timeouts; its next attempt uses a 32,768 total output allowance with an explicit 8,192-token reasoning budget, which was not reflected in usage (31,455 reasoning tokens reported before truncation). A subsequent medium/65,536 attempt recovered from an internal provider timeout and produced a complete 4,335-token final response with stopReason=stop. The initial runner classified any earlier error as fatal; that classification was corrected with an explicit audit record in its result JSON. The negative review was retained and evaluated, not retried for agreement. DeepSeek's high/65,536 attempt used the entire allowance for reasoning without a final response; the medium-effort retry also exhausted 65,536 output tokens (64,413 reasoning tokens), leaving only a truncated final assessment. It is retained as incomplete. Its surviving opening gives conditional support to the core confidentiality and early-key properties, unlike the completed direct-answer attempt. This disagreement between attempts is preserved; the partial answer is not counted as another completed review. A separate direct-answer attempt, with extended reasoning disabled and a 32,768-token allowance, completed with a 7,328-token final assessment against the identical snapshot. Its lower reasoning setting and numerous unsupported assertions limit its evidentiary weight. Both attempts are retained; they are one requested model, not additional independent panel members. Each attempt has its own manifest, usage, elapsed time, stop reason and final text. Truncated or failed answers are not counted as complete.