Gnomit Secret Share

The Problem & Solution

Sharing sensitive data—like passwords, database keys, or API credentials—via email or standard chat apps exposes businesses to permanent data leak risks. Gnomit solves this by establishing a zero-knowledge trust model. Secrets are encrypted directly inside the user’s browser before transmission. Once retrieved by the recipient, the data immediately deletes itself from the database forever, minimizing the window of exposure.

---

Cryptographic Hardening

The application is structured to ensure the hosting server never has access to the decryption keys.

 [ Raw Secret ]
        │
        ▼ (Browser-Side Encryption)
  1. AES-GCM-256 key + 12-byte IV
  2. Encrypt ──► ciphertext (Base64)
        │                       │
        │ (#fragment = key)     │ POST /api/secrets (same origin)
        ▼                       ▼
 /view/{id}#KEY           [ Nginx → FastAPI → Redis ]
                                TTL 24h, burn on read

---

Engineering Highlights

1. Hash-Fragment Key Isolation

The decryption key is appended to the sharing URL as a hash fragment (#). Because web browsers do not transmit hash fragments to servers during HTTP requests, the decryption key never leaves the client machine, maintaining a true zero-knowledge structure.

2. Verified Burn-on-Read

To guarantee secrets are read only once, the FastAPI backend uses a transaction block that fetches and immediately deletes the ciphertext from Redis. Even if the reader refreshes the tab, the key is gone, preventing subsequent decryptions.

3. Hardened Production Sandbox

The service is containerized via Docker Compose. The API and Redis ports are bound exclusively to the internal network. Only Nginx is exposed, configured with strict Content Security Policies (CSP), HTTP security headers, and rate limits (limit_req) to block scripting attacks.