the question is this:

ECDH is done using a 257 bit (33 byte) pubkey, to derive a secret

if you just stick a 02 in front, then you are wrong 50% of the time when the actual pubkey is 03

i kinda mistakenly believed that BIP-340 solved this problem by just making all keys even but it seems i am wrong about that

gonna keep researching this, but the problem i'm having writing a test for ECDH is that the 32 byte key is missing the sign/oddness bit and thus deriving the correct decryption secret is a coinflip

Reply to this note

Please Login to reply.

Discussion

That's not an issue I have run into with the vector tests. Maybe i need to do more research on this, I though only the positive (0x02) value was valid for nostr according to nip01. Happy to be wrong right now though.

yeah, that's what i thought!

so i've b0rked something here

no, i seriously had this understanding until today and then encounter ECDH not working correctly, i must be doing something wrong with a pubkey somewhere

If I'm not mistaken this is the basis for the twist vulnerability.