ZeroKey Architecture

ZeroKey is a paranoid-grade, zero-knowledge payload delivery system designed for ethical hackers, journalists, and privacy advocates. It guarantees that sensitive information is transmitted across the internet without leaving a digital paper trail or falling victim to middle-man interceptions. Here is the full technical breakdown of our security pipeline.

1. The Cryptographic Engine

ZeroKey does not trust the server. All encryption happens completely locally inside your browser's memory using the native Web Crypto API before a single byte of data is transmitted over the network.

  • Key Derivation (PBKDF2): If a PIN is provided, it is combined with a cryptographically secure random 16-byte salt and hashed 100,000 times using the SHA-256 algorithm. This intentional computational delay thwarts brute-force attacks.
  • Encryption Standard (AES-256-GCM): Your text and converted media buffers are encrypted using the Advanced Encryption Standard with a 256-bit key. We specifically use Galois/Counter Mode (GCM) because it provides Authenticated Encryption. If an attacker alters even a single bit of the encrypted blob in transit, the decryption will automatically fail.

2. Distributed Cloud Storage

Once the data is scrambled into high-entropy, unreadable ciphertext, it is transmitted via TLS 1.3 to our backend infrastructure powered by Supabase. We separate the text and media to optimize performance and security:

  • Text & Metadata (PostgreSQL): The Base64 encrypted text string, the Initialization Vector (IV), and the salt are stored in a strict row-level-secured PostgreSQL database.
  • Media Blobs (Object Storage): Images and files (up to 2MB) are uploaded to a locked Storage Bucket. The database only holds a reference path to this bucket. Because the file was encrypted on the client side, the server only sees a meaningless application/octet-stream blob.

3. The URL Hash Exploit

The biggest challenge in end-to-end encryption is sharing the key. ZeroKey uses a standard web architecture feature to achieve this securely. A generated link looks like this:

https://zerokey.vercel.app/view?id=uuid-string&salt=base64#SECRET_KEY_DATA

The Fragment Identifier (anything following the #) is designed to jump to sections on a webpage. Because of this, standard web browsers never transmit the fragment to the server. The decryption key effectively hitches a ride on the URL but drops off before the HTTP request hits our backend, ensuring a true Zero-Knowledge pipeline.

4. Bot-Shields & Geofencing

Before decryption can even be attempted, the recipient must pass localized security checkpoints:

  • Anti-Bot WebAuthn: Social media apps (like WhatsApp or Slack) automatically scan links to generate previews. To prevent these bots from triggering the "burn" sequence, ZeroKey requires physical human interaction and invokes the device's native WebAuthn (FaceID/Fingerprint) hardware.
  • GPS Radius Locking: If enabled, the sender's coordinates are encrypted within the payload. The recipient's browser calculates the Haversine distance locally. If the recipient is outside the 50-meter radius, the payload immediately self-destructs without decrypting.

5. Volatile Memory & Destruction

ZeroKey is designed to exist strictly in volatile memory (RAM). When media is decrypted, we use URL.createObjectURL() to render the image directly from RAM, ensuring it is never cached or written to the device's physical hard drive.

The exact millisecond the data is successfully fetched, the API executes a permanent DELETE command on the PostgreSQL row and a REMOVE command on the Storage bucket. After 30 seconds, the local ObjectURL is revoked, and the browser's garbage collector wipes the payload from local memory. It is gone forever.