XPost: sci.crypt, alt.privacy.anon-server   
   From: info@tcpreset.invalid   
      
   ## What is fog?   
      
   fog is an anonymous SMTP relay system that uses the Sphinx mixnet   
   protocol to provide strong sender anonymity through multi-hop routing   
   over Tor hidden services.   
   Messages are encrypted in layers (onion routing) and forwarded   
   through 3-6 randomly selected nodes before reaching their destination.   
      
   ### What Works ✓   
      
   - **Sphinx Mixnet Protocol**: Full implementation with AES-256-GCM   
   encryption   
   - **Variable-Hop Routing**: Random 3-6 hops per message   
   - **Random Route Selection**: Complete shuffling of available nodes   
   - **Batch Processing**: Messages batched and shuffled to resist timing   
   attacks   
   - **Forward Secrecy**: Ephemeral ECDH keys for each hop   
   - **Tor Integration**: All inter-node communication over Tor hidden services   
   - **SMTP Gateway**: Standard SMTP interface for sending messages   
   - **Persistent Keys**: Node keys saved and reloaded across restarts   
   - **Multi-Node Network**: Successfully tested with 4 nodes   
      
   ### Technical Details   
      
   Encryption:   
      - AES-256-GCM for payload encryption   
      - Curve25519 ECDH for shared secrets   
      - HKDF for key derivation   
      - HMAC-SHA256 for authentication (first hop only)   
      
   Security Features:   
      - Adaptive padding (512 bytes to 128KB buckets)   
      - Exponential timing delays (Poisson distribution)   
      - Replay protection (24-hour cache)   
      - Rate limiting (100 msg/hour per IP)   
      - No metadata retention   
      - Key rotation every 24 hours   
      
   Performance:   
      - Message processing: ~1-5 seconds per hop   
      - Batch delay: 5-60 seconds random   
      - Total latency: ~30-120 seconds for 3-6 hops   
      - Max message size: 10MB   
      
   ### Known Issues / Limitations   
      
   1. **Exit Node Visibility**: Final delivery to clearnet email is not   
   encrypted   
       (inherent limitation of SMTP protocol)   
      
   2. **Node Discovery**: Currently uses static JSON file for node directory   
       (no DHT or dynamic discovery yet)   
      
   3. **Scalability**: Tested with 4 nodes, larger networks untested   
      
   4. **Key Synchronization**: Requires manual distribution of nodes.json   
       after key rotation   
      
   5. **No Built-in Directory Authority**: PKI management is manual   
      
   6. **Limited Error Recovery**: Network failures may cause message loss   
      
   7. **Tor Dependency**: Requires properly configured Tor hidden services   
       on all nodes   
      
   ## Future Development Goals   
      
   ### Short-term (1-3 months)   
      
   - **Automated PKI Updates**: Nodes should publish their keys to a   
      distributed directory automatically   
      
   - **Better Error Handling**: Retry logic and message queue persistence   
      
   - **Monitoring Dashboard**: Real-time statistics and health monitoring   
      
   - **Testing Tools**: Automated testing suite for multi-node deployments   
      
   - **Documentation**: Comprehensive deployment guide and API documentation   
      
   ## Technical Architecture   
      
   Current implementation:   
      - Language: Go 1.21+   
      - Dependencies: golang.org/x/crypto, golang.org/x/net   
      - Transport: Tor SOCKS5 proxy   
      - Storage: JSON files (temporary)   
      - Configuration: Command-line flags   
      
   Code quality:   
      - Single-file implementation (~2000 lines)   
      - No external databases   
      - Minimal dependencies   
      - BSD-style license (planned)   
      
   ## Why Not Just Use Tor?   
      
   Good question! Tor provides excellent anonymity, but:   
      
   1. **Exit nodes see plaintext**: Tor exit nodes can read SMTP traffic   
   2. **Timing attacks**: Correlation attacks possible with global adversary   
   3. **No batching**: Messages forwarded immediately   
   4. **Limited padding**: Tor cells are fixed 512 bytes   
   5. **No mixing**: Direct circuit, no message mixing/reordering   
      
   fog adds an additional layer:   
      - Batch multiple messages together   
      - Add variable random delays   
      - Shuffle message order   
      - Adaptive padding beyond Tor's capabilities   
      - No single point sees both sender and content   
      
   Think of it as: Tor protects the transport, fog protects the timing.   
      
   ## Current Deployment   
      
   We currently operate a small test network:   
      - 4 nodes across different geographic locations   
      - All on Tor hidden services   
      - Approximately 90% uptime   
      - Processing ~10-50 test messages per day   
      
   We need feedback on:   
      
   1. Is the threat model realistic?   
   2. Are the security features sufficient?   
   3. Is the latency (30-120s) acceptable for email?   
   4. Should we prioritize anonymity or performance?   
   5. What features are most important?   
      
   ## Contact & Links   
      
   Project status: **Alpha** (use at your own risk)   
      
   We're sharing our work openly,   
   including limitations and bugs. If you're interested in anonymous   
   communication systems, we'd love your input.   
      
   Gabx   
   --   
   0745 074D FEAA 9CB7 62E9  D89D 3E54 F490 F2CC 5A82   
   https://yamn.virebent.art   
   https://news.tcpreset.net   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)