3.
Short, Clear Project Overview
You:
“We are building the cryptographic layer for a privacy-focused, decentralized
messaging app.
The goals are:”
✔ Zero metadata
✔ Zero logging
✔ No central server
✔ Signal-grade end-to-end encryption
✔ Session-style routing (like Session messenger)
✔ Cross-platform clients
✔ Real-time encrypted communication
Your app:
✔ Uses legal cryptographic protocols
Noise Protocol, Double Ratchet, Mixnets → All used in many legitimate applications.
✔ Uses decentralised routing for privacy
Session routing = legitimate privacy method, not a criminal tool.
✔ Designed for secure communications, not illegal markets
✔ Implemented in Rust
Rust is a respected systems language used for strong security.
✔ Your client is UK-based, which already means legal compliance.
Nothing about your architecture indicates:
● Tor hidden services
● Dark-web marketplaces
● Onion routing for illegal trade
● Illegal cyber operations
the project is a security-focused, privacy-preserving app, not a dark-net tool.
4. Architecture Summary — High Level
You:
“Here’s the architecture at a high level before we go deeper.”
Core Components
1. Client App (Rust)
● End-to-end encryption
● Double Ratchet (Signal-like)
● Key generation, verification, session state
2. Decentralized Routing
● Mixnets / onion-style routing
● Strong metadata protection
● No central storage or servers
3. Identity & Keys
● Decentralized identifiers
● No phone number / email
● Trust-on-first-use (TOFU) optional
4. Client-Side Secure Storage
● Local encrypted storage
● Perfect forward secrecy
● No cloud involvement
5. Phase-1 Summary (Core Deliverable)
You:
“Phase-1 is a reference Rust prototype — minimal, clean, audit-ready.”
● Noise_XX handshake
● Signal-style Double Ratchet
● Deterministic test vectors (KATs)
● CI + reproducible builds
● Threat model + verification scripts
6. Ask for Technical Input (Main Discussion)
Use these questions to open dialogue:
Crypto Stack Selection
● “What are your thoughts on the proposed cryptographic stack?”
● “Would you prefer Noise Protocol, Double Ratchet, or a hybrid approach?”
● “Do you see performance benefits in pure Rust?”
7. Technical Confirmation Checklist
A — Protocol & Primitives (5 min)
Handshake: Noise_XX
Ratchet: Signal Double Ratchet
Primitives:
● X25519 (KEM/KX)
● Ed25519 (signatures)
● HKDF-SHA256
● ChaCha20-Poly1305 (default), AES-GCM optional
● System CSPRNG, zeroization
Ask:
● “Any objections to these primitives?”
B — Handshake & Ratchet Details (5–8 min)
Topics to review:
● Handshake outputs (ck, h, root key)
● Deterministic KATs
● Ratchet state:
○ root KDF
○ send/recv chains
○ skipped-message table (default: 200)
● AEAD nonce layout (4-byte direction + 8-byte counter)
Ask:
● “What window size do you prefer for skipped messages?”
● “Should AES-GCM be runtime-configurable?”
C — Metadata & Routing Hooks (4 min)
Envelope format:
version || hdr_len || hdr_encrypted || payload_encrypted || mac
Ask:
● “What minimal routing token do relays need — opaque ID only, or TTL as well?”
D — PQC Migration Plan (2 min)
Hybrid shared secret = HKDF(X25519 || Kyber)
Ask:
● “Is this migration approach acceptable?”
8. CI, Tests & Reproducibility (6–8 minutes)
Deliverables:
● KATs for handshake + ratchet
● cargo test + [Link]
● CI: fmt, clippy, tests, audit, reproducible builds
● Dockerfile with pinned digest
Ask:
● “Do you have any CI/security scanning requirements?”
9. Scope Control — Keep Phase-1 Strict
If the developer dives into deep technical areas:
You reply:
“That’s an important point, but we will address that in Phase-2 or the routing layer.
Phase-1 is strictly the cryptographic core and correctness.”
This protects your timeline.
10. Crucial Technical Assessment Question
Ask this one question to judge capability:
“How would you structure the state machine for Noise_XX → Double Ratchet
transition in Rust?”
Good answer = you found the right developer.
11. Non-Negotiables (Must Repeat Clearly)
1. No custom cryptography
2. No central-server shortcuts
3. Metadata minimization > convenience
12. Non-Technical Discussion (5 minutes)
Topics:
● Working style
● Git repository access
● Documentation standards
● Security testing expectations
● Milestone delivery
13. Payment & Budget Discussion
You:
“The total project budget is $4,000–$5,000, divided into three phases.”
Phase-1 (20 days) — $1,000
● Cryptographic skeleton
● Prototype
● Routing + feasibility
Phase-2 — $2,000
● Complete protocol implementation
● Client-side app
● Metadata protection
● Optimization
Phase-3 — TBD
● Additional features
● UI/UX
● Scaling
● Security hardening
We are executing it in 3 phases:
Phase-1 (20 Days)
Budget: $1,000
● Core cryptographic skeleton
● Prototype of secure messaging
● Basic routing logic
● Feasibility validation
Phase-2
Budget: $2,000
● Complete protocol implementation
● Client application
● Advanced routing + metadata protection
● Testing, optimization
Phase-3
Budget: To be finalized
● Additional features
● UI/UX
● Scaling
● Security hardening
● Stress testing
14. Long-Term Vision (1–2 minutes)
You:
“Sir, I want this collaboration to grow long-term. We have more upcoming cryptography
and secure-communications projects, and your expertise would be invaluable.”
15. Responsibilities & Ownership (3–5 minutes)
● Agency handles client communication
● Developer reports progress to agency
● Must follow secure coding practices
● IP transferred after payment
Ask:
● “Are you comfortable with these coordination and IP terms?”
16. Next Steps (Final Wrap-Up)
You:
“So, the next steps are:”
1. You review and sign the Developer Agreement.
2. I transfer the kickoff payment of $300.
3. You clone the repo and begin Noise_XX implementation.
4. Initial KATs delivered in 4–6 days.
5. Mid-phase review demo.
“Does this timeline work for you?”