Oddbean new post about login | logout secret A + pubkey B = secret B + pubkey A this is the entire premise of Diffie Hellman Key Exchange if that equation doesn't hold, then one side has something wrong with it, and is not as labeled
Yeah but I mean in the wild where you don't have secret B.
you get a different secret, and the equation is false
But there is no way of knowing if the shared secret is invalid unless you can have both sides of the equation, which we can't have.
It would be nice to have "3" keys in your kind=0 profile. I have wanted that for years. But years later we still dont have it. And I dont think we will have it in future. It would have been nicer if pubkeys were 33 bytes in the first place. At this point I dont want anything to change, becasue the chance of breaking a working system is too high.
adding a flag to the kind 0 profile metadata is the only practical solution, as well as a strong stipulation about it both in the nip-01 and the - one that describes the kind 0 event it has to be addressed, and once it's obvious to any implementer and all implementations used in the majority of cases are compliant the problem will disappear and nobody will have to actually put the optional flag in the kind 0 i have had problems with DMs myself, and this is a big obstacle for use of nostr DMs as a control mechanism as a way to communicate with customers especially, just ask nostr:nprofile1qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qgwwaehxw309ahx7uewd3hkctcpz9mhxue69uhkummnw3ezuamfdejj7qg6waehxw309ahx7um5wgh8g6r9wdsk6etrv96zu6t09uq3kamnwvaz7tm5dpjkvmmjv4ehgtnwdaehgu339e3k7mf0qyf8wumn8ghj7mn0wd68yv339e3k7mf0qythwumn8ghj7un9d3shjtnwdaehgu3wvfskuep0qqs8eseg5zxak2hal8umuaa7laxgxjyll9uhyxp86c522shn9gj8crsy7rryg the thing i'm saying is that i believe this problem has silently retarded nostr adoption
if you are able to extend kind=0 ill be impressed and happy, but im not going anywhere near it, because the chance of breaking the whole protocol is too high. not alot of people have complained on this issue, so we can just use work arounds I think.
well, at least make a loud pronouncement about not making odd npubs lol
I think this might be an acceptable solution. I suppose it cuts the key-space in half though?
that was implicit and is mentioned in BIP-340 just keep in mind that as it was, the bit-strength of secp256k1 is about 126 effective bits, and this only shaves off half a bit the permutations of those bits is an extra factor of two for every bit so it's not a linear relation, losing one bit is really losing 1/126th of the security the chances of collision are doubled and the time to average brute force is half, yes, but we are talking about a process that would take hundreds of years for one key with all the computers in the world
no, i think that's a bad idea. its doubling down on a bad design choice. lots of things will and should produce odd npubs, like hardware wallets etc. and there already are many users with '3', its not fair to invalidate, deprecate or cancel those accounts. just let 2s be 2s and 3s be 3s. and find work arounds such as kind=0. in any case im not touching it, because the protocol might get even more broken by well-intended efforts to fix a bad original choice. and we cant cancel half the user base, the system is already running... use workarounds!
i understand your point but the change i propose only affects two points of the system, where your proposal means a whole shitload of code has to be rewritten to accept 64 or 66 character pubkeys in the event, this is a larger compliance burden
To be clear. I propose no change. The protocol is working. I propose dont change it, and dont touch it. Find a NIP work around for one of the other NIPs that's fine. Let 2s be 2s and 3s be 3s, because we already have a user base of 2s and 3s and cant change that now. Extending profiles is a good way. I actually think profiles should be extensible by design, in a permissionless way.
you are saying allow 66 character pubkey fields tho, or what?
No. Let me be very clear now. Dont change the protocol. Let 3s exist on the network. Dont touch it, dont break what we have. I have no proposal. Whatever workaround you want, is find by me. Just dont change the protocol. Im specifically not getting involved, because I dont want the protocol to change. I'll just cross my fingers on that, tho!
ah, yes, so you are gonna do the same as what the rest of them do because of the survivorship bias of not seeing the users who left for reasons of not being able to use DMs, helpful.
it is the fault of the NIP maintainers also, btw, because BIP-340 clearly states this but then again BIP-340 is horribly worded as well, it took me some time to figure a lot of it out... my fork of btcec has the extra 4 test vectors in the test suite that roasbeef refused to bother to complete, i even handed it to him on a platter
It's not that. There's tons of ways to do a DM already. They all work. Cant really invalidate user accounts on an existing system, that prides itself on users not being able to be cancelled. That would go against the marketing. Devs will just have to find another way, of which there are multiple, and they'll figure something out.
yeah, i've been thinking about it, because i have part way done the tooling to manage a paid relay service using DMs and for the customer side we need to be able to tolerate anything, so there's things that can be done one, the relay will never generate or use 3 keys, that's now fully fixed in my codebase two, the initial messages with a user will send out assuming both 2 and 3, and each one will have a different string that the user is asked to paste and return, and this will confirm, and if 3 keys are discovered they will be stored in the database - probably just make a public event with a note saying "this key is an odd key" so others can discover this after that i think that is enough measures other than simply pointing it out to the nip guardians that their protocol uses ecdh without strict odd prohibition (as you say, you can either roll again for a 2 or you can modulo subtract the curve order G from the key and voila - considering this avoids needing to derive the key again i might need to revisit this option
user A gets secret A and user B gets secret B and they can't communicate it's a 2x2 grid, two cases where A and B pubkeys are 3s you can't get the same shared secret most generators already either reject 3s or subtract the curve order from the secret to get the opposite sign, but even with this in mind you still have teh problem that you have to try a second one to test if it's just the wrong one and that only gives you 25% of cases where they are wrong, in the other direction, where you guess the pubkey prefix/sign, it works i have seen this in DMs before and it was infuriating, but i didn't test it enough, i'd generate a key, have problems, and without knowing what was going on, that key would be discarded and another one generated, and 50% of the time it would work and seem like the stars were out of alignment, but it's a bug in the protocol that needs to be strongly stipulated about the keys being ONLY 2 prefix, even pubkeys because of ECDH the ways around it are difficult, the only solution i see is signalling optionally in kind 0 if you have an odd pubkey that solves the problem if two people have 3 keys and their software guesses 2s both sides can't communicate, otherwise, you have a case where one way works the other doesn't
I guess what I'm trying to say is, from a libraries' perspective, there is no way (unless the caller tells me) for me to know what the proper sign is. It will just happily decrypt garbage and return it to the user. I can't know if the decrypted data is correct. In nip44 we can check the MAC, but for nip04 you just have to hope for the best??
all events have a MAC in fact, the presence of it in NIP-44 is redundant, that's what the event signature is it doesn't have to authenticate on the plaintext after you decrypt it, if you already certified the ciphertext this is another retarded element of nip-44
But I still can't know if the decrypted plaintext is correct. That's what I'm saying. The signature tells me nothing about the plaintext
yes, this is correct, you would have to have a sentinel to enable this, the first byte even it could be, or maybe better first 4 bytes to eliminate the chances of decrypting the same by both
also, yes, you don't need that bit for signature verification, that's one of the neat things about Schnorr signatures but it does not apply to ECDH