Author's security audit 2026-08-20

[ghscuuo]

Architecture & Security Audit Report: Airgap-Coinflip

Date: August 2, 2026
Status: Passed

Note

Non-Technical Summary
Built Defensively: This tool was designed by strictly minimizing features to reduce the chance of user error and limit exposure to operational risks.

• Verified Math: The tool correctly converts 128 physical coin flips into a standard 12-word Bitcoin seed phrase.
• No Peripheral Access: It requires no network connection and no camera access. It is a single file designed to be run on an isolated offline computer.
• Guardrails Against Error: We intentionally omitted complex options (like altcoins, 24-word phrases, dice, or cards). These omissions enforce a narrow, standard path that reduces the likelihood of critical configuration errors.
• Volatile Execution Requirement: Because the tool runs in a web browser, the browser's memory retains your seed words until the machine is shut down. You must power off the computer completely when you are done to clear the volatile memory.

1. Executive Summary & Audit Scope

An architectural security audit was conducted on the airgap-coinflip repository to evaluate its cryptographic implementation, dependency integrity, and build reproducibility. The architecture is designed to support offline, trustless deployment environments. No critical vulnerabilities were identified during the review.

• Review Methodology: Automated multi-model static analysis and architectural review (Gemini 3.1 Pro, Claude Sonnet 4.6, Claude Opus 4.6).
• In-Scope Code:
  • Source Code: main.js, vite.config.js
  • Compiled Artifact: Deterministic build output (dist/airgap-coinflip_a5418711.html)
• Out-of-Scope Code: test-bip85-bug.js, test-bip85-path.js, test-bip85-path2.js, style.css, and external node_modules. These files were deliberately excluded from the audit as they serve as non-cryptographic UI styling or external test-harnesses that are strictly pruned during the Rollup build phase.

2. Attack Surface Minimization & Threat Modeling

The application architecture employs deliberate feature restriction to mitigate operational risk and reduce the overall attack surface.

• Entropy Generation Constraints: The tool restricts entropy generation to binary inputs (coin flips). This mitigates the transcription and base-conversion risks associated with Base-6 (dice) or Base-52 (cards) implementations.
• Protocol Restriction: The application enforces standard Native Segwit Bitcoin derivations and actively omits custom derivation paths (including custom account indexes) and altcoin support. This prevents users from stranding funds in non-standard, unrecoverable configurations.
• Entropy Scope Restriction: The tool enforces 128-bit generation and omits 256-bit generation to maintain a strict UX boundary, preventing users from attempting to construct invalid 24th words with approximate checksums.
• Omission of CLI Executables: The application is deployed strictly as a standalone, browser-based HTML file. Refusing to package a Node.js CLI wrapper or compiled binary mitigates local privilege escalation vectors and eliminates dependency on host-level OS execution environments.
• Standardized Wordlists: Generation is strictly limited to the English BIP39 standard to ensure cross-vendor hardware compatibility and eliminate localization encoding risks.

3. Architectural Review & Isolation Constraints

The system was audited against its requirements for secure execution in isolated environments.

• Network & Peripheral Isolation: The application does not implement network request capabilities, external I/O peripheral access (e.g., webcams), or local state persistence mechanisms (localStorage/cookies). This limits data exfiltration vectors in the event of host compromise.
• Dependency Minimization: The application relies on vanilla JavaScript and HTML, bypassing complex component frameworks. This minimizes the compiled bundle size and facilitates manual code auditing.
• Cryptographic Boundary Enforcement: The tool programmatically computes the final SHA-256 checksum rather than relying on manual user approximation. This enforces BIP39 compliance at the application layer, ensuring the resulting mnemonic is natively accepted by standard hardware wallets during recovery operations.

4. Cryptographic Implementation (BIP39 Verification)

• Finding: Verified Execution. The application correctly delegates cryptographic bit-mapping to the audited @scure/bip39 library.
• Verification: 128 bits of binary entropy are generated and buffered (main.js#L296). The buffer is passed to the library (main.js#L297), which executes the SHA-256 hash, extracts the 4-bit checksum, and processes the 132-bit result into 12 chunks of 11 bits. No entropy leakage or truncation was detected in the generation logic.

5. Build Pipeline & Determinism

• Finding: Verified Cryptographic Reproducibility.
• Verification: The build pipeline utilizes vite-plugin-singlefile with static Rollup output configurations (vite.config.js#L15-L20). The build script enforces SOURCE_DATE_EPOCH=1700000000 and TZ=UTC (package.json#L8). This ensures reproducible builds, allowing independent parties to verify that the compiled release binary matches the public source code.

6. Content Security Policy (CSP) & Operational Security

• Finding: Compliant Execution Environment.
• Verification: The single-file HTML deployment prevents the side-loading of external dependencies when transferred to airgapped environments (e.g., Live USB operating systems). The implemented Content Security Policy restricts external network access. The wasm-unsafe-eval directive is appropriately scoped to permit local WebAssembly compilation for required cryptographic libraries in file:// contexts without introducing remote execution vulnerabilities.

7. Architectural Limitations & Residual Risks (Opus 4.6 Findings)

An adversarial consensus review conducted via Claude Opus 4.6 identified residual risks inherent to the JavaScript execution environment, validating the requirement for strictly volatile (Live OS) execution.

• JS String Immutability: While the application correctly executes .fill(0) on Uint8Array buffers to wipe cryptographic material, the final generatedMnemonic (the seed phrase) is cast as a standard JavaScript string. Strings in JS are immutable and persist in the V8 heap indefinitely until garbage collection, meaning memory wipes are incomplete at the memory layer.
• DOM Injection Persistence: Cryptographic buffers for BIP85 child mnemonics are securely wiped in finally blocks, but the plaintext mnemonic is subsequently concatenated into an HTML string and injected into the DOM (innerHTML).
• Required Mitigation: Because JavaScript cannot securely zero-out strings in memory, the most effective mitigation is hardware-level volatility. Users must power off the machine immediately after use to trigger RAM decay. This limitation emphasizes why the tool must only be run on amnesic operating systems like Tails or other temporary Live OS.
• Reproducibility Enhancement: Opus recommended pinning the Node.js version via an .nvmrc or Dockerfile to strictly guarantee deterministic build reproduction across different host environments.

8. Conclusion

The airgap-coinflip architecture meets the strict security requirements for offline, deterministic seed generation. The implementation effectively minimizes the attack surface and relies on established cryptographic standards. The identified JavaScript limitations are acceptable given the explicit operational requirement to execute solely within volatile, airgapped environments.

[ghscuuo]

While generating the input entropy (for example, via coin flips or hardware device) must not be biased (your secret must be able to have been put on any sand grain anywhere in the known universe, or something like that), I wanted to also try to make sure that the sha256 hashing in this implementation did not have any flaw that would destroy that entropy with some kind of fatal space-narrowing bias.

Cryptographic Audit Report: SHA-256 Hash Function Verification

Date: August 3, 2026
Status: Passed

Note

Non-Technical Summary
This audit validates the mathematical correctness and memory isolation properties of the SHA-256 hashing function used in the offline coin-flip generator.

• Verified Correctness: The algorithm produces exact, standardized hashes matching international NIST CAVP test vectors.
• Memory Zeroing: The system successfully overwrites memory buffers in the application's managed state (using TypedArrays) as a defense-in-depth measure. However, because standard JavaScript runtimes use immutable strings and garbage collection, the application cannot guarantee that no sensitive input entropy remnants linger in the underlying browser engine heap.

---

1. Scope of Audit

This audit targets the core SHA-256 cryptographic hash function implementation. The review evaluates:

1. Mathematical Correctness: Compliance with FIPS 180-4 and RFC 4634 specifications across boundary lengths.
2. Streaming Execution: Correctness of incremental block-by-block streaming updates.
3. Cloning Isolation: Memory safety during state copy/duplication operations.
4. Memory Hygiene: Verifiability of application-level managed state zeroization.

Note: This audit evaluates the SHA-256 primitive implementation only. It does not evaluate the security of the overarching coin-flip protocol or commitment schemes.

---

2. Test Methodology & Verification Vector Results

Correctness was evaluated across critical boundary input lengths designed to stress-test padding offsets, block boundary transitions, and multi-block formatting.

Test Vector Name	Input Description	Expected Hash (SHA-256)	Result
Empty String	0 bytes	e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855	PASS
Standard "abc"	3 bytes	ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad	PASS
55-Byte Edge Case	Maximum input size that fits within a single 64-byte block (64 - 9 bytes padding)	9f4390f8d30c2dd92ec9f095b65e2b9ae9b0a925a5258e241c9f1e910f734318	PASS
56-Byte Edge Case	First input size that spills padding into a second block (forces 128-byte formatting)	b35439a4ac6f0948b6d6f9e3c6af0f5f590ce20f1bde7090ef7970686ec6738a	PASS
63-Byte Edge Case	1 byte short of block boundary (spills padding into block 2)	7d3e74a05d7db15bce4ad9ec0658ea98e3f06eeecf16b4c6fff2da457ddc2f34	PASS
64-Byte Edge Case	Exactly 1 block of data (padding occupies block 2 entirely)	ffe054fe7ae0cb6dc65c3af9b61d5209f439851db43d0ba5997337df154668eb	PASS
65-Byte Edge Case	1 block + 1 byte data spillover (padding occupies block 2)	635361c48bb9eab14198e76ea8ab7f1a41685d6ad62aa9146d301d4f17eb0ae0	**PASS`
Long Multi-block	56-character ASCII string: "abcdbcdecdefdefgefghfghighijhijkijkljklmklmnlmnomnopnopq"	248d6a61d20638b8e5c026930c3e6039a33ce45964ff2167f6ecedd419db06c1	PASS

Note on Length Extension: Testing verifies correctness under multi-block padding transitions. SHA-256 is inherently vulnerable to length extension attacks by design; this audit verifies implementation compliance with the standard, not resistance to length extension.

---

3. Streaming and Incremental Block Accumulation

• Verification: Tested by feeding multi-block sequences in separate chunked updates.
• Finding: The streaming accumulator accurately handles partial-block updates and carries over correct compression states across block boundaries. The resulting digest matches standard one-shot calculations.

---

4. State Cloning Isolation

• Verification: Created an active hasher state, cloned the instance, and appended different data streams to each branch concurrently.
• Finding: Cloning creates a deep copy of internal buffers without sharing underlying memory references. Mutating one state does not affect the output of the other, confirming absolute isolation. Note that while this is a verified library primitive, it is not utilized in the single-pass coin-flip logic.

---

5. Memory Wiping & Cleanup Validation

• Verification: Checked state after execution of zeroization routines.
• Findings:
  1. Internal registers (A through H) stored in memory are successfully cleared to 0.
  2. The internal partial-block message queue buffer (implemented via Uint8Array) is successfully overwritten with zero values (0x00).
  3. The module-level shared message schedule buffer array (W array) is successfully zero-filled via .roundClean() to prevent derived block state leakage on the heap.
  4. The internal destroyed status flag is correctly set to prevent further usage of the closed context.

---

6. Architectural Limits & Residual Risks

• Garbage Collection Constraints: Hashing operations running in standard JavaScript execution environments are subject to engine-level optimization. Raw input strings and temporary variables are immutable and cannot be programmatically zeroed out in physical RAM by the application layer.
• Mitigation Recommendation: The application should enforce input paths using exclusively Uint8Array byte buffers rather than JavaScript string primitives. This avoids allocating immutable string copies on the engine heap.
• Timing Side-Channels: Because standard JS runtimes use Just-In-Time (JIT) compilation and automatic garbage collection, execution times are not strictly constant-time. While SHA-256 does not employ data-dependent branches, timing leaks are possible via engine operations, particularly when dynamic compilers switch between 32-bit SMI (Small Integer) representations and heap numbers.
• Required Mitigation: Complete protection against heap extraction requires operating system level memory volatility. Hashing of sensitive inputs must only be executed inside a volatile RAM environment (e.g. temporary Live OS), with a physical power cycle immediately following execution to decay host memory.

---

7. Conclusion

The SHA-256 implementation is cryptographically correct, handles padding boundary transitions without error, isolates cloned states, and implements functional application-level memory zeroization interfaces.