PsiDriveThe browser generates a 256-bit AES key for the transfer using the Web Crypto API.
Encryption begins before your upload does.
PsiDrive's browser creates a fresh AES-256-GCM key, encrypts the filename and every file chunk, and sends only ciphertext to Cloudflare storage.
AES-256-GCMAuthenticated chunksBrowser decryptionTemporary storage
A transfer architecture with clear boundaries.
The file service needs metadata to deliver and expire a transfer, but it does not need the transfer key. That separation reduces what the backend alone can learn from stored file objects.
GCM detects tampering during decryption. Each chunk is bound to its file and part number as additional authenticated data.
The recipient's browser reads the key from the link fragment, downloads encrypted parts, and decrypts locally.
From sender to recipient.
The sender's browser creates the transfer key and encrypted filename.
Encrypted parts are uploaded to a private R2 bucket through short-lived signed URLs.
The recipient downloads and verifies each encrypted part before saving the recovered file.
Encryption FAQ
What encryption does PsiDrive use?
The current format uses AES-256-GCM with a fresh key, a unique random IV for each encrypted value, and authenticated context for file parts.
Can the backend decrypt without the link fragment?
The backend does not store the transfer key. Decryption requires the complete fragment-bearing link in the recipient's browser. Read why in the URL fragment key guide.
Does encryption replace safe sharing?
No. Anyone who receives the complete link may be able to download while it remains active. Protect the link and use the optional password when appropriate.