[vnuge]

nostr cryptographic developer here (author of libnoscrypt C library)

Nip04 has been deprecated, and to be clear, in practice the nip04 payload is in a signed nip01 event wrapper.

nip44 replaced nip04, which has been reviewed/audited. Does use authenticated encryption in the message payload with forward secrecy, again in practice wrapped in a nip01 event, singed by the author, usually by the same cryptographic software used to encrypt the message.

nip44 is becoming more widely used for direct messages and other "private" metadata stored on relays. It's chacha20 + hkdf.

[tptacek]

Hey, I should say this, and wish I had earlier:

I don't really so much care whether Nostr is good or bad. I'm a connoisseur of cryptographic vulnerabilities, and the ones in that paper are fun. We host a podcast (me, Deirdre Connolly, and David Adrian) that is mostly about good crypto vulns. If there's someone affiliated with Nostr that would want to chat for an hour or so about how applicable the vulns in this paper are or aren't, and how they're addressed in NIP44 --- we'd love to talk. My email address is in my profile. Whoever showed up, they'd be in good company!

https://securitycryptographywhatever.com/

[duskwuff]

How robust is nostr against downgrade attacks - can an attacker induce users to use nip04, or are there safeguards against this?

(I have no significant knowledge of the protocol; if this is a meaningless question just say so.)

[vnuge]

Hard to say how relevant that is. DMs are simply a collection of events sitting on a relay. It's not really a mutual tunnel, most clients implement nip44 via nip19 (giftwrap DMs) so your ni04 message wouldn't likely make it to them. It's not considered backward compatible such that you could send a user a DM, then cause their client to downgrade to the DM scheme that uses nip04.

It's also worth noting, the user _must_ be made aware of the encryption method that was used, their "signer" application, which is also responsible for encryption and decryption, would require their permission to do an operation in either direction. Users may often choose to grant a trusted client application the permission to decrypt all nip04 or nip44 messages alike, automatically, or generally manually with a popup. That's up the signer application how granular the permissions get.

To be clear this is a client implementation detail, im not a client developer, so I can't say in practice how many have handled the UX on this, but know that the signer, and the user had the final say on which algorithm was granted permission.

Clients and signers alike could choose to block obsolete encryption methods if they choose.