schema System Specifications

Zero-Knowledge Protocol

A technical deep dive into how EnvGuard physically separates ciphertext from encryption keys to guarantee absolute data privacy.

laptop_mac
Sender Browser
Generates Key & IV
Encrypts Payload
database
Supabase DB
Stores Ciphertext
0 Bytes Key Data
URL Hash Fragment
#key=A7x...
devices
Receiver Browser
Parses Hash & Fetches
Local Decryption
01

Client-Side Key Generation

When a user selects an `.env` file, the browser's native Web Crypto API instantly generates a cryptographically secure 256-bit symmetric key. This key exists purely in RAM and is never part of an HTTP request body.

crypto.js
const encryptionKey = await window.crypto.subtle.generateKey( { name: "AES-GCM", length: 256 }, true, ["encrypt", "decrypt"] );
02

Authenticated Encryption

EnvGuard utilizes AES-256 in Galois/Counter Mode (GCM). GCM provides both data confidentiality and authenticity. An Initialization Vector (IV) is uniquely generated for every single encryption event. If the resulting ciphertext is tampered with in the database, the decryption process will mathematically fail upon retrieval.

encrypt.js
const iv = window.crypto.getRandomValues(new Uint8Array(12)); const encodedData = new TextEncoder().encode(rawEnvString); const encryptedBuffer = await window.crypto.subtle.encrypt( { name: "AES-GCM", iv: iv }, encryptionKey, encodedData );
03

URL Hash Architecture

The stroke of zero-knowledge genius lies in URL fragments. When the ciphertext is saved, the server responds with a unique Document ID. The client combines this ID with the raw decryption key inside the URL hash `#`. According to HTTP RFC specifications, browsers never send hash fragments to the server.

The Final Link
https://envguard-io.vercel.app/share?id=550e8400-e29b#key=ZeX9L...
?id= (Sent to Server) Used to fetch the AES-256 ciphertext from the database.
#key= (Kept Local) Extracted via JS window.location.hash to decrypt the data locally.

gpp_bad Threat Model & Mitigations

Threat 1: Database Breach (Supabase Compromise)

An attacker gains root access to the PostgreSQL database.

verified_user

Mitigation: The database contains only AES-256-GCM ciphertexts and random IVs. Without the decryption keys (which reside only in the creator's URL), the data is mathematically secure.

Threat 2: Man-in-the-Middle (MITM) Interception

An attacker intercepts the network traffic between the browser and Vercel edges.

verified_user

Mitigation: Network requests are strictly enforced over TLS 1.3. More importantly, the payload is fully encrypted before it leaves the browser. The attacker intercepts only ciphertext.

help Technical FAQ

Why use AES-256-GCM instead of AES-CBC? expand_more
Galois/Counter Mode (GCM) provides Authenticated Encryption with Associated Data (AEAD). This ensures both confidentiality and data integrity, protecting against padding oracle attacks and ciphertext tampering that CBC is vulnerable to.
Can server logs or analytics capture the decryption key? expand_more
No. The decryption key is strictly in the URL fragment (`#key=...`). Browsers explicitly drop the hash fragment when sending HTTP requests to the server, making it invisible to Vercel logs, backend infrastructure, and frontend analytics scripts.
How does the Burn After Reading feature work technically? expand_more
When a decryption request is made for a payload flagged as 'Burn After Reading', the serverless edge function retrieves the ciphertext and executes a hard-delete SQL query on that row in the same transaction block before returning the response to the client.