UAT/PHASE1.md — 20 test scenarios, 80+ checkboxes Identity, encryption, messaging, TUI, web, groups, aliases, auth, OTP replenishment, session persistence, cross-client UAT/PHASE2.md — 7 scenarios (WASM, receipts, files, multi-device, HW wallet, groups, history) UAT/PHASE3.md — 6 scenarios (DNS discovery, key transparency, federation, mutual TLS, gossip) UAT/PHASE4.md — 10 scenarios (mule identity, pickup, delivery, receipts, dedup, expiry, compression) UAT/PHASE5.md — 6 scenarios (Bluetooth, LoRa, mDNS, Wi-Fi Direct, USB export, fallback chain) UAT/PHASE6.md — 3 scenarios (sealed sender, traffic analysis resistance, onion routing) UAT/PHASE7.md — 8 scenarios (ntfy, DoH, DB encryption, admin CLI, rate limiting, audit, CI, monitoring) Each test has exact commands to run and checkboxes for pass/fail. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
74 lines
2.1 KiB
Markdown
74 lines
2.1 KiB
Markdown
# Phase 6 — User Acceptance Testing (Metadata Protection)
|
|
|
|
> Phase 6 is NOT YET IMPLEMENTED. This is a pre-written test plan.
|
|
|
|
## Prerequisites
|
|
|
|
- Phase 5 UAT fully passing
|
|
- Network traffic analysis tools (Wireshark/tcpdump)
|
|
- At least 3 federated servers for onion routing
|
|
|
|
---
|
|
|
|
## 1. Sealed Sender
|
|
|
|
**Alice sends to Bob through server:**
|
|
|
|
- [ ] Server receives message with recipient fingerprint but NO sender fingerprint
|
|
- [ ] Server logs show: "Message for <bob-fp> from [sealed]"
|
|
- [ ] Bob decrypts and sees Alice's identity (embedded in ciphertext)
|
|
- [ ] Wireshark: server-bound traffic contains no sender metadata
|
|
|
|
**Server admin inspects DB:**
|
|
- [ ] Message queue shows `to` field only, no `from`
|
|
- [ ] Cannot determine who sent the message
|
|
|
|
---
|
|
|
|
## 2. Traffic Analysis Resistance
|
|
|
|
**Padding:**
|
|
- [ ] All messages padded to fixed sizes (256, 1024, 4096 bytes)
|
|
- [ ] Small "hi" and large paragraph produce same-size ciphertext on wire
|
|
- [ ] Wireshark confirms uniform packet sizes
|
|
|
|
**Timing:**
|
|
- [ ] Messages not sent immediately — random delay (0-2 seconds)
|
|
- [ ] Constant-rate dummy traffic when idle (configurable)
|
|
- [ ] Observer cannot distinguish real messages from dummy traffic
|
|
|
|
---
|
|
|
|
## 3. Onion Routing (Opt-in)
|
|
|
|
**Setup: 3 servers (A, B, C). Alice on A, Bob on C.**
|
|
|
|
```bash
|
|
cargo run --bin warzone-client -- chat @bob.c.example.com --onion
|
|
```
|
|
|
|
- [ ] Client builds onion route: A → B → C
|
|
- [ ] Message encrypted in 3 layers: encrypt(C, encrypt(B, encrypt(A, plaintext)))
|
|
- [ ] Server A sees: "message for Server B" (doesn't know final destination)
|
|
- [ ] Server B sees: "message for Server C" (doesn't know origin)
|
|
- [ ] Server C sees: "message for Bob" (doesn't know it went through A and B)
|
|
- [ ] Bob decrypts successfully
|
|
- [ ] Latency: shown as "onion: 3 hops, ~500ms"
|
|
|
|
**Onion routing disabled (default):**
|
|
- [ ] Direct routing: A → C (faster, less privacy)
|
|
- [ ] No onion overhead
|
|
|
|
---
|
|
|
|
## Summary
|
|
|
|
| # | Feature | Result |
|
|
|---|---------|--------|
|
|
| 1 | Sealed sender | ☐ |
|
|
| 2 | Traffic analysis resistance | ☐ |
|
|
| 3 | Onion routing | ☐ |
|
|
|
|
**Tester:** _______________
|
|
**Date:** _______________
|