Thread

Zapstore is great for software signing. It solves the only reason you would need a long dated PGP key which was for software verifiability. But PGP still solves one narrow problem I don’t want to lose which is offline file level encryption with a trust model I fully control. That doesn’t require a decade long key. It just needs short lived, compartmentalized ones. Nostr’s missing piece is native expiry and rotation standards. We’ll get there. Until then my argument is simple. Keep PGP minimal and disposable for encryption. Treat Nostr as the long term identity layer because it avoids the overhead that made PGP brittle. Using both gives you the strengths of each and covers the weaknesses of both. And it lets you cross verify identity without dragging PGP’s legacy baggage into it.

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.

Ok, here the latest version of our architecture.

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.

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.

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

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

I wrote this as a starting point, no thanks to @aljaz 's idea: The Higher relay specializes in providing a Nostr relay with access to keys derived from a master key. Any keys which are not derived from the master key will be rejected for write events.

GitHub

GitHub - bitkarrot/higher: Higher: Nostr Relay for Hierarchical determinstic keys

Higher: Nostr Relay for Hierarchical determinstic keys - bitkarrot/higher

Cool!

Rotation doesn’t need exact dates. Just fixed epochs so clients can deterministically derive subkeys from a master key. Yearly is clean enough. At that point rotation is a UX decision more than a cryptographic one.

Most of the innovation won’t come from new protocols. It comes from combining the ones we already trust in smarter ways.

You can chain sign yearly keys, but it isn’t required. The rotation model works even without a continuity chain because the trust anchor isn’t the old key. It’s the signature from your Nostr identity that ties each yearly PGP key back to you. That keeps compromise blast radius small without forcing a long trust chain.

Replied in DM

They’re hot only because clients force them to be. There’s nothing in the protocol that says the nsec has to live on a daily use device. That’s just UX inertia. The protocol just says: A user has a keypair. Everything else is implementation detail. If Nostr ever adds native key hierarchies, you’d get exactly what you’re describing: offline root and deterministic hot keys. What I’d like to see is epoch rotation on top of that. Treat the nsec as an offline root that never touches a live client, and use it only to deterministically derive the ‘hot’ operational keys you actually use for a given epoch (year, quarter, whatever). Clients then follow the derived key, not the root, and can auto roll forward when a new epoch key appears in the same family. The root stays cold, the hot keys rotate on a schedule, and a compromise only burns that epoch instead of your entire identity history. A modernized key hierarchy model: Root nsec (offline, cold) -> deterministic derivation -> epoch subkeys (hot, operational) -> clients follow epochs -> rotation becomes normal, safe, automatic This is the same key lifecycle model used everywhere else encryption has matured.

this is maybe the best summary of where i assumed nostr key mgmt would already be at this point. also it would be 100% backwards compatible with not using derivative subkeys if users chose not to.