How We Built a Zero-Knowledge Secret Sharing Tool with Cloudflare in 5 Days

The design constraint was simple: the provider must never be able to read a secret, even with full infrastructure access. That rules out server-side encryption with provider-held keys. Encryption happens exclusively in the browser; the Worker is a courier for opaque blobs.

Architecture Overview

Two tiers, not three. The Next.js frontend owns all crypto via the Web Crypto API. Sensitive data becomes ciphertext before it leaves the device. The Cloudflare Worker receives encrypted blobs and stores them in KV without any ability to decrypt. If the entire backend were compromised, attackers would find ciphertext and IVs — not keys.

What Never Touches the Server

• Plaintext secrets
• AES encryption keys (URL fragment only)
• User accounts or identity for anonymous shares

What does touch the server: ciphertext, IV, a random ID, and a TTL. That is the entire trust boundary.

Backend Implementation with Cloudflare Workers

Core store and retrieve (burn-after-read) handlers:

// Store endpoint - saves an encrypted secret
async function handleStore(request) {
  const { encryptedData, expiresAt } = await request.json();
  
  // Generate a random ID for the secret
  const id = crypto.randomUUID();
  
  // Store the encrypted data in KV with TTL
  await SECRETS_STORE.put(
    id,
    JSON.stringify({ encryptedData }),
    { expirationTtl: 604800 } // 7 days in seconds
  );
  
  return new Response(
    JSON.stringify({ id }),
    { headers: { 'Content-Type': 'application/json' } }
  );
}

// Retrieve endpoint - gets and deletes a secret (one-time access)
async function handleRetrieve(request, id) {
  // Get the secret from KV
  const secretData = await SECRETS_STORE.get(id);
  
  if (!secretData) {
    return new Response(
      JSON.stringify({ error: 'Secret not found or already viewed' }),
      { status: 404, headers: { 'Content-Type': 'application/json' } }
    );
  }
  
  // Delete the secret immediately (one-time access)
  await SECRETS_STORE.delete(id);
  
  return new Response(
    secretData,
    { headers: { 'Content-Type': 'application/json' } }
  );
}

Frontend Encryption with Web Crypto API

On the frontend, we use the Web Crypto API (secure contexts only: HTTPS or localhost) to handle encryption and decryption — no third-party crypto libraries:

// Generate a random encryption key
async function generateEncryptionKey() {
  return window.crypto.subtle.generateKey(
    { name: "AES-GCM", length: 256 },
    true,
    ["encrypt", "decrypt"]
  );
}

// Encrypt data with the generated key
async function encryptData(key, data) {
  // Create a random initialization vector
  const iv = window.crypto.getRandomValues(new Uint8Array(12));
  
  // Encode the data as UTF-8
  const encodedData = new TextEncoder().encode(data);
  
  // Encrypt the data
  const encryptedBuffer = await window.crypto.subtle.encrypt(
    { name: "AES-GCM", iv },
    key,
    encodedData
  );
  
  // Convert the encrypted data and IV to base64
  const encryptedData = bufferToBase64(encryptedBuffer);
  const ivBase64 = bufferToBase64(iv);
  
  return { encryptedData, iv: ivBase64 };
}

// Decrypt data with the provided key
async function decryptData(key, encryptedData, iv) {
  // Convert base64 back to ArrayBuffer
  const encryptedBuffer = base64ToBuffer(encryptedData);
  const ivBuffer = base64ToBuffer(iv);
  
  // Decrypt the data
  const decryptedBuffer = await window.crypto.subtle.decrypt(
    { name: "AES-GCM", iv: ivBuffer },
    key,
    encryptedBuffer
  );
  
  // Decode the decrypted data as UTF-8
  return new TextDecoder().decode(decryptedBuffer);
}

Secret URL Generation

When a user creates a secret, we:

1. Generate a random encryption key
2. Encrypt the secret with this key
3. Send the encrypted data to the server
4. Receive a unique ID from the server
5. Create a URL with the ID and the encryption key as a fragment

The encryption key is never sent to the server. Instead, it's added as a URL fragment (the part after the # symbol). Browsers do not include fragments in HTTP requests, so Workers and KV never receive the key — even in access logs.

// Create a secret URL
async function createSecretUrl(secret) {
  // Generate a random encryption key
  const key = await generateEncryptionKey();
  
  // Export the key to raw format
  const rawKey = await window.crypto.subtle.exportKey("raw", key);
  
  // Convert the key to base64
  const keyBase64 = bufferToBase64(rawKey);
  
  // Encrypt the secret
  const { encryptedData, iv } = await encryptData(key, secret);
  
  // Send the encrypted data to the server
  const response = await fetch('/api/store', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ encryptedData, iv })
  });
  
  const { id } = await response.json();
  
  // Create the secret URL with the key as a fragment
  return `${window.location.origin}/s/${id}#k=${keyBase64}`;
}

Deploying our solution to production was straightforward thanks to Cloudflare's developer-friendly tools:

1. Setting Up the KV Namespace

# Create a KV namespace for secrets
wrangler kv:namespace create "SECRETS_STORE"

# Add the namespace to wrangler.toml
# kv_namespaces = [
#   { binding = "SECRETS_STORE", id = "your-namespace-id" }
# ]

2. Configuring CORS for Multiple Domains

Since we operate on two domains (vanishingvault.com and secretdropbox.com), we needed to configure CORS properly:

// CORS headers function
function corsHeaders(request) {
  // Get the origin from the request
  const origin = request.headers.get('Origin');
  const allowedOrigins = [
    'https://secretdropbox.com',
    'https://vanishingvault.com',
    'http://localhost:3000' // For development
  ];
  
  // Check if the origin is allowed
  const allowedOrigin = allowedOrigins.includes(origin) 
    ? origin 
    : allowedOrigins[0];
  
  return {
    'Access-Control-Allow-Origin': allowedOrigin,
    'Access-Control-Allow-Methods': 'GET, POST, DELETE, OPTIONS',
    'Access-Control-Allow-Headers': 'Content-Type',
    'Access-Control-Max-Age': '86400',
  };
}

3. Deploying the Worker

# Deploy the worker
wrangler deploy

# Configure custom domain routes
# In your Cloudflare dashboard:
# - Add a route pattern: secretdropbox.com/api/*
# - Add a route pattern: vanishingvault.com/api/*

Our zero-knowledge secret sharing tool is designed to address a variety of secure sharing needs:

• Share sensitive personal information with family members
• Securely transmit passwords to friends
• Send private account details to trusted contacts
• Share temporary access codes without leaving a trace

VanishingVault gives privacy-conscious individuals a secure way to share sensitive information. By leveraging Cloudflare's edge infrastructure and client-side encryption, secrets stay under user control while delivery stays global and simple.

Compare the wider landscape in best one-time secret sharing tools.