spoiler alert: it doesn't check
i just never encountered this before, because it looks like most generators check for a 2 key and either invert it or reject it
it's not specified in either nip-04 or bip-340 except obliquely and not explicitly
you can't get around it, claude is wrong, the ECDH computation makes two different keys depending on whether it's an odd or even Y
huh, but it has the pubkey, why wouldnt it be able to know its even or odd when computing shared secret? im missing something here..
it's not possible for the sender to know the extra bit, they pick the wrong one, the receiver at best could send back a reply "wrong bit"
damn 🌋🌊
dang
I think it's time to hopefully ask nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 and maybe nostr:npub1zuuajd7u3sx8xu92yav9jwxpr839cs0kc3q6t56vd5u9q033xmhsk6c2uc
Something seems really wrong. This is nothing that's come up in my tests before. Were all missing something?? This is a huge deal! I beleive this would be part of an EC twist vulnerability...
CC @nostr:npub1acg6thl5psv62405rljzkj8spesceyfz2c32udakc2ak0dmvfeyse9p35c nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z
i wasn't aware of what this exactly means, it's not a vulnerability, it's a bug that surely is killing nostr adoption because everyon expects DMs to work, but they obviously can't work without that extra bit
if my dm partners are mostly different sign keys to me, we can't use it
BIP-340 specifies choosing the 02. Look at the section "Implicit Y coordinates"
so using code that doesn't check for it is wrong
go read some source code of nostr libraries again with regard to key generation
i'm not gonna pretend i checked the javascript or rust libraries, as i hate both of these languages but the Go libraries DO NOT CHECK
just write a short piece of code generating new keys and then use two of them to make an ECDH key both ways
then you'll know if the library is doing it right
