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.)
(I have no significant knowledge of the protocol; if this is a meaningless question just say so.)
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.
Let me ask a more pointed question about downgrade attack resistance then:
Is the algorithm being used determined by the encrypted message contents? Or is it determined by the key controlled by the signer app?
The user is then requested to confirm the encryption operation. So a "downgrade" could happen in two ways. The client selects nip04 without the user's instructions, and the signer does not properly guard or notify the user that the message to be encrypted is using nip04. Still not really an attack I don't think, since no "sessions" exist in DMs there shouldn't be any way a remote user gets to cause a client to change algorithms.
To answer directly, the client app chooses, makes a remote procedure call with the desired algorithm, user confirms, message is encrypted, returned, signed (another rpc round-trip), then written to relays.
The signer application is ALWAYS authoritative, if it chooses to.
Is the decision (regardless of who fucking decides) based on metadata attached to the key the client controls or from a breadcrumb included in the message itself?
In all cases the client application chooses the algorithm used when the user writes a DM. What do you mean by breadcrumb in the message. Message in what context? Message sent to the signer?
Edit: Maybe I should say the client developer? Is that the answer you're looking for? The developer _could_ give the user the option of choosing which to use, but clients generally are hard-coded to use one or the other.
When a user decides to send a DM to another user, the client must choose the standard for encryption, and message wrapping. Then hope the other user is using a client that implements the same standard, in order to decrypt the message.
Again, remember, DMs don't have a session. Every message derives a new symmetric key. The only metadata that makes a "chat" session is the timestamp, and the public keys of the users.
https://github.com/nostr-protocol/nips/blob/master/17.md
Notice that nip44 IS the standard. again, nip04 is deprecated, and should be treated by clients as such.