Old paper, but this is why we don't use NIP04 DMs anymore. Also, I don't understand why would anyone say that Nostr has an issue if they only test a couple clients, mostly Damus. Clients might have a lot of problems. But those are not Nostr problems. They are that specific clients issue. They should have said that. They seen to think the way Damus does things is Nostr itself, which is dumb. Either they don't know how the Nostr ecosystem works or they are intentionally misleading people.
Replies (4)
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. 😬
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.
NIP-04 by itself is not vulnerable and is secure against these “attacks” as signatures exist
AES-CBC (the core of nip04) has been removed from many crypto suites, including TLS 1.3, due the many security issues in poor implementations, mostly related to oracle padding attacks, which are also possible in nip04.
