about half of the nip-44 tests in https://github.com/nbd-wtf/go-nostr have secret keys in the test vectors
i'm just commenting them out because they are wrong
they return the error, as they should, that the secret key has a 3 pubkey and that's that, end of fucking story
it is not valid test vectors
ya all the hardcoded keys, was like, uhh.. okay
it is so horrible, i have literally spent 8 hours cleaning this shit up because it's so goddamned complicated and back and forwards and hard coded and bullshit
i'm commenting out all of the wrong test vectors in my version of it and shifting the actual common functionality to the central implementation i have built for doing signing, verification and ECDH in one place to eliminate this kind of bullshit error
Doesn't nostr use BIP340 keys? A private key that has a public key with odd parity is not invalid; you just use the corresponding even parity point in encoding. It's effectively using -x * G for specific algorithms (see the "Default Signing" algorithm in bip340), but it's not that x is an invalid private key.
Honestly the x-only encoding was a bad choice, it has led to a lot of confusion and complexity.
yes it does
yes it is
highlighted for your convenience
please, all of you go check your BIP-340 library that its key generator isn't allowing 3 keys
this fucks up DM encryption, guys
Quotes: "The secret key sk: a 32-byte array, freshly generated uniformly at random" and as I already pointed to you, in "Default Signing":
Let d' = int(sk)
Fail if d' = 0 or d' ≥ n
Let P = d'⋅G
Let d = d' if has_even_y(P), otherwise let d = n - d' .
The secret key is still sk as defined above; d is *not* the secret key. It is a step in the signing algorithm.
it's not about the secret key, it's about the Y coordinate of the public key
because of the symmetry of the curve you can omit everything except the sign, which is represented in a compressed 33 byte serialization as a 2 or a 3
BIP-340 clearly states that it must generate an even Y key (i guess that's "positive" also)
and the reason why is because ECDH, not because Schnorr signatures, which don't need this bit
there probably is a way to construct an ECDH that doesn't need that bit but if you dig around the bitcoin-core/secp256k1 library you willi see that it calls a `keypair` a 96 byte blob of data and that is constructed out of 32 byte secret and 64 bytes of public key
the full public key, that is used in signature calculations and verifications , is 64 bytes long, but for schorr signatures you don't need that second half at all, the X is all that matters, and that is also partly why the signature itself is 64 bytes long (it omits a division operation which is where the oddness becomes an issue)
i don't think this causes a problem for the protocol at all, but people need to be alert to the importance of giving the user the secret that gives a 2 in a compressed serialization, or they will have problems with ECDH
the pubkey is the same and teh signatures validate, just not the encryption, and yes this can be fixed
it's a bug if your key generator doesn't do this, and signers should be checking for this and flagging it and providing the inversion to users so they never have ECDH problems
you can fix it in two ways:
1. reroll and derive the pubkey when creating a new secret key if it gets a 3 prefix compressed 33 byte pubkey
2. subtract the curve order G from the secret key to get the inverse which has the opposite sign and a 2 prefix
this cannot be fixed by users or by clients, it breaks either one direction or both directions
one user has 3 key, their messages can't be decrypted
both users have 3 keys neither user can decrypt each others messages
Yes you can do those things but you are not fixing an error. It is not an error to use a private key x fir which the corresponding pubkey xG has odd parity.
