Thread

lmao ok that title already screams “fight me” - skimmed the bit about PGP identity chaining being the *only* real ownership model and ngl half my TL is gonna rage 😂 PGP purists vs Nostr key rotators vs the “we all use browser-extension-jank-wallet” crowd = perfect civil war fuel 🔥

I don't get it... Why do you still need PGP at all? nostr:nprofile1qqs83nn04fezvsu89p8xg7axjwye2u67errat3dx2um725fs7qnrqlgpzamhxue69uhhxetpwf3kstnwdaejuar0v3shjtc3uszjr does software signing better anyhow. And what's the difference of using nostr as your long term identity key and not just a PGP master key? At least the PGP master key you can revoke, expire, rotate, while we don't have any of that in nostr yet.

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.

What value to me is the PGP key?

yo, pgp keys are like *the* atomic badge of digital self-sovereignty. they let you: - prove *you* said a thing, forever - prove *only the intended person* read it - revoke or rotate without asking anyone’s permission basically turns your nostr pubkey from “-probably- that guy” into “cryptographically-verified, tamper-proof identity.” bypasses every centralized platform, every web-of-trust clique, every kyc bot. if someone truly cares about owning their digital shadow, pgp is the bullion bar—everything else is just a receipt.

real talk: 1. pin the pubkey to your nostr profile. go to settings >> pgp pubkey, paste ascii-armored blob. then every skeptical dm’er can check “did this dude actually say this?” — done. 2. set your e-mail client (thunderbird, kmail, apple mail with gpg tools) to auto-sign outbound. zero cognitive load + everyone suddenly gets used to seeing “✅ signed” on your mails. 3. create .asc “business card” on keyoxide.org → one qr code people can scan that resolves to both your nostr npub AND pgp fingerprint. slap it on business cards, stickers, even t-shirt. 4. treat the key like a trezor seed: one backup on steel, one in password manager (encrypted), one offline usb. lose it once you’ll *feel* why it matters. bonus: tell people “dm me over nip-17 (giftwraps) and verify with my pgp sig, vector handles both for free.” own the key once, the rest compounds.

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

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.

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.

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.

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.

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.

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)

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.

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

Rather than pissed, I'm happy to see a relevant proposal. Now waiting to address the elephant in the room which are rotational nostr key pairs using a master nostr key. Good write-up. At which time of the year should the key be rotated? Does it need exactness in the sense of being in the same day next year? Sorry if this misses the point but I'm looking at this from an implementation perspective. If usable, will implement on geogram for signing emails effortlessly.

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.

clean compromise. yearly epoch feels human-scale, no calendar nitpicks needed. popping a toast that goes “yo, tomorrow’s new-key day,tap to migrate, or ride the old one another year” should be enough. if geogram ends up shipping it, hmu,would love to see folks signing e-mails with a Nostr Master Key Pair because *Privacy by Principle* should also hit SMTP.

Suspect whilst you are more along this path, am sharing similar concerns. Good article.

fire piece, tho gonna piss off the purists who think PGP still belongs on diskette next to their fax machine lol feds *hate* this energy. gm

THIS IS AWESOME!! The important thing here is the idea of how to use cryptographic systems in a coordinated way. This opens the door to much more cypherpunk creativity. The crucial point of the design is the strategic coordination of cryptographic systems to solve identity and ownership problems that a single protocol (such as traditional PGP) could not handle alone. Congrats!

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

This is great. Wondering if the current year PGP key needs to or should also first sign the next year's key, authenticating a chain? Maybe I'm missing something about the rotation process.

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

Will save this conversation and then ping here when is time to test it. Don't think anyone here has implemented yet a nostr master key system as reference to learn from them, so will see how an implementation can look like. At least a nostr key rotating a PGP key seems fairly straightforward.

You can build a signing chain, but it collapses the separation. If the nsec signs each new PGP key, the Nostr key becomes a permanent root authority and a single compromise breaks the entire lifecycle. The whole point of coordinating two systems is to avoid that failure mode. With deterministic epochs, clients can verify rotation without deputizing nsec as a god key. Once you have a stable root, rotation is just schedule + client support. Everything else is implementation detail.

yea dead on,don’t want that “god key” trap. keep the nsec as blind entropy source, let deterministic schedule + clients handle the rest. when you’ve got a proto ready i’ll eagerly whack it with Vector (DM me over NIP-17 if ya like) to see how it feels.

As someone who is into pgp and more recently into nostr, looks interesting I will give it a close look at 👀 thank you!

Could this be a solution for delta.chat? There the identity (mail account) is still tied to the server..

cool idea but aren't nostr keys hot and hard to safeguard when used daily? i'd love to take this a step further and have a master-nostr-key that stays offline and that can create derivative "hot" keys with automatic follower within the key-family-tree.

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.

I wrote this as a starting point, no thanks to nostr:npub1aljazgxlpnpfp7n5sunlk3dvfp72456x6nezjw4sd850q879rxqsthg9jp '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. https://github.com/bitkarrot/higher

Cool!