# Exact assumptions and limitations

This application is an experimental integration, not an audited cryptographic product.

1. **Threat model:** honest coordinator and honest protocol execution; at most one party's state/transcript is passively observed. No malicious-security claim is made for the entire application even though the engine implements authenticated garbling. Setup lacks verifiable sharing; input consistency across holders is not proved.
2. **MPC dependency:** correctness and privacy rely on emp-wasm 0.3.2 and its underlying EMP port. Upstream explicitly flags uncertain changes, including IO ordering, threading/SIMD changes and crypto-library migration. See the included upstream README. Passing tests does not settle those concerns.
3. **Runtime:** browser, operating system, static files and CSPRNG must be trustworthy. Party workers are logical execution boundaries on one machine, not protection against its owner, debugger, extensions, same-origin compromise or OS compromise.
4. **Sharing:** one party holds two independent components and lacks the third. Two colluding parties can reconstruct K outside this protocol. The no-reconstruction property describes the supplied computation, not resistance to an authorized coalition combining its stored secrets.
5. **Output:** the coordinator knows the selected plaintext for encryption and receives authenticated plaintext chunks during decryption. Both participants also receive the agreed circuit output. Output recipients can retain plaintext indefinitely.
6. **Transport:** local direct MessagePorts are used; no share or online protocol traffic is deliberately routed through the coordinator. Remote replacements require authenticated confidential peer channels and correct role/session binding. A hardware-backed AES API cannot automatically participate in this protocol.
7. **Nonce lifecycle:** one Files object per live keyset, no counter rollback, no imported keys or concurrent independent encryptors. Keys are ephemeral and nonce allocation is centralized by the honest coordinator. The demo does not support restoring shares after reload.
8. **Debug:** private debug output is deliberately accessible in each worker's console. It is off by default and never returned as a coordinator response. Collecting multiple workers' console output defeats the intended separation; disable debug code in any future hardened build.
9. **Memory:** explicit wiping is best effort only. JS/WASM garbage collection and message copies do not guarantee erasure. Timing, memory side channels, denial of service and malicious file resource exhaustion are not comprehensively defended.
10. **Framing:** each chunk uses AES-GCM, but the surrounding SHA-256-bound JSON framing is application code requiring review. No plaintext from a failing chunk is output by MPC; the coordinator may already hold earlier authenticated chunks when a later chunk fails. The UI does not offer a download until the complete file succeeds.

## Audit guide

Trace every `postMessage` and `finish` in party/worker.js and crypto/engine.js. During setup components go only over transferred peer ports. Private inputBits are partial contributions passed only to that party's runtime worker. Coordinator responses contain identifiers, status, outputs and statistics.

In crypto/circuit.js `key`, `h`, `mask` and `transformed` are arrays of integer wire identifiers (or public constant sentinels), not clear secret values. `Builder.finish` is the only output boundary in generated circuits. For encryption it outputs ciphertext and tag; for decryption validity and gated plaintext. Tests contain a deliberately clear evaluator for PUBLIC fixture keys; it is not part of the application import graph.

Also review the compiled upstream runtime and its randomness/preprocessing. The provided source map and provenance make locating code easier but do not establish binary reproducibility or the absence of hidden leakage. Rebuilding the upstream WASM from source is a separate audit task.