DEV Community

Alexander Suvorov
Alexander Suvorov

Posted on

The next step in privacy: A messenger that doesn't send data and doesn't keep your secrets. 🚀

#privacy #cryptography #security #opensource

The next step in privacy: A messenger that doesn't send data and doesn't keep your secrets. 🚀 💫 What if I told you that you could send messages without transmitting data AND without ever storing any secrets on your device?

Last time I introduced you to Chrono-Library Messenger — a crazy idea where messages aren't sent but discovered from a shared mathematical space. The response was incredible, but one question kept coming up:

"Great, but you still store the master secret in the database. What if someone steals it?"

And I realized I'd missed a key point in the first implementation that I'd used in my smart password manager. You don't need to store a secret phrase; you need to use a public key for authentication.

Meet Chrono-Library Messenger v2.0 — now with zero secret storage.

🔐 The Security Paradox We Solved

The Old Way (v1.x): 

# ❌ This was bad!
self.db.set_config('master_seed', master_seed)  # Secret stored in DB!
Enter fullscreen mode Exit fullscreen mode

The New Way (v2.0): 

# ✅ This is revolutionary!
public_key = auth.generate_public_key(username, master_seed)
self.db.set_config('public_key', public_key)  # Only proof is stored
# master_seed NEVER touches persistent storage!
Enter fullscreen mode Exit fullscreen mode

The breakthrough: We now use HMAC-SHA256 to generate a public key from your username and master phrase. We store only the public key. During login, you provide the master phrase again, we verify it against the stored public key using HMAC-SHA256 verification.

The master secret exists only in RAM during your session (as self.master_seed in the CLI object) and is completely wiped when you exit.

🚀 What's New in v2.0: Beyond Security

1. 🎯 Interactive Console Interface

Gone are the CLI commands. Now you have a full menu-driven experience:

🌌 CHRONO-LIBRARY MESSENGER
==================================================
👤 User: @cryptographer
1. 💬 My chats
2. ➕ Create a new chat
3. 📨 Send message
4. 📩 Receive a message
5. 📜 Message history
6. ⚙️ Profile settings
7. 🚪 Exit
Enter fullscreen mode Exit fullscreen mode

2. 💬 Real Chat Management

  • Create unlimited chat rooms
  • Organize conversations by topic
  • Full message history browsing
  • Proper message deletion and recovery

3. 🗑️ Message Recovery System

Accidentally deleted a message? No problem! The new trash system lets you:

  • Restore deleted messages
  • Permanently delete sensitive content
  • Browse through deletion history

🧠 The Philosophical Evolution

The original concept was mind-bending enough: messages that were never sent, but discovered.

v2.0 takes this further: secrets that are never stored, but verified.

The Double Paradox:

  1. Synchronous Discovery Without Transmission

    Messages emerge from mathematical space when parameters align

  2. Authentication Without Storage

    Identity is proven without persistent secrets

This isn't just better security—it's a fundamentally different approach to digital trust.

⚙️ How the Magic Works Now

Setup Phase:

  1. You choose a username and master phrase
  2. System generates: public_key = HMAC-SHA256(key_material) where key_material = f"{username}:{master_seed}"
  3. Only public_key and username are stored

Login Phase:

  1. You enter master phrase again
  2. System verifies it against the stored public key using HMAC-SHA256 verification
  3. If verification passes: access granted!

The Beautiful Part:

  • Database theft: Attacker gets only public keys (useless without master phrases)
  • Memory analysis: Master phrase exists only briefly in RAM during session
  • Future-proof: No secret residue anywhere on disk

🎯 Why This Matters Beyond Messaging

This isn't just about messages. It's about rethinking digital security fundamentals:

For Password Managers:

Why store encrypted passwords when you can generate them deterministically?

For Authentication Systems:

Why store password hashes when you can store proof-of-knowledge?

For Digital Preservation:

Why rely on servers when you can reconstruct everything from a seed?

The pattern is reusable anywhere we need to verify knowledge without exposing secrets.

🔧 Technical Deep Dive

The core authentication system (direct from source code):

class AuthManager:
    def generate_public_key(self, username: str, secret: str) -> str:
        # Note: Uses colon separator for unambiguous key material formation
        key_material = f"{username}:{secret}".encode('utf-8')
        hmac_obj = hmac.new(b'clm-auth-key', key_material, hashlib.sha256)
        return base64.b64encode(hmac_obj.digest()).decode('utf-8')

    def verify_secret(self, username: str, secret: str, stored_public_key: str) -> bool:
        generated_key = self.generate_public_key(username, secret)
        return generated_key == stored_public_key
Enter fullscreen mode Exit fullscreen mode

Elegant simplicity: No secrets in database, no complex crypto, just clean HMAC verification.

🌐 The Bigger Picture: Towards Zero-Trust Architecture

This approach aligns perfectly with zero-trust principles:

  • Never trust, always verify: Secrets are verified every session
  • Assume breach: Database compromise reveals nothing valuable
  • Minimal attack surface: No persistent secrets to target

⚠️ Important Limitations & Considerations

This is still a proof-of-concept! Not for protecting state secrets.

Current limitations:

  • Use of fixed HMAC key: The PoC uses a static HMAC key (b'clm-auth-key') for simplicity. A production implementation would use a unique per-instance key or standard KDF.
  • Metadata exposure: Chat IDs and timestamps are still public
  • No forward secrecy: Master phrase compromise reveals all history
  • Key exchange problem: Initial secret sharing still required
  • No message integrity: The protocol doesn't verify message authenticity yet

What we're working on:

  • Database encryption layer
  • Forward secrecy mechanisms
  • Secure key exchange protocols
  • Message authentication codes

🚀 Getting Started 

# Install
pip install chrono-library-messenger

# Run
clm

# First launch will guide you through setup
# Subsequent launches will ask for your secret phrase
Enter fullscreen mode Exit fullscreen mode

The project is open source on GitHub — contributions and security audits welcome!

🔮 The Future Is Deterministic

This isn't just about building a better messenger. It's about exploring what's possible when we question fundamental assumptions:

  • What if we didn't need to transmit data to communicate?
  • What if we didn't need to store secrets to authenticate?
  • What if security meant having less surface area to attack?

Chrono-Library Messenger v2.0 is a step toward that future. A future where we don't just encrypt better, but we architect systems that have nothing valuable to steal.

💬 Join the Discussion

I'm incredibly excited about this direction, but I want to hear from you:

  • Is this approach fundamentally sound?
  • Where else could zero-secret storage be applied?
  • What are the unconsidered attack vectors?

Let's continue this conversation on GitHub or Dev.to!

Keep exploring,
Alexander Suvorov

🔗 References & Related Projects:

📜 Disclaimer: This is a research project for educational purposes. Always use professionally audited security software for sensitive communications.

Top comments (0)