CipherNest

CipherNest started from a question that kept bothering me:

If messaging platforms say messages are encrypted, why do they still control the infrastructure, metadata, and retention policies?

Most messaging systems encrypt content, but the platform still owns the servers, stores metadata, and ultimately decides how long information survives.

I wanted to experiment with a different model — one where encryption happens client-side, identity is blockchain-native, and messages are designed to disappear automatically instead of living forever.

The problem

Modern messaging systems usually centralize at least one critical layer:

• identity management
• message storage
• encryption key handling
• metadata retention
• message persistence

Even when content is encrypted, platforms often still know:

• who talked to whom
• when messages were sent
• how long conversations lasted
• which devices were used

CipherNest was designed to minimize those assumptions as much as possible.

What we built

• End-to-end encrypted messaging — messages encrypted client-side using ECDH key exchange and AES symmetric encryption.
• Decentralized backend on ICP — message storage and access control handled through Internet Computer canisters.
• Ephemeral messaging system — every message carries a 24-hour TTL and gets removed automatically after expiration.
• Principal-based authentication — users authenticate using Internet Computer principals instead of traditional credentials.
• Message integrity verification — ECDSA signatures and hashing ensure messages cannot be modified silently.
• Configurable cryptography — users can choose between multiple elliptic curves and symmetric encryption modes depending on performance and security needs.

The architecture

CipherNest separates cryptography, storage, and identity into distinct layers.

Client-Side Encryption
        ↓
ECDH Key Exchange
        ↓
AES Message Encryption
        ↓
Encrypted Payload Upload
        ↓
ICP Canister Storage
        ↓
TTL-Based Garbage Collection

The frontend handles encryption entirely in the browser using the Web Crypto API before messages are sent to the backend canister.

The backend never sees plaintext message content.

The backend

The backend is written in Motoko and deployed as Internet Computer canisters.

Messages are stored using trie-based structures for efficient lookup and cleanup.

type Message = {
    from: Principal;
    encryptedContent: Blob;
    publicKey: Blob;
    timestamp: Int;
    expiresAt: Int;
}

Each message contains:

• sender principal
• encrypted payload
• public key metadata
• expiration timestamp

Expired messages are automatically removed through scheduled cleanup routines.

Decisions worth calling out

• Client-side encryption only — plaintext messages never leave the browser.
• ECDH over static symmetric keys — session keys are derived dynamically for forward secrecy.
• 24-hour TTL by default — storage persistence was intentionally treated as temporary instead of permanent.
• Principal-based identity — Internet Computer principals simplify authentication without requiring username/password systems.
• Multiple cryptographic curve options — users can choose between faster curves like P-256 or stronger options like P-521 depending on threat models.

Trade-offs I made

The biggest trade-off was usability versus cryptographic strictness.

Automatic key rotation, ephemeral storage, and browser-side cryptography improve privacy, but they also make debugging and state synchronization significantly harder compared to traditional centralized messaging systems.

I also intentionally avoided storing searchable plaintext metadata because it would have simplified features like search and analytics while weakening privacy guarantees.

Security model

CipherNest uses layered cryptography:

• ECDH for shared secret generation
• AES-GCM for symmetric encryption
• PBKDF2 for key strengthening
• SHA-384 for hashing
• ECDSA signatures for integrity verification

The system supports multiple elliptic curves:

ENCRYPTION_ALGORITHMS = {
  ECDH_P384: 'P-384',
  ECDH_P256: 'P-256',
  ECDH_P521: 'P-521'
}

The default configuration prioritizes balanced performance and security using P-384 + AES-GCM.

What it taught me

This project taught me that secure systems engineering is mostly about trade-offs.

Strong cryptography alone does not automatically create a secure application. The difficult part is designing systems where identity, storage, lifecycle management, and usability do not quietly undermine the security guarantees you're trying to build.

It also gave me a much deeper understanding of browser cryptography, decentralized compute models, and how difficult state management becomes once persistence is intentionally temporary.