Building EncroGram: A Messenger Where Servers Can't Read Your Messages

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:

1. Receives encrypted envelope


2. Forwards to recipient immediately
   


3. Deletes from memory


4. 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

1. 
   Reliability: Stateless servers mean no retry mechanisms


2. 
   User Education: People expect cloud backups


3. 
   Key Management: Perfect Forward Secrecy adds complexity


4. 
   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

1. Do you see value in technical vs policy privacy guarantees?


2. What attack vectors should I consider with this architecture?


3. 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?