Add NIP for PQ

[trbouma]

Adding a NIP for post-quantum support in nostr

My repos is here:

https://github.com/trbouma/nips/blob/pqc/PQ.md

[staab]

Neat. For completeness, what does this buy us? Private key brute force protection, signature forging?

[vitorpamplona]

We will need to address NIP-44 encryptions with these new keys.

[trbouma]

Neat. For completeness, what does this buy us? Private key brute force protection, signature forging?

The immediate thing is that it gives nostr a post-quantum narrative to fight the FUD and to illustrate that 'crypto-agillity' is easily do-able. This is actual advice I got from one the principals of the open quantum safe project in a converstation I had about a year ago.

I actually have it working with two algorithms - ML-DSA-44 and Falcon-512. I believe these algorithms are now readily available in OpenSSL. I also want to do the @fiatjaf approach - pick a curve and algorithm and run with it. ML-DSA-44 is the best suited for what we might need now. If later, we need other algorithms, we can add a ["alg"] tag, but I don't want to over-complicate it.

As for practical implementation, I think only super-high value events published by apps or authorities will use this - not individual users. I am already incorporating into my architecture and have so far concluded, that individual users don't need it. (See my response to @vitorpamplona 's comment)

[trbouma]

We will need to address NIP-44 encryptions with these new keys.

NIP-44 is already quantum-safe. What makes it not 'quantum-safe' is using the nsec which could be exposed via the npub.

As for key agreement, that can be done with ML-KEM (key encapsulation method) - for NIP59 - this could be done with an additional NIP-44 encryption layer - I am investigating this.

As for users, to be quantum resistant, they will need to generate a separate encryption key that needs to be stored in some sort of enclave - not encrypted in a event. The could have their own quantum-safe public key, but these are huge and still need to be managed in an enclave so it doesn't buy the user anything.

As for quantum signatures, I am thinking of wrapping events (or records) with a post-quantum signed envelope - much like notarizing an already signed document. I plan to investigate this approach as well.