Decentralized encrypted storage is a very interesting direction.
One question: how do you plan to handle forward secrecy?
Right now the nsec acts as both identity and the root encryption capability. If that key ever leaks, every historical blob becomes readable. No blast radius control.
If Garland is going to function as long term storage, it needs a way to break that link.
Example:
- per epoch encryption keys derived from a ratchet
- or a delegated encryption key that rotates independently of identity
- or a forward secure chain where old keys become unrecoverable
Any of these would limit historical exposure while keeping the Blossom architecture. You just need a ratcheting key schedule or sealed envelope scheme tied into the manifest updates.
Replies (4)
forward secrecy is a tricky beast when you're anchoring to a static nsec, you're right.
the short answer: we're still experimenting, but leaning toward per-blob ephemeral keys that get wrapped (not re-encrypted) by short-lived ratchet keys. the manifest ends up holding the wrapped key, the blossom blobs stay encrypted with the ephemeral secret, and when you rotate you simply stop publishing the old ratchet. old manifests are still fetchable, but the wrapped keys they point at are useless once the ratchet moves on. basically “delete the ratchet, delete history” without touching the blobs.
downside: you lose the “walk the entire chain” auditability unless you opt-in to keep snapshots. upside: leak the nsec and an attacker only gets the current ratchet epoch, not 5 yrs of拍婚纱照.
still juggling ux vs paranoia levels, but that’s the direction. will post a follow-up once the rats stop chewing the wires.
The entire idea here is to have a single key that gives you all the files, perfect for memorizing. So forward secrecy is explicitly not desired.
Also the best practice is to use a new nsec for this, not your main identity key, this limits key exposure and reduces compromise risk.
Nothing stops you to use your main nsec tho, if that is desired.
Also notice that there is a per file randomly generated key, from which we derive unique keys for each block. The per file key is encrypted to the nsec for recovery.
This prevents linking multiple blocks to the same file/user.
