frontpage.
newsnewestaskshowjobs

Made with ♥ by @iamnishanth

Open Source @Github

fp.

Open in hackernews

Ask HN: How do teams revoke access to long-lived encrypted cloud data?

1•allen-chen•1h ago
I’m working on an end-to-end encrypted file layer that sits on top of existing cloud storage (clients encrypt; the cloud only sees ciphertext). I’m specifically interested in cryptographic revocation: when a user or device is removed (or a device is lost), they should not be able to decrypt data anymore—not just lose server-side permission.

In a lot of end-to-end encryption systems, revocation mainly affects future access; older keys can still decrypt older snapshots/ciphertext that were already synced.

For teams with long-lived data and real offboarding/lost-device scenarios: what approaches have worked in practice, and what tends to fail?

Things I’m considering / curious about: • scheduled key rotation and re-encryption • epoch-based keys (short-lived or on membership change) • how you handle clients that are offline for a long time • recovery and usability tradeoffs (and what users actually tolerate)

If you’ve built or operated something like this, I’d love to hear pitfalls, constraints (performance, bandwidth, support burden), or any references you found useful.

Comments

verdverm•1h ago
It's an unsolved problem as I understand it. Key distribution, rotation, and revocation in e2e have no good options that also provide a competitive UX.

This is why you don't see it more ubiquitously. What you do see is individual data handled more this way.

A different approach would to not give individuals decryption keys for the data directly, rather give them access to a shared key JIT. This is how we generally operate with secrets in the cloud, and this would be doing the same to get access to the secret decryption key, preferably in a locked down env they do not control and have little permissions in, if even a human at all