1
$\begingroup$

Assume that I operate a user-facing online file syncing service that offers end-to-end encryption of large files, such that files are encrypted client-side first, then uploaded to the server for storage. Assume that at present, files are encrypted with AES-CBC.

My question is, how is a such a service to safely facilitate long-term saving of data if longevity implies that files may need to be re-encrypted with newer algorithms in the future? That is, if a user has built up a collection of 10,000 files at 1GB a file over the last 10 years, and this service now needs to upgrade files to AES-GCM, how is it to do so? Manually downloading, decrypting CBC, re-encrypting with GCM, then uploading to server could take the client months to complete.

Proxy re-encryption seems a related topic, but having looked into that, it seems mostly related to the re-encryption of ciphertexts having been encrypted with RSA/asymmetric encryption, rather than symmetric encryption. Otherwise, if we can offload AES (or any arbitrary algorithm) re-encryption to a proxy server, that would be great, but doesn't seem to be the case with this type of encryption.

Is there a cryptographic solution to this, or is this more of a practical problem that must be solved through the only way possible—coordinating efficient, multi-day communication of client and server to ensure a safe upgrade process?

To be clear, I don't mean this in an enterprise capacity, but as a practical user-facing tool like Dropbox. If I'm storing many terabytes of encrypted data for millions of users, how do I facilitate encryption upgrades?

Improve this question
$\endgroup$
7
  • 1
    $\begingroup$ Sent with UPS? AWS Snowmobile does that for customers. Anyway, one can design a FHE solution to this but this will be way slower. 1GB file can be downloed in minutes. Decryption can be done very fastly, AES-NI, etc... $\endgroup$
    – kelalaka
    Dec 21, 2019 at 20:31
  • 3
    $\begingroup$ Generally such use cases are simply overlooked, to be honest :) $\endgroup$
    – Maarten Bodewes ♦
    Dec 22, 2019 at 2:47
  • $\begingroup$ @Maarten-reinstateMonica wait, what do you mean? And sorry, I should have clarified: I don't mean this in an enterprise capacity (where AWS Snowmobile would make sense), but as a practical user-facing tool like Dropbox. If I'm storing many terabytes of encrypted data for millions of users, how do I facilitate encryption upgrades, is the question. $\endgroup$
    – Snowman
    Dec 22, 2019 at 18:18
  • $\begingroup$ I mean that for existing services that allow client side encryption may not have an upgrade path. To be honest, if you secure using AES-256 and a secure mode you may not need to upgrade for the foreseeable future. Of course, you can always more easily upgrade the encryption of any keys used to wrap or generate the data keys themselves, if that's required. $\endgroup$
    – Maarten Bodewes ♦
    Dec 22, 2019 at 20:54
  • $\begingroup$ Upgrading encryption of keys is definitely easier, but you'd still have the actual payloads encrypted with an outdated algorithm or scheme. And this question pertains to developer error as well: suppose the developer made a mistake with the encryption of items, and all data now needs to be re-encrypted. Seems like that should be a not uncommon occurrence. $\endgroup$
    – Snowman
    Dec 22, 2019 at 21:21

0

Reset to default

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Browse other questions tagged or ask your own question.