Zero-Knowledge Security Architecture

Understanding the advanced security and encryption behind SecureShare

Client-Side AES-256-GCM
Military-grade encryption happens entirely in your browser

We use the Web Crypto API to generate AES-256-GCM encryption keys and encrypt your data locally. The encryption key never leaves your device and is embedded in the URL fragment.

URL Fragment Key Storage
Encryption keys are never sent to our servers

The decryption key is stored in the URL fragment (after #) which is never transmitted to servers. This ensures true zero-knowledge architecture where we cannot access your data.

Redis Storage with TTL
Encrypted data stored in Redis with automatic expiration

Only encrypted data is stored in Upstash Redis with automatic TTL expiration. No encryption keys, metadata, or plaintext data is ever stored on our servers.

View-Based Auto-Destruction
Automatic deletion after maximum views reached

Set view limits from 1-10. Once the maximum number of views is reached, the encrypted data is immediately deleted from Redis with no recovery possible.

Technical Security Details

AES-256-GCM Encryption

We use AES-256-GCM (Galois/Counter Mode) which provides both encryption and authentication. Each encryption uses a unique 96-bit initialization vector (IV) for maximum security.

Web Crypto API

All cryptographic operations use the browser's native Web Crypto API, which provides hardware-accelerated, secure random number generation and encryption.

Zero Server-Side Key Access

Encryption keys are generated client-side and embedded in URL fragments. Since fragments are never sent to servers, we have zero access to decryption keys.

Automatic TTL Expiration

Redis automatically expires and deletes encrypted data based on TTL. No manual cleanup or maintenance required.

Security Flow Diagram
1
Client generates AES-256 key

Web Crypto API generates cryptographically secure key

2
Data encrypted client-side

AES-256-GCM encryption with unique IV

3
Encrypted data sent to Redis

Only ciphertext and IV stored, never the key

4
Key embedded in URL fragment

Fragment (#) never sent to server

5
Client-side decryption

Recipient's browser decrypts using key from URL

Best Practices

Use HTTPS Always

Always share links over HTTPS to prevent man-in-the-middle attacks on the encrypted data.

Short Expiration Times

Use the shortest reasonable expiration time to minimize the window of exposure.

Single-Use Links

Set max views to 1 for maximum security, especially for highly sensitive credentials.

Share Complete URLs

Ensure the complete URL including the fragment (#) is shared - without it, decryption is impossible.