← Back to Home
Source 1: The Tor Project
SOCKS Server: SOCKS5 on local TCP port. No BIND/UDP.
TLS Underlay: TLS 1.2 to every relay. Self-signed certs validated against consensus.
ntor Handshake: Curve25519 DH + HMAC-SHA256. Forward secrecy per hop.
Cell Protocol: Fixed 514-byte cells. RELAY + PADDING types.
Layered Encryption: 3 layers AES-256-CTR (guard→middle→exit). Client encrypts exit first, guard last.
Consensus: ~1-2 MB compressed. ~7,000+ relays. Microdescriptors: ~30-50 KB.
Circuit Building: Select 3 relays → TLS to guard → CREATE (ntor) → EXTEND per hop → RELAY_BEGIN.
Source 2: ESP32 NAT Router Project
- WiFi STA+AP concurrent: Exactly the topology needed.
- Full TCP/IP stack: lwIP with NAT, IP forwarding, DHCP, DNS.
- WireGuard VPN: Modern crypto runs on ESP32 — proven.
- 8 WiFi clients: ~5 KB RAM each. Mature TCP handling.
- Throughput: 5-15 Mbps routing, reduced with crypto.
Critical lessons: RAM is #1 constraint. Feature toggling essential. PSRAM on WROVER critical.
Source 3: ESP32 Hardware + ESP-IDF
table>
| Resource | Specification |
|---|
| CPU | Dual-core Xtensa LX6 @ 240 MHz |
| SRAM | 520 KB internal |
| PSRAM | Up to 8 MB (WROVER) |
| WiFi | 802.11 b/g/n, STA+AP concurrent |
| HW Crypto | AES-128/256, SHA-1/256/512, RSA, ECC |
mbedTLS: TLS 1.2/1.3 with HW acceleration. Dynamic buffers: ~22 KB per TLS connection.
Feasibility Analysis
SOCKS5 Server Feasible — ~8-16 KB for 4 clients.
WiFi AP+STA Proven — By esp32_nat_router.
TLS 1.2 to Guard Feasible — ~22 KB per connection.
AES-256-CTR (3 layers) HW Accelerated
Curve25519 ntor Feasible — ~100-300ms with HW ECC.
Consensus Download Bottleneck — 1-2 MB. Solution: hardcode 3-5 guards, ~5-10 KB.
Memory Budget Tight — TLS(22KB) + SOCKS(16KB) + circuit(12KB) + WiFi(80KB) = ~130 KB. Leaves ~70-180 KB.
Performance Estimates
table>
| Operation | Time (ESP32 @ 240 MHz) |
|---|
| TLS 1.2 handshake | 500-2000 ms |
| ntor per hop | 100-300 ms |
| Circuit build (3 hops) | 2-6 seconds |
| Realistic throughput | 0.2-1 Mbps |
Enough for text browsing, SSH, IRC. Not video streaming.
Recommended Hardware
table>| Board | Suitability |
|---|
| ESP32-WROOM-32 | ⚠️ Very tight. Single circuit only. |
| ESP32-WROVER (4MB PSRAM) | ✅ Recommended minimum. |
| ESP32-S3 (8MB PSRAM) | ✅ Best. |
| ESP32-C3 | ❌ Too constrained. |
Feature Reduction Plan
Must Remove
- Full consensus download → hardcode 3-5 guards
- Onion service (.onion) support → too complex
- Pluggable transports (obfs4) → no room
- Padding negotiation → accept traffic analysis risk
- Concurrent circuits → ONE circuit only
- Circuit rotation → rebuild on failure only
- IPv6, bridge relays, consensus diffs
Must Keep (Core Security)
- 3-layer AES-256-CTR onion encryption — this IS Tor
- ntor handshake (Curve25519) — required for circuits
- TLS 1.2 to guard — required transport
- 514-byte fixed cells — protocol compatibility
- SOCKS5 with hostname support — prevents DNS leaks
Forward secrecy — ntor provides by design
Final Verdict
YES — Architecturally Feasible with Constraints.
- Use ESP32-WROVER (PSRAM) or ESP32-S3
- Hardcode guard relay addresses (skip full consensus)
- One circuit at a time, fixed 3-hop path
- SOCKS5 CONNECT only, hostname addressing
- Remove onion services, pluggable transports, padding
- Use mbedTLS with hardware crypto + dynamic buffers
- Accept 0.2-1 Mbps throughput, 2-8s latency
The result: a pocket-sized, battery-powered Tor WiFi hotspot. Connect your phone to its WiFi AP, set SOCKS5 proxy to ESP32 IP:9050, and all traffic flows through Tor.
Biggest risk: engineering effort — 6-12 months for a proper implementation. But all building blocks exist.