I can see your point. Out of curiosity, there are few practical attacks in there mentioned both in client and server imolementations and protocol specifications. Regardless whether the paper is old, it would be interesting to know if the dev community looked into them esp the nip01 manadatory implementations. The bigger risk mentioned is the vulnerability 1 which is in protocol level and this paper is open for public to view. 😬
Discussion
Thats not a problem of nostr. In order to pull of that attack, they will need to change the event and recreate the event ID that matches the signature. That is impossible with today's computers. So much so that they could not create ANY event to explore that vulnerability.
They are only describing it because of vulnerability 2, when Damus wasn't verifying events they receive. That was fixed a while back on the Damus clients.
To this date, nobody was able to actually do Vulnerability 1. Even if you use the entire hash power of the Bitcoin network, you still cannot do it.
I see. the paper claimed that nostr relay operators can do this type of attack bcoz of lack of verification from the server end. genuinely curious to understand, are we saying that each event are verified in the server end (relay side) therefore, this attack cannot be done? Eg. No way relay operators can forge an event in the server side? ty
Even if they don't verify, we all verify on the client side and discard if the signature doesn't match.
But no, relay operators cannot do this. If they could, they would also be able to create Bitcoin transactions on the blockchain, since nostr uses the same cryptography tool. There is 2 trillion dollars of money to anyone that can do that. :)
that is a relief ppphhheeewwww sweat averted ty as always 🫂
An example of a protocol (and not client) concern is that if someone has your nsec you generally have no way of knowing. I could have your nsec right now, I could be reading your DMs (unless MLS), and I could continue to do for the next months or years, you'd have no real way of knowing I'm doing this unless I slip up and publish something with your nsec and you see that (which, if I was using a special client, would be unlikely) or some elaborate relay sting.
This sucks because the moment you suspect your nsec mave have been exposed, even if just a small chance, you then have to assume it has been and start on a new one, since there's no way to check the history as you can do with other platforms.
The more Nostr moves to Web of Trust the more it benefits the attacker (the knower of the exposed nsec) to just wait and let you build trust on your compromised account, over months or years, because that trust will be useful to cash out as some point in future.
You do have a way of knowing: if your DMs are going to a semi-trusted relay and you have to AUTH to it in order to read them (as you should under NIP-17) that relay may inform you about who has read them, when and from what IP address.
If we implement https://github.com/nostr-protocol/nips/pull/1647 that will also kill the attacker ability's to read anything in the first place unless he wants to reveal himself by registering his bogus device or publishing new encryption keys.
Agree those are potential fixes for NIP17 DMs, albeit they rely on all the things you mentioned. How many people are going to exclusively use auth-enabled relays with IP access alerts? And those alerts could also work backwards and inform the attacker of the true holder's IP, which needs to be accounted for. I mean it's all doable but these dumb relays sure are getting pretty smart.
Clients should nudge users towards using such relays for DMs, and that is happening right now in every client.
Relays were never meant to be dumb in the sense that they wouldn't have any internal logic, that was an unfortunate choice of words and a huge misunderstanding that damaged Nostr a lot, it's a surprise to me that people could have thought a relay would be really that dumb, do no filtering, no access control etc and Nostr would still work? Nostr would never work if it was like that.
That's fair.