PsiDriveThe browser asks the operating system's cryptographic random source for a fresh 256-bit AES key.
How a browser encrypts a file before upload.
Modern browsers include the Web Crypto API, which lets a web application generate a random key and encrypt bytes locally. The server can then store and deliver ciphertext without receiving the transfer key as ordinary application data.
Four parts of a browser-encrypted transfer.
AES-GCM encrypts the data and adds an authentication tag so tampering is detected during decryption.
Only the encrypted filename, encrypted chunks, and delivery metadata need to reach storage.
Why files are split into chunks.
Chunking lets the browser process a large file incrementally instead of holding the full encrypted result in memory. Each PsiDrive chunk uses a unique initialization vector and authenticated context that binds it to the file and part number. A changed or misplaced chunk fails verification instead of silently producing altered output.
Chunking also allows direct uploads through short-lived signed URLs and makes interrupted uploads easier to resume without restarting the entire file.
What the recipient does.
The recipient's browser reads the key from the complete link, requests authorized encrypted chunks, verifies and decrypts each chunk, and writes the recovered bytes to a safe browser-supported destination. The backend supplies ciphertext and metadata; the browser performs recovery.
This design does not protect a file after it has been opened on a compromised device, and it cannot prevent a recipient from copying a file they are legitimately able to decrypt.
Questions to ask any encrypted transfer service.
Local generation avoids sending a newly created transfer key to the service as ordinary request data.
Key separation matters only if the backend does not store the key beside the encrypted object.
Authenticated encryption should reject modified ciphertext rather than return corrupted plaintext.