https://github.com/VnUgE/noscrypt/blob/51d0aff9166ddaa3c74dbc2d7c1dcbdefa8405e1/src/noscrypt.c#L127
Discussion
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
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.