Oddbean

i'm not sure you understand the function of encryption nonces, they ensure that for every message the secret is effectively a new one... there is zero chance of a plaintext attack in this, so long as the quality of the entropy of the nonce is adequate i agree that there should be padding but i don't think it should be the stupid "pad out to next power of 2" of nip-44 is retarded it should just be a random amount extra and you just put a zero byte at the end of the actual string and fill the rest with garbage... i've written what i think is an adequate message length obfuscation method on indra so, yeah, no, there is zero risk of a plaintext attack even if people keep saying "hi" over and over again in their messages the nip-44 scheme is seriously wasteful of data size with its power of two scheme, and doesn't really help anything, and it doesn't matter if the padding is noise or spaces because it's already obscured by the combination of the shared secret combined with the nonce auth and not letting users see other people's messages solves way more problems than this retarded complicated nip-44 scheme, that is also wasteful of data size

this is why i'm so mad about people not understanding the point of nip-42 and it's centrally about the fucking DM privacy!!!! plaintext attacks are not a real threat not being able to read your own messages is a real threat to usability verifying that relays are properly gating access to DMs is easy and cheap and is easy to stop any attempts to game this and appear that you are not giving them away yes, relays have privilege to see them of course, but this is far better than opening up the whole world to see it nip-44 is not solving any real problems for DMs compared to having auth

Feel free to offer better padding. Padding was discussed at length before and after nip44 and directly audited by the firm. No one has proposed anything better yet. I strongly disagree with your "zero risk of plain text attack". There are folks here, with money, whose sole goal is to break our encryption.

zero risk of plaintext attack it's an encryption algorithm that has been in use everywhere for more than a decade that has not been broken it's only retarded clients not providing good entropy, that has been the only vulnerability that has ever been demonstrated, and not just for symmetric encryption, but also for signing as well, as was found with a number of bitcoin wallets in past years that didn't use good entropy for the signatures, enabling the discovery of the secret keys not only that, senders don't have to use their actual key as their public key for the message, only the receiver's public key has to be the actual one used by the receiver so, good quality nonce, good quality random new private key to use the encryption, i mean, really, how can there be a plaintext attack if there is two quality obfuscation factors and the only constant is one out of three? even, clients can refuse to send DMs to a relay that doesn't demand auth for access to DMs, as far as actually protecting the users without adding cognitive burden putting a fancy lock on a door made out of cardboard isn't going to change the easy way to access - in this case - the metadata compared to a strong door (auth) that doesn't give you any information about the existence let alone the actual content of messages that are privileged

We can't control how implementers code. This is nostr. There is weird stuff everywhere. There are evil relays tracking users, evil clients tracking users, relay devs not knowing any better, clients not knowing any better. Most of the nostr code out there doesn't even think about privacy. We can't design a protocol expecting that everyone will have good entropy, good code or an authed service. All we can do is to offer primitives that makes sense even if everything else isn't there. Everything you said has been said during the NIP-44 debates and they culminated with NIP-44, NIP 59 and NIP17. But feel free to offer an updated variant of all of the above.

yeah, it's simple enough to have clients require auth to access DMs, then you put pressure on the relay operators and devs to make that a priority feature it's not really a technical problem, more of an education problem