Nostr Web Client

That's not a migration pathway though, in the sense that many other things can have one.

Even if you add, let's say, fields for a falcon sig and pubkey, a quantum baddie can ignore the falcon sig and just forge a valid schnorr sig for your identity. To the legacy part of the network the forged event looks authentic. For a migration to actually protect you, every relay and client would have to disregard schnorr sigs altogeher. So siging schnorr over falcon (or whatever) is a pointless act. No matter what, you end up with a breaking change, no cross-fade.

Also there is no mathematical pathway to derive a lattice-based key from an elliptic-curve key. This means every user would have to generate a brand-new lattice key, post an event signed by the old schnorr key attesting that the new key is the rightful heir. And where does that attestation event go? And will all in the decentralised network know about it? And what about agreed time-stamping, etc. (All requires *some* centralisation.)

And after q-day the schnorr key is meaningless and the baddie can post that same event claiming one of their falcon keys is the rightful heir, maybe before you get round to it, if this all happens fast enough. Or maybe delete your attestation event and post theirs in its place, and so on.

Also any baddie from q-day onwards can insert anything into your history before q-day and it's indistinguishable from anything else in your history, at least at the atomic event level (which is what nostr is supposed to be).

Basically nostr as it stands cannot be advertised as the future. It doesn’t really matter how you assess the quantum threat, for the coming years with quantum-vulnerable cryptography you’ll be swimming against the current of internet opinion, and that's the real issue, not the true nature of the threat.

nout 3d ago

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

Reply to this note

Please Login to reply.

Discussion

JOE2o 3d ago

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.

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.