{"id":177341,"date":"2026-06-09T07:51:04","date_gmt":"2026-06-09T07:51:04","guid":{"rendered":"https:\/\/mycryptomania.com\/?p=177341"},"modified":"2026-06-09T07:51:04","modified_gmt":"2026-06-09T07:51:04","slug":"build-a-zero-knowledge-encrypted-document-vault-complete-developer-guide","status":"publish","type":"post","link":"https:\/\/mycryptomania.com\/?p=177341","title":{"rendered":"Build a Zero-Knowledge Encrypted Document Vault: Complete Developer Guide"},"content":{"rendered":"

By the end of this guide, you\u2019ll have built a file-sharing system where you the developer running the server cannot read your users\u2019\u00a0files.<\/em><\/strong><\/p>\n

\u23f1 Estimated read time: 20 minutes<\/em> \u00b7 \ud83c\udff7 Tags: cryptography, javascript, ipfs, security, web-dev, zero-knowledge<\/em><\/p>\n

Introduction<\/h3>\n

Most \u201csecure\u201d file apps encrypt data at rest on the server<\/strong>. That means the server holds the encryption key. Which means the server or anyone who compromises it can read your files. That\u2019s not security. That\u2019s\u00a0trust.<\/p>\n

A Zero-Knowledge<\/strong> vault is different. Files are encrypted in the browser before they are uploaded. The server stores only encrypted blobs. The encryption keys are wrapped using the user\u2019s RSA public key and stored separately on IPFS. The private key never leaves the user\u2019s device<\/strong>.\u00a0Ever.<\/p>\n

This guide walks through a complete, working implementation called SECUREDOC<\/strong>. We\u2019ll cover every meaningful piece of code: key pair generation, Pinata\/IPFS storage, the upload encryption pipeline, the share re-wrap flow, decryption, and access revocation. Each section includes both real JavaScript<\/strong> and language-agnostic pseudo-code<\/strong> so you can implement this in Python, Go, Rust, or any runtime with standard crypto libraries.<\/p>\n

TL;DR<\/em><\/strong>Every user has an RSA-2048 key pair generated in their\u00a0browserFiles are encrypted with a random AES-256-GCM key per\u00a0documentThat AES key is RSA-encrypted (wrapped) with the user\u2019s public key and stored on\u00a0IPFSSharing = re-wrapping the AES key for the recipient\u2019s public key, locally in the\u00a0browserThe server only stores: encrypted blobs (IPFS CIDs), wrapped key CIDs, and\u00a0metadataThe server cannot decrypt anything\u00a0ever<\/strong><\/p>\n

The Architecture at a\u00a0Glance<\/h3>\n

Before diving into code, here\u2019s the full system\u00a0map:<\/p>\n

\u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510
\u2502 USER’S BROWSER \u2502
\u2502 \u2502
\u2502 RSA Key Pair \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500 stays here (private key never leaves) \u2502
\u2502 AES Encrypt \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500 file encrypted before any network call \u2502
\u2502 Key Wrapping \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500 AES key encrypted with RSA public key \u2502
\u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518
\u2502 \u2502
\u25bc \u25bc
\u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510 \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510
\u2502 PINATA \/ IPFS \u2502 \u2502 EXPRESS BACKEND \u2502
\u2502 \u2502 \u2502 \u2502
\u2502 Encrypted Blob CID \u2502 \u2502 Document metadata \u2502
\u2502 Wrapped Key CID \u2502 \u2502 Access Control List \u2502
\u2502 (can’t read either) \u2502 \u2502 Public key registry \u2502
\u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518 \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518<\/p>\n

Part 1\u200a\u2014\u200aThe Cryptography, Plain\u00a0English<\/h3>\n

You don\u2019t need a math degree. You need two concepts.<\/p>\n

RSA-OAEP: Asymmetric Encryption<\/h3>\n

RSA uses two linked\u00a0keys<\/strong>:<\/p>\n

Public key<\/strong>\u200a\u2014\u200ashare this freely. Anyone can use it to encrypt data for\u00a0you<\/em>.Private key<\/strong>\u200a\u2014\u200akeep this secret. Only you can use it to decrypt data encrypted with your public\u00a0key.<\/p>\n

The golden rule: data encrypted with a public key can only be decrypted with its matching private key.<\/strong> Even the person who encrypted it can\u2019t decrypt it again without the private\u00a0key.<\/p>\n

We use RSA-OAEP with SHA-256<\/strong> the modern, padding-safe variant. Never use raw RSA (textbook RSA) in production.<\/p>\n

AES-GCM: Symmetric Encryption<\/h3>\n

AES is symmetric<\/strong> the same key encrypts and decrypts. It\u2019s extremely fast for large\u00a0files.<\/p>\n

We use AES-256-GCM<\/strong> specifically because GCM mode provides both confidentiality and<\/em> authentication. If anyone tampers with the encrypted bytes, decryption throws a hard error you can\u2019t get garbled output, you get\u00a0nothing.<\/p>\n

The Hybrid\u00a0Pattern<\/h3>\n

RSA is slow on large data. AES is fast but requires sharing the key securely. Solution: use\u00a0both.<\/p>\n

# Pseudo-code \u2014 the core pattern
symmetricKey = AES_GCM.generate_256bit_key() # fast key for the file
encryptedFile = AES_GCM.encrypt(symmetricKey, file) # encrypt the big file
wrappedKey = RSA_OAEP.encrypt(userPublicKey, symmetricKey) # protect the small key# What gets stored \/ transmitted:
store(encryptedFile) # safe \u2014 useless without the AES key
store(wrappedKey) # safe \u2014 only the private key holder can open this<\/p>\n

That\u2019s the entire vault in four lines. Everything else is implementation detail.<\/p>\n

Part 2\u200a\u2014\u200aSetting Up Pinata (IPFS\u00a0Storage)<\/h3>\n

IPFS<\/strong> is a decentralized content-addressed storage network. Pinata<\/strong> is a managed pinning service that gives you a reliable HTTP API on top of it. Files are stored by their content hash (CID) immutable, permanent, and globally accessible.<\/p>\n

Step 1: Create a Pinata Account and Generate a\u00a0JWT<\/h3>\n

Sign up at app.pinata.cloud<\/a> (free tier\u00a0works)Go to API Keys<\/strong> \u2192 New\u00a0Key<\/strong>Under Scopes<\/strong>, enable pinFileToIPFS only<\/strong>\u200a\u2014\u200athis is the only scope you\u00a0needClick Generate<\/strong> copy the JWT token<\/strong> immediately (it won\u2019t be shown\u00a0again)\u26a0\ufe0f <\/em>Principle of least privilege:<\/em><\/strong> Enable only <\/em>pinFileToIPFS. If this JWT is ever leaked, an attacker can pin new files but cannot delete or manage your existing pins. Never use an Admin key in a client-side app.<\/em><\/p>\n

Step 2: The Gateway\u00a0URL<\/h3>\n

Every file pinned to IPFS gets a CID. Fetch it back\u00a0using:<\/p>\n

GET https:\/\/gateway.pinata.cloud\/ipfs\/<CID><\/p>\n

Because every file in this system is AES-encrypted before upload<\/strong>, anyone who fetches the raw bytes from IPFS gets an unreadable blob. The CID being public is completely fine.<\/p>\n

Step 3: The Core Upload\u00a0Function<\/h3>\n

We use pinFileToIPFS for everything both the large encrypted blobs and the small wrapped key JSON\u00a0files.<\/p>\n

\/\/ JavaScript (browser)
async function pinataPinFile(fileBlob, filename, metadata = {}) {
const form = new FormData();
form.append(“file”, fileBlob, filename);
form.append(“pinataMetadata”, JSON.stringify({
name: filename,
keyvalues: metadata \/\/ optional searchable tags
}));
form.append(“pinataOptions”, JSON.stringify({ cidVersion: 1 })); \/\/ CIDv1 recommended const response = await fetch(“https:\/\/api.pinata.cloud\/pinning\/pinFileToIPFS”, {
method: “POST”,
headers: { Authorization: `Bearer ${PINATA_JWT}` },
body: form
\/\/ Note: do NOT set Content-Type header manually \u2014
\/\/ the browser sets it automatically with the correct boundary for multipart
}); if (!response.ok) {
const err = await response.text();
throw new Error(`Pinata upload failed (${response.status}): ${err}`);
} const data = await response.json();
return data.IpfsHash; \/\/ e.g. “bafybeifgc2voidpz2rh773vkvqutkpu…”
}# Pseudo-code (Python \/ Go \/ Rust \/ any language)
function pinataPinFile(fileBytes, filename, metadata):
form = new MultipartForm()
form.add_file_field(“file”, fileBytes, filename)
form.add_text_field(“pinataMetadata”, json_encode({ name: filename, keyvalues: metadata }))
form.add_text_field(“pinataOptions”, json_encode({ cidVersion: 1 })) response = http_post(
url = “https:\/\/api.pinata.cloud\/pinning\/pinFileToIPFS”,
headers = { “Authorization”: “Bearer ” + PINATA_JWT },
body = form
)
return response.json()[“IpfsHash”]CORS note:<\/em><\/strong> Pinata\u2019s API supports browser-side CORS out of the box. You can call it directly from client-side JavaScript with no proxy. If you\u2019re calling from a server-side backend (Node, Python, Go), standard HTTP requests work no special\u00a0setup.<\/em><\/p>\n

Part 3\u200a\u2014\u200aWallet Creation (Key Pair Generation)<\/h3>\n

Each user\u2019s \u201cwallet\u201d is an RSA-2048 key pair. Generated in the browser. The private key never touches the network\u200a\u2014\u200anot even encrypted at first generation.<\/p>\n

Generate the RSA Key\u00a0Pair<\/h3>\n

\/\/ JavaScript (browser \u2014 Web Crypto API)
async function generateKeyPair() {
const keyPair = await crypto.subtle.generateKey(
{
name: “RSA-OAEP”,
modulusLength: 2048, \/\/ 2048-bit \u2014 solid for 2025+
publicExponent: new Uint8Array([1, 0, 1]), \/\/ 65537 \u2014 standard safe exponent
hash: “SHA-256”
},
true, \/\/ extractable: yes (needed to export to JWK)
[“encrypt”, “decrypt”]
);
return keyPair; \/\/ { publicKey: CryptoKey, privateKey: CryptoKey }
}# Pseudo-code
function generateKeyPair():
return RSA.generate(
algorithm = “RSA-OAEP”,
key_size = 2048,
exponent = 65537,
hash = “SHA-256”,
usages = [“encrypt”, “decrypt”]
)
# Returns: { publicKey, privateKey }
# privateKey NEVER leaves this function’s caller context to the network<\/p>\n

Export the Public Key as\u00a0JWK<\/h3>\n

JWK (JSON Web Key) is the standard interoperable format for sharing cryptographic keys.<\/p>\n

\/\/ JavaScript
const pubKeyJWK = await crypto.subtle.exportKey(“jwk”, keyPair.publicKey);
\/\/ Result: { kty: “RSA”, alg: “RSA-OAEP-256”, n: “qW80Lgi…”, e: “AQAB”, … }
\/\/ Safe to send to the server \u2014 this is the PUBLIC key only<\/p>\n

Derive a User Identity from the Public\u00a0Key<\/h3>\n

Instead of random UUIDs, the user\u2019s identity is derived from their public key<\/strong>. This means the identity is cryptographically bound you can\u2019t claim someone else\u2019s identity without their\u00a0key.<\/p>\n

\/\/ JavaScript
async function deriveUserDID(publicKey) {
const pubJWKString = JSON.stringify(await crypto.subtle.exportKey(“jwk”, publicKey));<\/p>\n

\/\/ SHA-256 hash of the public key JSON
const hashBuffer = await crypto.subtle.digest(
“SHA-256”,
new TextEncoder().encode(pubJWKString)
);<\/p>\n

const hex = Array.from(new Uint8Array(hashBuffer))
.map(b => b.toString(16).padStart(2, “0”))
.join(“”);<\/p>\n

return `did:local:${hex.slice(0, 32)}`;
\/\/ e.g. “did:local:8912c294b807019086b09342da9f7cf0”
}# Pseudo-code
function deriveUserDID(publicKey):
pubKeyStr = json_encode(export_jwk(publicKey))
hash = SHA256(utf8_encode(pubKeyStr))
return “did:local:” + hex_encode(hash)[0:32]<\/p>\n

Register with the\u00a0Backend<\/h3>\n

After creating the wallet locally, send the public key<\/strong> and the encrypted wallet<\/strong> to the server. The encrypted wallet is the private key locked with the user\u2019s password the server stores it but cannot open\u00a0it.<\/p>\n

\/\/ JavaScript
async function registerUser(email, password, keyPair, did, encryptedWallet) {
const publicKeyJWK = await crypto.subtle.exportKey(“jwk”, keyPair.publicKey); const response = await fetch(“\/api\/auth\/register”, {
method: “POST”,
headers: { “Content-Type”: “application\/json” },
body: JSON.stringify({
email,
password, \/\/ hashed with bcrypt server-side
did,
publicKey: publicKeyJWK, \/\/ \u2705 safe to send \u2014 public key only
encryptedWallet \/\/ \u2705 private key AES-locked with user’s password
\/\/ privateKey \/\/ \u274c NEVER include this
})
});
return response.json(); \/\/ returns JWT token
}What is <\/em><\/strong>encryptedWallet?<\/em><\/strong> Before sending, the private key is exported to JWK format and encrypted with AES-GCM using a key derived from the user’s password via PBKDF2. The server stores this encrypted blob (<\/em>{ salt, iv, ciphertext }). On login, the server returns the blob and the browser decrypts it locally using the password. The password itself is <\/em>never sent to the server in the wallet derivation step<\/em><\/strong> only the hash sent for <\/em>bcrypt password verification.<\/em><\/p>\n

Part 4\u200a\u2014\u200aUpload & Encrypt a\u00a0Document<\/h3>\n

This is the core of the vault. Here\u2019s the full pipeline:<\/p>\n

File
\u2502
\u251c\u2500[1]\u2500 Generate AES-256-GCM key (K) \u2190\u2500\u2500 unique per document
\u2502
\u251c\u2500[2]\u2500 Encrypt file with K \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2192 Encrypted Blob
\u2502
\u251c\u2500[3]\u2500 SHA-256(original file) \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2192 Integrity Hash
\u2502
\u251c\u2500[4]\u2500 RSA_OAEP_encrypt(publicKey, K) \u2192 Wrapped Key (U1)
\u2502
\u251c\u2500[5]\u2500 Upload Encrypted Blob \u2192 Pinata \u2192 Blob CID
\u2502
\u251c\u2500[6]\u2500 Upload Wrapped Key \u2192 Pinata \u2192 Key CID
\u2502
\u2514\u2500[7]\u2500 POST metadata to server \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2192 Document registered<\/p>\n

Step 1: Generate a Symmetric Key<\/h3>\n

\/\/ JavaScript
async function generateSymmetricKey() {
return crypto.subtle.generateKey(
{ name: “AES-GCM”, length: 256 },
true, \/\/ extractable \u2014 needed for key wrapping
[“encrypt”, “decrypt”]
);
}# Pseudo-code
function generateSymmetricKey():
return AES_GCM.generate_key(bits=256, extractable=true)<\/p>\n

Every document gets its own unique key.<\/strong> This is critical: if one key is ever compromised, only that document is affected.<\/p>\n

Step 2: Encrypt the\u00a0File<\/h3>\n

\/\/ JavaScript
async function encryptFile(symmetricKey, fileArrayBuffer) {
\/\/ 12-byte random IV \u2014 MUST be unique for every encryption with the same key
const iv = crypto.getRandomValues(new Uint8Array(12)); const ciphertext = await crypto.subtle.encrypt(
{ name: “AES-GCM”, iv },
symmetricKey,
fileArrayBuffer
); return { ciphertext, iv };
\/\/ ciphertext: ArrayBuffer (file bytes, fully encrypted)
\/\/ iv: Uint8Array(12) (must be stored alongside ciphertext to decrypt)
}# Pseudo-code
function encryptFile(symmetricKey, fileBytes):
iv = random_bytes(12) # CRITICAL: never reuse IV with same key
ciphertext = AES_GCM.encrypt(
key = symmetricKey,
iv = iv,
data = fileBytes
)
return { ciphertext, iv }
# AES-GCM appends a 16-byte auth tag to ciphertext automatically
# If ciphertext is tampered with, decryption will throw \u2014 not return garbage\u26a0\ufe0f <\/em>The IV is not a secret.<\/em><\/strong> Store it alongside the ciphertext. What\u2019s critical is that you <\/em>never reuse the same IV with the same key<\/em><\/strong>\u200a\u2014\u200adoing so completely breaks AES-GCM confidentiality. Since every document gets a new random key, this is automatically safe.<\/em><\/p>\n

Step 3: Wrap the AES Key with\u00a0RSA<\/h3>\n

This step protects the symmetric key. The wrapped key can be stored publicly on IPFS\u200a\u2014\u200aonly the private key holder can open\u00a0it.<\/p>\n

\/\/ JavaScript
async function wrapSymmetricKey(symmetricKey, rsaPublicKey) {
\/\/ Export the AES key to raw bytes
const rawKeyBytes = await crypto.subtle.exportKey(“raw”, symmetricKey);
\/\/ rawKeyBytes is 32 bytes (256 bits) \/\/ Encrypt those bytes with RSA-OAEP
const wrappedKey = await crypto.subtle.encrypt(
{ name: “RSA-OAEP” },
rsaPublicKey,
rawKeyBytes
); return wrappedKey;
\/\/ wrappedKey: ArrayBuffer \u2014 256 bytes for RSA-2048
\/\/ Safe to store publicly \u2014 only the RSA private key can reverse this
}# Pseudo-code
function wrapSymmetricKey(symmetricKey, rsaPublicKey):
rawBytes = export_raw_bytes(symmetricKey) # 32 bytes
wrappedKey = RSA_OAEP.encrypt(rsaPublicKey, rawBytes)
return wrappedKey
# Result: ~256 bytes. Useless without the matching private key.<\/p>\n

Step 4: Upload Encrypted Blob to Pinata\/IPFS<\/h3>\n

\/\/ JavaScript
async function uploadEncryptedBlob(iv, ciphertext, originalFilename) {
\/\/ Pack into a single binary blob: [1 byte version][12 bytes IV][N bytes ciphertext]
const ivBytes = new Uint8Array(iv);
const ctBytes = new Uint8Array(ciphertext);
const packed = new Uint8Array(1 + ivBytes.length + ctBytes.length);
packed[0] = 1; \/\/ version byte \u2014 for future format changes
packed.set(ivBytes, 1);
packed.set(ctBytes, 1 + ivBytes.length); const blob = new Blob([packed.buffer], { type: “application\/octet-stream” });
return pinataPinFile(blob, `${originalFilename}.enc`, { type: “zk-enc-blob” });
\/\/ Returns CID \u2014 e.g. “bafybeifgc2voidpz2rh773…”
}# Pseudo-code
function uploadEncryptedBlob(iv, ciphertext, filename):
packed = concat_bytes([byte(1), iv, ciphertext]) # version + IV + data
return ipfs_upload(packed, filename + “.enc”)<\/p>\n

Step 5: Upload Wrapped Key to Pinata\/IPFS<\/h3>\n

\/\/ JavaScript
async function uploadWrappedKey(wrappedKeyBuffer, ownerDID) {
const payload = {
wrappedKey: btoa(String.fromCharCode(…new Uint8Array(wrappedKeyBuffer))),
\/\/ base64-encoded wrapped key \u2014 safe to store publicly
owner: ownerDID
};
const blob = new Blob([JSON.stringify(payload)], { type: “application\/json” });
return pinataPinFile(blob, `wrapped_key.json`, { type: “zk-wrapped-key” });
\/\/ Returns CID \u2014 e.g. “bafkreidjmhvyxz5ckzi5ouuo2…”
}# Pseudo-code
function uploadWrappedKey(wrappedKeyBytes, ownerDID):
payload = json_encode({
wrappedKey: base64_encode(wrappedKeyBytes),
owner: ownerDID
})
return ipfs_upload(payload, “wrapped_key.json”)<\/p>\n

Step 6: Anchor Metadata on the\u00a0Backend<\/h3>\n

\/\/ JavaScript
async function anchorDocument(docId, hash, blobCID, keyCID, ownerDID, filename) {
const response = await fetch(“\/api\/documents”, {
method: “POST”,
headers: { “Content-Type”: “application\/json” },
body: JSON.stringify({
docId,
hash, \/\/ SHA-256 of the ORIGINAL plaintext file
encryptedBlobCid: blobCID, \/\/ IPFS CID of the encrypted blob
wrappedKeyCid: keyCID, \/\/ IPFS CID of the wrapped key JSON
ownerDid: ownerDID,
filename
})
});
if (!response.ok) throw new Error(“Failed to anchor document on server”);
}<\/p>\n

The server stores only CIDs and metadata<\/strong> never file contents, never keys in plaintext.<\/p>\n

The Full Upload\u00a0Function<\/h3>\n

\/\/ JavaScript \u2014 full upload pipeline
async function uploadDocument(file, userPublicKey, userDID) {
const fileBuffer = await file.arrayBuffer(); \/\/ 1. Generate a unique AES key for this document
const symKey = await generateSymmetricKey(); \/\/ 2. Encrypt the file
const { ciphertext, iv } = await encryptFile(symKey, fileBuffer); \/\/ 3. SHA-256 hash of original file (integrity anchor)
const hashBuf = await crypto.subtle.digest(“SHA-256”, fileBuffer);
const hash = Array.from(new Uint8Array(hashBuf))
.map(b => b.toString(16).padStart(2, “0”)).join(“”); \/\/ 4. Wrap the AES key with the user’s RSA public key
const wrappedKey = await wrapSymmetricKey(symKey, userPublicKey); \/\/ 5. Upload encrypted blob to IPFS
const blobCID = await uploadEncryptedBlob(iv, ciphertext, file.name); \/\/ 6. Upload wrapped key to IPFS
const keyCID = await uploadWrappedKey(wrappedKey, userDID); \/\/ 7. Register document on backend
const docId = `doc_${Date.now()}_${Math.random().toString(36).slice(2, 6)}`;
await anchorDocument(docId, hash, blobCID, keyCID, userDID, file.name); console.log(” Upload complete.”);
console.log(” The server stored: blobCID, keyCID, SHA-256 hash, filename”);
console.log(” The server did NOT see: file contents, AES key, or private key”);
}# Pseudo-code (any language)
function uploadDocument(file, publicKey, userDID):
fileBytes = read(file)
symKey = AES_GCM.generate_key(256)
iv, cipher = AES_GCM.encrypt(symKey, fileBytes)
hash = SHA256(fileBytes)
wrappedKey = RSA_OAEP.encrypt(publicKey, export_raw(symKey))
blobCID = ipfs_upload(pack(iv, cipher))
keyCID = ipfs_upload(json({ wrappedKey: base64(wrappedKey) }))
server_post(“\/api\/documents”, { blobCID, keyCID, hash, userDID, filename })<\/p>\n

Part 5\u200a\u2014\u200aSharing a Document (The Re-Wrap\u00a0Flow)<\/h3>\n

This is the most technically interesting part of the entire system. When User 1 shares a document with User 2, the server never sees the AES key in plaintext<\/strong>. The re-encryption is done entirely in User 1\u2019s\u00a0browser.<\/p>\n

The 6-Step Share\u00a0Flow<\/h3>\n

\u2460 Fetch User 2’s public key from the server’s key registry
(safe \u2014 public keys are meant to be shared)\u2461 Fetch Wrapped Key (U1) from IPFS
(encrypted with User 1’s public key \u2014 safe to fetch over network)\u2462 [LOCAL] Decrypt Wrapped Key (U1) with User 1’s PRIVATE KEY
\u21b3 Recovers raw AES key bytes in browser memory
\u21b3 Private key never leaves the browser. Raw AES key never hits the network.\u2463 [LOCAL] Re-encrypt raw AES key bytes with User 2’s PUBLIC KEY
\u21b3 Creates Wrapped Key (U2)
\u21b3 Only User 2’s private key can open this\u2464 Upload Wrapped Key (U2) to Pinata\/IPFS
\u21b3 Returns new CID\u2465 Update Access Control List on server
\u21b3 Server links User 2’s DID to the new key CID for this document<\/p>\n

The Code<\/h3>\n

\/\/ JavaScript \u2014 full share flow
async function shareDocument(
docId, senderPrivateKey, senderDID,
recipientDID, existingWrappedKeyCID
) {
\/\/ Step 1: Fetch recipient’s public key from server registry
const pkRes = await fetch(`\/api\/did\/${encodeURIComponent(recipientDID)}\/publickey`);
if (!pkRes.ok) throw new Error(“Recipient not found. Have they created their wallet?”); const { publicKey: recipientJWK } = await pkRes.json();
const recipientPublicKey = await crypto.subtle.importKey(
“jwk”,
recipientJWK,
{ name: “RSA-OAEP”, hash: “SHA-256” },
false, \/\/ non-extractable \u2014 we only use it for encrypt
[“encrypt”]
); \/\/ Step 2: Fetch Wrapped Key (U1) from IPFS
const keyData = await fetch(
`https:\/\/gateway.pinata.cloud\/ipfs\/${existingWrappedKeyCID}`
).then(r => r.json());<\/p>\n

const wrappedKeyU1 = Uint8Array.from(
atob(keyData.wrappedKey), c => c.charCodeAt(0)
).buffer; \/\/ Step 3: LOCAL ONLY \u2014 Unwrap the AES key with sender’s private key
\/\/ The raw AES bytes live only in browser memory. Never sent anywhere.
const rawAESKeyBytes = await crypto.subtle.decrypt(
{ name: “RSA-OAEP” },
senderPrivateKey, \/\/ stays on device
wrappedKeyU1
);
\/\/ rawAESKeyBytes: 32 bytes in memory \u2014 the original AES-256 key \/\/ Step 4: LOCAL ONLY \u2014 Re-encrypt with recipient’s public key
const wrappedKeyU2 = await crypto.subtle.encrypt(
{ name: “RSA-OAEP” },
recipientPublicKey,
rawAESKeyBytes \/\/ same 32 bytes, now encrypted for recipient
); \/\/ Step 5: Upload new wrapped key to IPFS
const newKeyCID = await uploadWrappedKey(wrappedKeyU2, recipientDID); \/\/ Step 6: Update ACL on server
await fetch(“\/api\/share”, {
method: “POST”,
headers: { “Content-Type”: “application\/json” },
body: JSON.stringify({
docId,
recipientDid: recipientDID,
wrappedKeyCid: newKeyCID,
requesterDid: senderDID \/\/ server verifies this is the document owner
})
}); console.log(” Access granted to”, recipientDID);
console.log(” Server stored: new key CID for recipient”);
console.log(” Server did NOT see: raw AES key or any private key”);
}# Pseudo-code (any language)
function shareDocument(docId, senderPrivKey, senderDID, recipientDID, keyCID):
recipPubKey = fetch_from_server(“\/api\/did\/” + recipientDID + “\/publickey”)
wrappedU1 = ipfs_fetch(keyCID).wrappedKey # still encrypted
rawAESBytes = RSA_OAEP.decrypt(senderPrivKey, wrappedU1) # LOCAL ONLY
wrappedU2 = RSA_OAEP.encrypt(recipPubKey, rawAESBytes) # LOCAL ONLY
newCID = ipfs_upload(json({ wrappedKey: base64(wrappedU2) }))
server_post(“\/api\/share”, { docId, recipientDID, wrappedKeyCid: newCID, senderDID })\ud83d\udca1 <\/em>Key insight:<\/em><\/strong> The <\/em>encrypted file on IPFS is never touched during a share<\/em><\/strong>. Only a new wrapped key is created and uploaded. You can share a document with 100 users and the file is stored on IPFS exactly once. Each user gets their own personally-addressed wrapped copy of the AES\u00a0key.<\/em><\/p>\n

Part 6\u200a\u2014\u200aDecrypting & Downloading a\u00a0Document<\/h3>\n

When a user opens a document, their browser fetches the encrypted blob and their wrapped key, decrypts everything locally, and triggers a download.<\/p>\n

\/\/ JavaScript \u2014 full decrypt flow
async function decryptAndDownload(blobCID, wrappedKeyCID, filename, userPrivateKey) {
\/\/ 1. Fetch encrypted blob from IPFS
const blobResponse = await fetch(`https:\/\/gateway.pinata.cloud\/ipfs\/${blobCID}`);
const packedBuffer = await blobResponse.arrayBuffer(); \/\/ Unpack: skip version byte (index 0), read 12-byte IV, read remaining ciphertext
const packed = new Uint8Array(packedBuffer);
const iv = packed.slice(1, 13); \/\/ bytes 1\u201312
const ciphertext = packed.slice(13).buffer; \/\/ bytes 13 to end \/\/ 2. Fetch wrapped key from IPFS
const keyData = await fetch(`https:\/\/gateway.pinata.cloud\/ipfs\/${wrappedKeyCID}`)
.then(r => r.json());
const wrappedKey = Uint8Array.from(
atob(keyData.wrappedKey), c => c.charCodeAt(0)
).buffer; \/\/ 3. Unwrap AES key with user’s RSA private key (LOCAL)
const rawAESBytes = await crypto.subtle.decrypt(
{ name: “RSA-OAEP” },
userPrivateKey,
wrappedKey
); \/\/ Import raw bytes as a usable AES-GCM CryptoKey
const symmetricKey = await crypto.subtle.importKey(
“raw”, rawAESBytes,
{ name: “AES-GCM” },
false, \/\/ non-extractable after import
[“decrypt”]
); \/\/ 4. Decrypt the file
const plaintextBuffer = await crypto.subtle.decrypt(
{ name: “AES-GCM”, iv },
symmetricKey,
ciphertext
);
\/\/ If this succeeds, the key was correct AND the ciphertext wasn’t tampered with
\/\/ (AES-GCM authentication tag is verified automatically) \/\/ 5. Trigger browser download
const url = URL.createObjectURL(new Blob([plaintextBuffer]));
const a = document.createElement(“a”);
a.href = url;
a.download = filename;
document.body.appendChild(a);
a.click();
document.body.removeChild(a);
setTimeout(() => URL.revokeObjectURL(url), 1000); console.log(” Decrypted and downloaded. Server saw zero plaintext.”);
}# Pseudo-code (any language)
function decryptAndDownload(blobCID, keyCID, filename, privateKey):
encryptedBlob = ipfs_fetch(blobCID)
iv, ciphertext = unpack(encryptedBlob) # skip version byte, split at byte 13 wrappedKey = ipfs_fetch(keyCID).wrappedKey
rawAESBytes = RSA_OAEP.decrypt(privateKey, base64_decode(wrappedKey))
symmetricKey = AES_GCM.import_key(rawAESBytes) plaintext = AES_GCM.decrypt(symmetricKey, iv, ciphertext)
save_to_disk(filename, plaintext)On SHA-256 integrity:<\/em><\/strong> After decryption, you can optionally verify the file by computing <\/em>SHA256(plaintext) and comparing it to the <\/em>hash field stored in the server’s document registry during upload. If they match, the file is bit-for-bit identical to what was originally uploaded. Any IPFS-level tampering would also cause the AES-GCM auth tag check to fail first, so this is a secondary defense-in-depth measure.<\/em><\/p>\n

Part 7\u200a\u2014\u200aRevoking\u00a0Access<\/h3>\n

When you revoke a user\u2019s access, the server removes their entry from the document\u2019s Access Control\u00a0List.<\/p>\n

\/\/ JavaScript
async function revokeAccess(docId, recipientDID, ownerDID) {
const response = await fetch(“\/api\/share”, {
method: “DELETE”,
headers: { “Content-Type”: “application\/json” },
body: JSON.stringify({
docId,
recipientDid: recipientDID,
requesterDid: ownerDID \/\/ server verifies this matches the document owner
})
}); const result = await response.json();
if (result.success) {
console.log(`Access revoked for ${recipientDID}`);
}
}# Pseudo-code
function revokeAccess(docId, recipientDID, ownerDID):
server_delete(“\/api\/share”, { docId, recipientDID, ownerDID })<\/p>\n

What Revocation Does and Doesn\u2019t\u00a0Do<\/h3>\n

What it\u00a0does:<\/strong><\/p>\n

Removes the recipient\u2019s DID from the server\u2019s ACL for this\u00a0documentThe GET \/api\/documents\/:did endpoint no longer returns the document for the revoked\u00a0userTheir wrapped key CID pointer is deleted from the server\u2019s\u00a0recordsFuture attempts to list or access the document via the API will fail with\u00a0403<\/p>\n

What it doesn\u2019t\u00a0do:<\/strong><\/p>\n

IPFS content is immutable <\/strong>the wrapped key file (U2) that was previously uploaded to IPFS is not deleted. It\u2019s addressed by content hash and pinned globally.If the recipient already fetched and locally cached the wrapped key CID before revocation<\/em>, they technically still have the bytes to decrypt the document.For strong cryptographic revocation:<\/em><\/strong> Re-encrypt the document with a <\/em>brand new AES key<\/em><\/strong> after revocation. Then re-wrap the new key for every remaining authorized user and update all the CIDs. This is computationally more expensive but makes the old wrapped keys useless. For most real-world applications documents, file sharing, medical records ACL-level revocation is standard and sufficient.<\/em><\/p>\n

Part 8\u200a\u2014\u200aThe Backend API (Key\u00a0Routes)<\/h3>\n

The server handles authentication, key registry, document metadata, and ACL management. Here are the routes you need to implement:<\/p>\n

POST \/api\/auth\/register<\/h3>\n

Request:
{
“email”: “alice@example.com”,
“password”: “supersecret123”, \u2190 hashed with bcrypt(12) server-side
“did”: “did:local:8912c294b807…”,
“publicKey”: { “kty”: “RSA”, “alg”: “RSA-OAEP-256”, “n”: “…”, “e”: “AQAB” },
“encryptedWallet”: { “version”: 1, “salt”: “…”, “iv”: “…”, “ciphertext”: “…” }
}Response 201:
{ “token”: “eyJhbGci…”, “user”: { “id”: “user_1”, “email”: “alice@…”, “did”: “…” } }<\/p>\n

POST \/api\/auth\/login<\/h3>\n

Request:
{ “email”: “alice@example.com”, “password”: “supersecret123” }Response 200:
{
“token”: “eyJhbGci…”,
“user”: { “id”: “user_1”, … },
“encryptedWallet”: { “version”: 1, “salt”: “…”, “iv”: “…”, “ciphertext”: “…” },
“publicKey”: { “kty”: “RSA”, … }
}
\u2190 Server returns encryptedWallet so the browser can decrypt it locally
\u2190 The plaintext private key is NEVER in this response<\/p>\n

POST \/api\/documents<\/h3>\n

Request:
{
“docId”: “doc_1779097856281_287z”,
“hash”: “6a1e70b95c82514041db571…”,
“encryptedBlobCid”: “bafybeifgc2voidpz2…”,
“wrappedKeyCid”: “bafkreidjmhvyxz5ck…”,
“ownerDid”: “did:local:8912c294…”,
“filename”: “my_will.pdf”
}
Response 200: { “success”: true, “docId”: “doc_1779097856281_287z” }<\/p>\n

GET \/api\/documents\/:did<\/h3>\n

Returns all documents the given DID has access to (either as owner or shared recipient).<\/p>\n

Response 200:
{
“documents”: [
{
“docId”: “doc_1779…”,
“filename”: “my_will.pdf”,
“hash”: “6a1e70b9…”,
“encryptedBlobCid”: “bafybeifgc2…”,
“wrappedKeyCid”: “bafkreidjm…”, \u2190 the wrapped key for THIS DID
“isOwner”: true
}
]
}<\/p>\n

POST \/api\/share<\/h3>\n

Request:
{
“docId”: “doc_1779…”,
“recipientDid”: “did:local:0ef56523…”,
“wrappedKeyCid”: “bafkreic22hrkc6vy…”, \u2190 CID of the new Wrapped Key (U2)
“requesterDid”: “did:local:8912c294…” \u2190 must be document owner
}
Response 200: { “success”: true }<\/p>\n

DELETE \/api\/share<\/h3>\n

Request:
{
“docId”: “doc_1779…”,
“recipientDid”: “did:local:0ef56523…”,
“requesterDid”: “did:local:8912c294…”
}
Response 200: { “success”: true }<\/p>\n

Part 9\u200a\u2014\u200aThe Zero-Knowledge Proof: Live\u00a0Demo<\/h3>\n

The best way to prove the system works is to try to break it. Here\u2019s what happens when someone tries to decrypt a document without authorization:<\/p>\n

\/\/ JavaScript \u2014 attempting to decrypt without the correct wrapped key
async function demonstrateZeroKnowledge(blobCID) {
\/\/ Step 1: Fetch the encrypted blob from IPFS (always works \u2014 IPFS is public)
const response = await fetch(`https:\/\/gateway.pinata.cloud\/ipfs\/${blobCID}`);
const packedBuffer = await response.arrayBuffer();
const packed = new Uint8Array(packedBuffer);
const iv = packed.slice(1, 13);
const ciphertext = packed.slice(13).buffer; \/\/ Step 2: Try to decrypt with a completely wrong AES key
const wrongKey = await crypto.subtle.generateKey(
{ name: “AES-GCM”, length: 256 }, false, [“decrypt”]
); try {
await crypto.subtle.decrypt({ name: “AES-GCM”, iv }, wrongKey, ciphertext);
console.error(“This should NEVER happen \u2014 something is wrong”);
} catch (err) {
\/\/ AES-GCM verifies an authentication tag on decrypt.
\/\/ A wrong key produces the wrong tag \u2192 hard cryptographic failure.
console.log(“\u2705 Decryption FAILED as expected”);
console.log(” Error:”, err.name, “\u2014”, err.message);
\/\/ Output: OperationError \u2014 The operation failed for an operation-specific reason
console.log(” Without the correct wrapped key from the ACL,”);
console.log(” decryption is mathematically impossible.”);
console.log(” Not hard. Not unlikely. Impossible.”);
}
}<\/p>\n

The result:<\/strong> OperationError\u200a\u2014\u200aThe operation failed for an operation-specific reason<\/p>\n

AES-GCM appends a 16-byte authentication tag<\/strong> to every ciphertext. Any decryption attempt with the wrong key produces the wrong tag\u200a\u2014\u200aand the Web Crypto API throws immediately. You don\u2019t get garbled output. You don\u2019t get partial data. You get\u00a0nothing.<\/p>\n

This is the zero-knowledge guarantee in action. An attacker with full read access to the server database and full read access to IPFS has exactly the same problem as a random person on the internet: they can fetch the encrypted blobs, but without the correct wrapped key and a private key to unwrap it, the data is permanently inaccessible.<\/p>\n

Part 10\u200a\u2014\u200aImplementing This in Other Languages<\/h3>\n

Every crypto primitive used here is available in all major languages. The concepts are identical only the syntax\u00a0differs.<\/p>\n

Python Example (Key Wrapping)<\/h3>\n

from cryptography.hazmat.primitives.asymmetric import rsa, padding
from cryptography.hazmat.primitives import hashes
from cryptography.hazmat.primitives.ciphers.aead import AESGCM
import os, base64# Generate RSA key pair
private_key = rsa.generate_private_key(public_exponent=65537, key_size=2048)
public_key = private_key.public_key()# Generate AES-256 key
aes_key = os.urandom(32)# Encrypt file with AES-GCM
iv = os.urandom(12)
aesgcm = AESGCM(aes_key)
ciphertext = aesgcm.encrypt(iv, file_bytes, None)# Wrap AES key with RSA public key
wrapped_key = public_key.encrypt(
aes_key,
padding.OAEP(
mgf=padding.MGF1(algorithm=hashes.SHA256()),
algorithm=hashes.SHA256(),
label=None
)
)# Unwrap (decrypt) with private key
recovered_key = private_key.decrypt(
wrapped_key,
padding.OAEP(
mgf=padding.MGF1(algorithm=hashes.SHA256()),
algorithm=hashes.SHA256(),
label=None
)
)
# recovered_key == aes_key \u2713<\/p>\n

The architecture is the same. Upload the encrypted blob and base64(wrapped_key) to Pinata, anchor the CIDs on the\u00a0server.<\/p>\n

Part 11\u200a\u2014\u200aSecurity Quick\u00a0Tips<\/h3>\n

\ud83d\udd10 Never log or persist the private key in plaintext.<\/strong> Keep it in memory only. Wipe it on logout by overwriting the variable and triggering garbage collection.<\/p>\n

\ud83d\udd10 Always generate a fresh IV per encryption.<\/strong> crypto.getRandomValues(new Uint8Array(12)) every single time. Reusing an IV with the same AES key breaks GCM confidentiality catastrophically.<\/p>\n

\ud83d\udd10 Scope your Pinata JWT to <\/strong>pinFileToIPFS only.<\/strong> If leaked, an attacker can pin new files but cannot delete, query, or manage your existing\u00a0pins.<\/p>\n

\ud83d\udd10 Serve the app over HTTPS.<\/strong> Client-side crypto only protects data in transit on IPFS and the server. A MITM attacker who can inject JavaScript into your app page can steal the private key before it\u2019s used. HTTPS prevents\u00a0this.<\/p>\n

\ud83d\udd10 Use environment variables for <\/strong>JWT_SECRET.<\/strong> Never hardcode it. A leaked JWT secret means token forgery. Generate with openssl rand -hex\u00a064.<\/p>\n

\ud83d\udd10 sessionStorage, not localStorage, for the session wallet.<\/strong> sessionStorage is cleared when the tab closes. localStorage persists indefinitely across sessions and is a much larger attack surface. The private key session copy should be tab-scoped.<\/p>\n

\ud83d\udd10 Treat the DID registry as a trust anchor.<\/strong> In this implementation, the server hosts the public key registry. A compromised server could serve a malicious public key to a sharer, causing them to wrap a key for an attacker\u2019s key rather than the intended recipient. For production, anchor public keys on an immutable ledger (blockchain, Hyperledger, or a transparency log).<\/p>\n

What\u2019s Next<\/h3>\n

This implementation is production-grade for a wide range of use cases. If you want to push it further: key rotation<\/strong> (re-wrap all document keys when a user regenerates their RSA pair), WebAuthn binding<\/strong> (tie private key decryption to a hardware security key, TouchID, or FaceID so even sessionStorage compromise can\u2019t expose the key), and recovery mnemonics<\/strong> (give users a 12-word BIP39 phrase at registration currently, a forgotten password permanently loses the private key and all documents with\u00a0it).<\/p>\n

The full source code for this reference implementation is available on GitHub. If you build something with it, I\u2019d love to hear about it.<\/p>\n

Github Link\u00a0: https:\/\/github.com\/muhammadtalha198\/ZeroKnowladge_Document_Upload<\/a><\/p>\n

Conclusion<\/h3>\n

Here\u2019s what you\u2019ve\u00a0built:<\/p>\n

Files encrypted before<\/strong> they leave the browser with AES-256-GCMAES keys wrapped with RSA-2048-OAEP<\/strong> and stored on\u00a0IPFSDocument sharing via client-side key re-wrapping<\/strong>\u200a\u2014\u200athe server is blind throughoutAccess revocation enforced at ACL\u00a0level<\/strong>An attacker with full server + IPFS access gets mathematically nothing\u00a0useful<\/strong><\/p>\n

The cryptographic primitives RSA-OAEP and AES-GCM are available in every modern language and runtime. The pseudo-code in this guide maps directly to Python\u2019s cryptography library, Go’s crypto\/rsa and crypto\/cipher packages, Rust’s rsa and aes-gcm crates, and Java’s javax.crypto.<\/p>\n

The architecture is the idea. The language is just\u00a0syntax.<\/p>\n

Tagged: #cryptography #javascript #ipfs #security #zero-knowledge #encryption #fullstack #webdev<\/em><\/p>\n

Build a Zero-Knowledge Encrypted Document Vault: Complete Developer Guide<\/a> was originally published in Coinmonks<\/a> on Medium, where people are continuing the conversation by highlighting and responding to this story.<\/p>","protected":false},"excerpt":{"rendered":"

By the end of this guide, you\u2019ll have built a file-sharing system where you the developer running the server cannot read your users\u2019\u00a0files. \u23f1 Estimated read time: 20 minutes \u00b7 \ud83c\udff7 Tags: cryptography, javascript, ipfs, security, web-dev, zero-knowledge Introduction Most \u201csecure\u201d file apps encrypt data at rest on the server. That means the server holds […]<\/p>\n","protected":false},"author":0,"featured_media":177342,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-177341","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-interesting"],"_links":{"self":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/posts\/177341"}],"collection":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=177341"}],"version-history":[{"count":0,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/posts\/177341\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/media\/177342"}],"wp:attachment":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=177341"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=177341"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=177341"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}