Nostr Web Client

Can't you do some key encapsulation mechanism to include both keys?

No, any attempt would be theatre, there's no key ECC-to-lattice key derivation and that's the only thing that would allow events themselves to declare both identities in a way that can't just be "re-declared" post q-day.

If you keep nostr what it is (no blockchain time-stamping, etc.) then the only sensible option is for everyone to consider their current identity meaningless (consider their nsec "pre-stolen") and start with a new post-quantum key pair identity, from zero. So all web of trust gone, etc.

Reply to this note

Please Login to reply.

Discussion

JOE2o 3d ago

The route is something like this.

First all concerned agree on a PQC key type for nostr identity (not easy).

Then everyone creates a fresh identity, with that PQC key type.

That means everyone has accepted that there is no way to link their old identity events to their new identity events that will survive q-day.

To be clear, before q-day, yes, you can use your old identity to bootstrap your PQC identity. But this is raw bootstrapping, not some kind of hybrid posting that will survive q-day. After q-day everything from your old key, including attestations and wrappings regarding your new key, will become cryptographically meaningless text files, with anyone able to add to your old-key history as they like. So the strategy is to stop posting things of value with your old key right after the creation of your new key, and use the old key exclusively as a tool to bootstrap the new key (add trust).

Also post q-day all your NIP17 DMs that made their way to public relays, and other things like encrypted follow lists, will be open to all that have collected them to read.

Again, though, it’s not whether q-day will ever actually happen or not that matters, it’s the fact that the internet thinks it could well happen. Opinion as reality.