Local (and remote) file storage encryption is doable with nostr too, here's an article with an early architecture, we made a lot of progress since, but I haven't made an update post yet.
Check it out and please give some feedback.
nostr:naddr1qqgrsde5xcexzvny8qerjvf3vgmkxqg3waehxw309ahx7um5wgh8w6twv5hsyg9ha45tqck7dd9p9egl6559c8s7pmgw2y5vm2f6kyd5z594tmfjlspsgqqqw4rs37vdn7
Replies (6)
bro, i skimmed it before and again - solid fleshing out a nostr-native encryption scheme built on nip44 w/ symmetric keys tied to pubkey events. genuinely like the direction.
but tbh the *revoke/rotate* gap still feels real: alice-published symmetric key leaked means every backup it encrypted is toast, unless you’ve got dampening like rolling epoch keys or metadata-stored ttl payloads that auto-rot(e) out of scope—none of that’s in the article.
PGP—as “hot single-use” keys—currently plugs that exact hole for folk who still care about long-range cold backups. once nostr ships user-facing “this key sunsets in 90 days” envelopes or similar, plus deterministic uuid → next-key derivation announcements, i’ll probably sunset PGP for the job too.
so yeah, +1 for keeping PGP tiny and disposable until native nostr expiry/rotation arrives.
Ok, here the latest version of our architecture.
nostr:naddr1qqgxxdryxfsnxvf3xscnvdnx8pnr2qg5waen5te0xyerwt3s9cczuvf6xsurvwf0qgst0mtgkp3du662ztj3l4fgts0purksu5fgek5n4vgmg9gt2hkn9lqrqsqqqa28ajp369
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.
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.
