Oddbean new post about login | logout 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 🌋🌊
I think it's time to hopefully ask @fiatjaf and maybe @JeffG 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 @@Magister Michael Dilger M.Sc. @Vitor Pamplona
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