The Problem That Kept Me Up at Night
As developers, we build "secure" messaging apps with excellent end-to-end encryption. But there's a fundamental issue: we still store encrypted messages on servers.
Sure, the encryption is solid. But stored data creates attack vectors:
- Server compromises expose encrypted databases
- Governments can demand stored content
- Companies change privacy policies
- Long-term cryptographic attacks become possible
I wondered: What if servers literally couldn't store messages?
Introducing EncroGram
I built EncroGram with a different architecture: stateless relay servers.
Instead of the typical encrypt → store → forward model:
Client A → [EncroGram Relay] → Client B
(immediate deletion)
The relay server:
- Receives encrypted envelope
- Forwards to recipient immediately
- Deletes from memory
- Stores nothing, logs nothing
Technical Architecture
Backend: Rust-based relay servers
Frontend: C# MAUI cross-platform app
Crypto: Custom implementation with Perfect Forward Secrecy
Key Features
- Zero Server Storage: Messages deleted immediately after relay
- Perfect Forward Secrecy: Keys rotate automatically
- Sealed Sender: Servers only see recipient hash, never identity
- Emergency Wipe: Code "0000" destroys all device data instantly
- Anonymous: No phone numbers, emails, or personal data required
The Security Model
What This Solves:
✅ Eliminates server-side data retention completely
✅ Makes mass surveillance economically unviable
✅ Provides technical guarantees vs policy promises
What This Doesn't Solve:
❌ Endpoint security (device compromise still possible)
❌ Network analysis (traffic correlation attacks)
❌ Requires trust that relay operators are honest
Real-World Impact
When authorities request user data from EncroGram, the honest answer is:
"We have no data. Our servers don't store messages."
Not a policy decision - a technical reality.
The Trade-offs
Compared to Signal/WhatsApp:
- ❌ No cloud backup/message recovery
- ❌ Requires real-time delivery
- ❌ Less convenient for casual users
- ✅ Zero server-side attack surface
- ✅ Technical impossibility of data retention
- ✅ Perfect for high-risk scenarios
Development Challenges
- Reliability: Stateless servers mean no retry mechanisms
- User Education: People expect cloud backups
- Key Management: Perfect Forward Secrecy adds complexity
- Performance: Real-time relay requirements
Current Status
- iOS app submitted to App Store
- Self-hostable relay server implementation
- Subscription model ($19.99/quarter) to fund infrastructure
- Planning open source release after security audit
The Philosophy
Sometimes the best way to protect user privacy is to make surveillance technically impossible, not just against policy.
Why This Matters
Current "secure" messengers rely on policy promises:
- "We won't read your messages"
- "We delete messages after X days"
- "We resist government requests"
EncroGram provides technical guarantees:
- "We cannot read your messages"
- "Messages are deleted immediately"
- "We have no data to provide"
Target Users
EncroGram isn't for everyone. It's designed for:
- Journalists protecting sources
- Activists in authoritarian regimes
- Business executives with trade secrets
- Anyone who needs technical privacy guarantees
Questions for the Community
- Do you see value in technical vs policy privacy guarantees?
- What attack vectors should I consider with this architecture?
- Would you trade convenience for stronger privacy assurances?
Not trying to replace Signal for casual users - just exploring whether technical architecture can provide stronger privacy foundations.
What do you think? Is the convenience trade-off worth technical privacy guarantees?
Top comments (0)