Nostr Web Client

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

GHOST 0mo ago 💬 1

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.

Reply to this note

Please Login to reply.

Discussion

Viktor 0mo ago

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.

Max 0mo ago 💬 2

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.

Max 0mo ago 💬 1

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.

Viktor 0mo ago

ah cool, so basically a *memory-only* safety deposit box. one key to rule them all, burn the key → burn the vault.

strikes me as the opposite of forward secrecy—call it "perfect historical access" instead.

trade-offs seem sane:

- memorize 64 chars === brainwallet for fast restore

- key reuse across files → deduplication & deterministic paths

- you can literally "delete never existed" by nuking the single secret

but:

- single point of fail = single point of death if someone shoulder-surfs or torture-memorizes it

- no rotation/recovery ever = no room for key rotation culture over decades

imo leave both vectors open: default flow is "fresh nsec" yet still let power users toss their main in if they want. usability wins both.

Max 0mo ago

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.

GHOST 0mo ago 💬 1

Have you considered allowing an optional passphrase that mixes into the HKDF for the master storage key?

That way the design stays deterministic and recoverable with one memorized secret, but the blast radius of a leaked nsec becomes much smaller. The user doesn’t need FS, but they also don’t need their raw nsec to unlock all stored data.

This keeps the one key philosophy intact and just makes compromise require two factors instead of one.

Viktor 0mo ago 💬 1

clever middle ground — single remembered factor could yield the same seed, optional passphrase becomes the second salt that never touches disk. adds maybe 20 chars to the seed phrase if users want it, zero complexity otherwise.

r4f4 0mo ago

So, it can be generate a rotate key from the nsec + a passphrase, right?

Another point that supports the proposal of nostr:npub18dlusgmprudw46nracaldxe9hz4pdmrws8g6lsusy6qglcv5x48s0lh8x3 is that in PGP you can use a more robust algorithm that secp256k1 (Curve25519)

Max 0mo ago 💬 1

Yes, the earlier designs had a password as well, it should be trivial to add here too as an option.

GHOST 0mo ago 💬 1

Perfect. Optional password fits the model without altering the recovery guarantees.

Viktor 0mo ago

yup, optional pass is the sweet spot,still “everything in one brain cell” if you want it, two factors if you’re paranoid.