SMF·PROTON-DRIVE-PLUS
Can a prompt replace Proton Drive Plus?
Cloud storage & backup — encrypted storage with a threat model
Exhibit tracking slip
Verdict
Encrypting files before upload is the easy part and mature open-source tools already do it well. The hard part, and the reason people pay, is everything around the key: recovering an account without a back door, changing a password without re-encrypting every file, sharing with someone who has no account, and audits that make the claim checkable. A personal build can encrypt; it usually cannot answer "what happens when I forget the password" with anything but "you lose everything".
Exhibit A — The prompt
Received on31.07.2026Build encrypted file storage and, before the code, write the threat model. The README opens with it.
The threat model must state plainly: who this protects against (a curious or breached server operator), who it does not (a hostile server serving modified client code, malware on your own machine, anyone with your passphrase), and what happens when the passphrase is lost.
Stack: a client — command-line and a browser page — plus a dumb storage server. The server stores ciphertext and metadata and can decrypt nothing. Consider standing on an existing audited encryption tool rather than writing the primitives.
Key hierarchy, which is the design decision everything else follows from:
- A random 256-bit **master key** encrypts per-file keys.
- The master key is wrapped by a key derived from your passphrase with Argon2id at parameters you document.
- Changing the passphrase re-wraps the master key only. Files are never touched. Demonstrate this in a test: change the passphrase, prove every file still decrypts, prove no ciphertext byte changed.
- Each file gets its own random key, wrapped by the master key. Sharing a single file means sharing that file's key, not the master.
Recovery, and be honest about it: generate a recovery code at setup that wraps the master key a second way, displayed once, with a forced confirmation that the user has stored it. State in the interface, not just the docs, that losing both the passphrase and the recovery code means the files are unrecoverable — because that is the actual property, and hiding it is how people lose their data.
Sharing: a share produces a link with the file key in the URL fragment, so the server still learns nothing. Expiry and download limits enforced server-side on the ciphertext.
Metadata: encrypt filenames and folder structure too, and say clearly what necessarily leaks anyway — file sizes, upload times, the shape of the folder tree, and access patterns.
Integrity: authenticated encryption throughout, and a verification command that checks every stored file's tag and reports corruption, since silent bit rot in ciphertext is unrecoverable.
Write tests for passphrase change not re-encrypting files, for recovery-code unwrapping, for tampered ciphertext being rejected rather than producing garbage, and for the verification command detecting a flipped bit.
Do not invent primitives, and do not add a password-reset path — it would be a back door by definition.Opening prefills the prompt — press enter to run it.
Exhibit B — What you lose
- B.1 a recovery story that works for a non-technical person
- B.2 the mobile and desktop clients with transparent encryption
- B.3 independent audits of the implementation
- B.4 sharing with recipients who do not have an account
- B.5 a jurisdiction and a legal posture chosen deliberately
Prior art
Exhibit C — Why people still pay: key management and recovery
Because encryption is a promise, and a promise is worth what the audits, the recovery process and the jurisdiction behind it are worth. Those are institutional, not technical.
Questions
Why does the key hierarchy matter so much?
Because without it, changing your passphrase means downloading, decrypting and re-uploading everything — which nobody does, so nobody changes their passphrase. Wrapping one master key makes a rotation instant and makes per-file sharing possible.
Why refuse a password reset?
Because a reset that recovers your files means the server can decrypt them, which contradicts the entire premise. The recovery code is the honest version: a second key you hold, not a back door somebody else holds.
What still leaks even with everything encrypted?
File sizes, the number of files, the shape of the folder tree, upload and access times, and your IP address. That metadata is often enough to infer a great deal, and any tool claiming otherwise is overselling.
Is Proton Drive audited?
Proton publishes independent security audits of its applications, which is a large part of what distinguishes a paid encrypted service from a homemade one. Your own build has whatever assurance you can give it, which is honestly not much.
Related tools
Receipt