Nostr Web Client

Get rid of that NIP-04 support

as an amateur cryptographer, this anti-nip-04 thing is completely nonsensical

chacha-poly-1080 in not stronger than AES 256 ... what is it CBC? ... no, AEAD... with no actual extra data btw, so it was pointless making it that anyway

the giftwrapping enables some degree of forward privacy but it also makes it complicated for clients to see messages the user wrote, and i notice this all the time clients are not seeing the messages

after making my relay really nice and easy to extend and work with one of my first priorities is making messaging work properly

like, seriously, do people not get it the reason why i am always talking about nip-42 auth all the time is so you can prevent access to these messages in the first place?

the right way to do things is to test and certify that relays are not allowing access to events they don't have proof of being in the conversation

it also applies to application specific data events too, which are encrypted, by some clients, but not by others (looking at you #nostrudel )

Reply to this note

Please Login to reply.

Discussion

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

seriously, has anyone actually thought through the problem of implementing clients to pull messages that contain no reference to a user without leaving them wide open for anyone to read?

first rule of signals intelligence is don't send a signal you don't want to be noticed for its mere existence, or at worst, exposing you to a potential plaintext attack if the encryption has a flaw

i honestly don't think that anyone else in nostr dev really understands the problems they are trying to solve with nip-04, nip-44, and the rest

Vitor Pamplona 1y ago

The main issue is that nip-04 leaks way too much data not only to the relay, but to the public in general. On top of that, the encryption procedures of NIP-04 are laughable. The lack of padding alone is a major problem. Imagine saying "Hi" on a DM and that gets converted to 4 encrypted chars. Besides letting everyone know your message is small, how hard is to break the encryption of a 4 char cipher text? Not that hard.

If you repeat GMs around, now you have 100s or 1000s of 4 char encrypted messages. How hard would it be to recover your shared key knowing all those little messages? Not that hard.

With enough shared keys, how hard would it be to figure out somebody's nsec? It gets in the realm of "possible" with today's available computing power.

Vitor Pamplona 1y ago

on top of that, it doesn't make any sense to have a client that has fixed most of those issues make worse versions available to the user.

Users will just use the worse versions if it is available.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

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

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

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

Vitor Pamplona 1y ago

Most people are not using authed relays for DMs. And likely they never will. The DM solution we made was explicitly designed for that in mind.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

you are never going to solve this problem while you let stupid people building shitty clients (and not you, or hzrd or hodlbod, you all have implemented auth) you can't protect users from bad shit without at least providing your own system with teh right best practices implementation

if you let other people's bad designs impact your engineering decisions and in doing so reduce the security of your users, that's on you, you can't palm that off to the dumbasses who don't do it right... clear up your understanding of what you CAN do and stop talking about difficult problems that are much harder puzzles

Vitor Pamplona 1y ago

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.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

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

Vitor Pamplona 1y ago

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.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

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

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

the public leak is because relays are not implementing auth and until recently almost no clients did either

this is a really small change that prevents this leaking, the main threat

users can control their use of relays and if it is discovered a relay is run by spooks, then people can avoid it

it's not rocket science... don't allow access to DMs without auth. end of.

making complicated obfuscation schemes are not going to help, because "giftwrap" just means the receiver is mentioned not the sender

how does a client migrate this data across to other clients the user is using if they then have to literally search for other people's DMs that *might* have been sent by them

you really need to think a lot more about what the actual problems are instead of wrapping it in more and more complicated encryption schemes

Felix 1y ago

Is there a tool to request deletion for all sent nip4 dms? Asking for a friend😂

Vitor Pamplona 1y ago

Talk to your relay operators. They can do this easily.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

the leak to the public is because of relays not implementing auth

at minimum, they should implement auth to access DMs

if everyone's relay did this, that problem goes away

it's never a better solution to use obfuscation when you can instead simply not send out the signal

Vitor Pamplona 1y ago

Agree. With it's not just AUTH as defined in NIP-42. It's AUTH + a p-tag filter based on the logged in user. Virtually no relay does this.

But even if it does. The relay itself SHOULD NOT be able to track anyone else but the user that connected.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

yeah, this is an essential feature, and nobody is prioritising it as they should be

it's like putting a big fancy padlock on a shitty wood and cardboard gate, to add all this obfuscation to the messages when you could just have auth and not send out messages that don't relate to an authed user pubkey

really, you can't solve that problem any other way

the relay is acting as an untrustworthy intermediary when it doesn't have controls to prevent strangers reading your private messages