Replying to Avatar waxwing

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.
Avatar
ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

yes it does

yes it is

highlighted for your convenience

Reply to this note

Please Login to reply.

Discussion

Avatar
ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

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

Avatar
waxwing 1y ago

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.

Avatar
ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

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