Rounds 1–3 completed 2026-03-31. Round 4 pentest completed 2026-03-31. Scope: crypto primitives, deniability, collision integrity, side channels, adversarial attacks, build hardening, penetration testing.

Two 64MB images tested blind (one darkfs with 3 files, one pure /dev/urandom):

Confidence: 0%. Cannot determine which image is darkfs. Deniability PASS.

Originally rated CRITICAL, this was fixed by switching to random 24-byte nonces per write (see cipher.rs). Every block write generates a fresh random nonce, stored as the first 24 bytes of the on-disk block. Nonce collision probability at 2^48 writes is ~2^-97.

Full automated pentest with 25+ attacks across 7 categories. All findings below have been fixed.

• HKDF salt==IKM distinguisher: chi-square 284.6, no bias
• XChaCha20 nonce birthday: collision at 2^48 writes is 2^-97
• Argon2id timing vs passphrase length: constant time
• Directory cycle stack overflow: path canonicalization prevents true cycles
• Deletion residue: erased blocks no longer decrypt
• Dual passphrase corruption: 0/100 files corrupted
• Statistical distinguishability (used vs fresh): identical chi-square, entropy, serial correlation
• Bincode deserialization OOM: rejects malformed data safely
• flock bypass: second open correctly returns ImageLocked
• Modular bias (u64 % total_blocks): ~1.4×10⁻¹³, negligible
• 500-file roundtrip integrity: all files byte-perfect
• 5000 create/delete cycles: no slot leaks or degradation

At rest: PASS — A static darkfs image is cryptographically and statistically indistinguishable from random data. Confirmed by 14-test statistical suite and blind penetration test.

Under observation: PARTIAL — Behavioral fingerprints exist (I/O patterns, memory allocation, process/mount names). All require active monitoring of the running system.

Multi-snapshot: IMPROVED — Random nonces prevent confidentiality breaks. Decoy writes mask superblock location. Write padding hides exact file sizes (observer learns only tier: 1/16/256/4096 blocks).

Full-source adversarial audit covering cryptographic analysis, deniability attacks, protocol-level attacks, implementation bugs, and side-channel analysis across both darkfs and qsmm codebases.

Attack scenario: After reopening an image, populate_claims() walks the directory tree and attempts to claim block offsets for existing files. The claim_file_blocks function uses decrypt_block() (without void unmasking) to find each block's slot. Since all file blocks on disk are void-masked, decrypt_block() always fails, so blocks 1..N of multi-block files are never added to the claimed set. A subsequent file write whose HMAC-derived slot overlaps with an unclaimed block will silently overwrite it.

Impact: Silent data loss for any multi-block file after image reopen + new file write.

PoC: tests/pentest.rs::critical_claim_file_blocks_never_claims_multiblock

Fix: In ops.rs:390, replace:

if crate::crypto::cipher::decrypt_block(&key, &raw).is_ok() {

with:

if crate::crypto::cipher::decrypt_block_masked(&key, &raw, master_secret, offset).is_ok() {

Attack scenario: File blocks are encrypted + void-masked (double layer). Superblock shards are only encrypted (single layer). While both look random individually, the inconsistency means an adversary with the master secret can identify shard blocks by checking which blocks change when void masking is applied/removed.

Fix: Use encrypt_block_masked() / decrypt_block_masked() for shard blocks in superblock.rs.

Location: superblock.rs:248: if expected != actual

Fix: use subtle::ConstantTimeEq; if actual.ct_eq(&expected).unwrap_u8() == 0

Success path: void_unmask (ChaCha20) + AEAD_decrypt (ChaCha20 + Poly1305) = 2x ChaCha20 + 1x Poly1305. Failure path: void_unmask (ChaCha20) + AEAD_verify_fail (Poly1305) + equalize (ChaCha20 + Poly1305) = 2x ChaCha20 + 2x Poly1305.

Fix: Run dummy Poly1305 verify (not encrypt) in equalize, or always run both paths.

The void mask is deterministic per (seed, block_id). When the same block is sealed twice with identical data, XOR cancels the mask AND the data region, producing all zeros in the data portion. This reveals whether the plaintext changed (1 bit per block). When data changes, the XOR of the data region reveals the approximate plaintext length (zero/non-zero boundary within the tier).

Fix: Mix the per-seal random nonce into the mask derivation, making the mask stream unique per seal.

• HKDF domain separation: all 12 info/domain strings are unique across qsmm and darkfs
• Known-plaintext on void mask: ChaCha20 is a PRF; recovering one block's mask doesn't help with others
• Malicious shard injection: AEAD encryption prevents false shard creation (adversary can only DoS)
• Session secret isolation: per-image random_salt ensures different encryption keys between images
• Shard position prediction: HMAC-SHA256 produces uniformly distributed offsets; no clustering detected
• Shard collision infinite loop: coupon collector bound; ~25 iterations worst case for 9-of-9

1. Attacker has the source code and the image file
2. Attacker does NOT have the passphrase
3. Passphrase has >= 80 bits of entropy (recommended 12+ mixed chars)
4. Attacker may compel one passphrase (decoy filesystem)
5. Single-snapshot assumption: attacker sees the image at one point in time
6. No active surveillance of the running system

• Deterministic salt (C4): Argon2id salt derived from image size. Precomputation feasible for common sizes by well-funded adversaries. Mitigation: use non-standard image sizes.
• Multi-snapshot (D2): Block change patterns reveal write activity volume.
• SSD wear-leveling: Outside threat model; requires firmware-level access.
• No mlock/core dump prevention (S8/S9): Secrets can be swapped to disk or captured in core dumps.
• Advisory locking (I5): flock is best-effort; malicious processes can bypass.
• Fill rate (I1): Practical limit ~50-60% before slot exhaustion.