How S3ND Implements True End-to-End Encryption (E2EE)

Here's a high-level, step-by-step walkthrough of how S3ND implements true end-to-end encryption (E2EE) in the browser so that the server (and anyone observing it) never sees your unencrypted data or your secret key:

🖱️ User chooses a file in the browser

• You click "Upload a file…" in the S3ND UI.
• The browser obtains a File/Blob object but does not send it yet.

🔑 Client generates a fresh symmetric key

• S3ND uses the Web Crypto API to create:
  • A random 32-byte master key (for AES-256)
  • A random 16-byte salt for key derivation
  • A random 12-byte IV (initialization vector) for AES-GCM
• None of these secret values ever leave the browser in plaintext.

🔧 Key derivation (HKDF/PBKDF2)

• S3ND runs a Key Derivation Function on the master key + salt to produce the AES-GCM key.
• The salt is stored alongside the ciphertext so anyone with the salt + link fragment can re-derive the same key.

🔒 File encryption in the browser

• The browser reads the file (chunk by chunk for large files).
• Each chunk is encrypted with AES-256-GCM, yielding ciphertext + authentication tag.
• This ensures both confidentiality and tamper-detection.

☁️ Upload of encrypted bundle + metadata

• The browser packages:
  • Ciphertext chunks
  • IV
  • Salt
  • (Optional) filename, size, MIME type
• The encrypted bundle is POSTed over HTTPS to S3ND's backend or an S3 presigned URL.
• The server never sees plaintext or your master key.

🔗 Link creation

• After upload, the server returns a short ID (for example https://s3nd.com/XYZ789).
• The browser appends the decryption material to the URL fragment (after "#"):
  e.g. https://s3nd.com/XYZ789#salt=…&iv=…&key=…
• URL fragments stay in-browser and are never sent to servers.

🌐 Recipient fetches the link

• When the link is opened, the browser requests /XYZ789 and downloads the encrypted bundle.
• The fragment (salt, iv, key) remains local, accessible only to client-side JavaScript.

🛠️ Key re-derivation + decryption

• The browser re-derives the AES-GCM key from the fragment's salt and key material.
• AES-GCM decrypts the ciphertext. If the authentication tags validate, you have the original file.

💾 File delivery in the browser

• The decrypted Blob is converted to an object URL or fed into a <a download> link.
• The user is prompted with a "Save as…" dialog showing the original filename.

Why it's true E2EE:

• All encryption/decryption happens client-side.
• The server only ever handles ciphertext, IV, salt, and metadata.
• The secret key lives in the URL fragment, never transmitted over the network.
• Even a fully compromised server or HTTPS channel cannot reveal your plaintext without the fragment.
• Optionally, S3ND can auto-expire or delete the ciphertext after delivery, leaving no residual data.