@dlaumen - following up on the crypto-refresh guidance earlier in this thread. We shipped it in rclone v1.75.0 and hit an interop problem I'd like your guidance on.
We implemented (per your post #16) file node keys generated with the v6/AEAD profile; content key = v6 session key in a v6 PKESK to the node key; blocks SEIPDv2 AES-256-GCM; name/passphrase/xattr kept non-AEAD.
The server accepts the uploads, rclone round-trips them fine, and the Android app reads them fine - but the web app fails with "Item cannot be decrypted" for any file whose node key is v6, flagged at listing time before any download, and regardless of the format of everything else (we tried with all auxiliary fields, including block signatures, pinned to v3 PKESK + SEIPDv1). First user report: [Proton Drive] - Unable to Decrypt
We uploaded a file with the current web app and dumped its packets via the API:
| field | format |
|---|---|
| node key | v4 |
| node passphrase | v3 PKESK + SEIPDv1 |
| xattr | v3 PKESK + SEIPDv1 |
| content key packet | v6 PKESK (to the v4 node key) |
| block signature | v6 PKESK + SEIPDv2 (GCM) |
So the web app writes crypto-refresh content on a v4 node key, and apparently does not support v6 node keys on the read side at all. Also worth noting: in June the server rejected a v6 content key packet on a v4 node key ("Could not verify the nodeKey was used for encrypting contentKeyPacket") - which is what pushed us to v6 node keys - but that validation has evidently been relaxed since, as the web app now produces exactly that combination.
What rclone does now (what will become v1.75.1, currently on a test branch): new files are created fully legacy-format again (v4 node key, v3 PKESK content key, SEIPDv1 blocks) as the only format all clients read today. We still read the new format, revisions of files that already have a v6 content key keep SEIPDv2 blocks, and the auxiliary fields are pinned non-AEAD regardless of key preferences per your guidance.
Questions
- Should third-party clients put the v6/AEAD profile on file node keys at all? Is web support for v6 node keys coming, or should node keys stay v4 indefinitely with crypto-refresh applied to the content only, as the web app does?
- Is the target format for new files what the web app currently writes - v4 node key + v6 PKESK content key + SEIPDv2/GCM blocks? Should the encrypted block signature be AEAD (as web does) or non-AEAD?
- Is there, or will there be, a signal (feature flag, capabilities endpoint) third-party clients can use to know when it is safe to default to writing crypto-refresh - and how long will legacy-format writes remain accepted?
- For the files already created with v6 node keys by rclone v1.75.0 (~2.5 weeks of uploads): is delete + re-upload the only repair, or might the web app gain v6 node key support / is a server-side migration possible? The Android app reads them fine, so users may prefer not to recreate them.
We're planning to add an opt-in flag to rclone for writing the new format (matching whatever you confirm is the target), so we can track the migration without breaking the web app again.
Thank you very much for helping