I think it's worth knowing that the cryptography in Nostr appears to be a wreck. Here's a paper from EuroS&P this year, also presented at Black Hat on the crypto track:

https://eprint.iacr.org/2025/1459.pdf

The vulnerabilities here are pretty :yikes:

* The event protocol that drives the system doesn't authenticate public keys, so asymmetric signatures are performative: attackers that can intercept messages (Nostr servers, the presumed adversary of an E2EE messaging system) can just swap out keys and re-sign.

* Two major clients, the mobile phone Damus app and the web Iris app, don't even verify signatures to begin with.

* DMs in this system are unauthenticated CBC, so attackers can simply bitflip messages and events to say what they want.

* The apps do automatic link-preview, so they've managed to reconstitute the EFAIL attack: attackers can locate links within messages (they'll be revealed by SNI and DNS anyways) and then bitflip them to point to attacker-controlled servers, exposing both the URLs (which will often contain tokens) and, with a bit of extra work, the message itself (by tacking `?foo=` onto a URL).

* There's no key separation in the system, so you can trick users into running a subprotocol other than the messaging system, then establishing a session key, which will then be used for messaging.

These are really basic errors; this is mid-aughts-level cryptographic engineering. There are probably a variety of other reasons to use Nostr, but end-to-end security does not appear to be one of them.

▲

ursuscamp 5 days ago | parent | next [-]

So, I was part of the Nostr community for quite a while and was the author of a popular Nostr extension for Safari, before eventually giving up on Nostr for various reasons.

I haven't read that entire paper. Mainly, I skipped to the section you mention here:

> The event protocol that drives the system doesn't authenticate public keys, so asymmetric signatures are performative: attackers that can intercept messages (Nostr servers, the presumed adversary of an E2EE messaging system) can just swap out keys and re-sign.

I think you and the authors perhaps misunderstand the Nostr protocol. Nostr is, effectively, an identity system tied to a public key. The cryptography is sound. Your identity is your public key. When you request a user's profile, or their events, you request it specifically by their public key. That is unforgeable (assuming no bugs in the implementation, like what the authors found in Damus).

This does present UX issues that can manifest as security issues, such as "how can you verify that a user with a certain public is who they say they are instead of an impostor". That is a separate issue from whether the cryptography itself is sound.

▲

tptacek 5 days ago | parent | next [-]

If you read the entire paper you'll see that the paper presents a formalized set of security goals that acknowledge Nostr uses public keys as identities. They haven't misunderstood the system. Meanwhile: the cryptography is obviously unsound: it relies on unauthenticated CBC, and signatures that aren't verified, and provides attackers with the ability to coerce users into following links.

▲

jonstaab 5 days ago | parent | next [-]

The cryptography was thrown together in the very early days as a proof of concept, that reached some level of adoption because of how nostr suddenly grew at the end of 2022. The community has since largely switched to a new standard (NIP 44) which has been independently audited, although there are some popular clients that haven't yet transitioned.

▲

tptacek 5 days ago | parent [-]

From a brief scan, NIPS 44 seems reasonable; it's just AEAD ChaCha20, which is boring, which is good.

▲

eduction 5 days ago | parent | next [-]

Interesting way to spell “i was extremely wrong”

▲

skinkestek 5 days ago | parent | next [-]

I think it is an HN standard:

I am less on HN these days, but as far as I have seen:

Telegram is still judged by its very early releases, still called "unencrypted" while it is about as encrypted as your bank transactions (they definitely aren't e2ee either).

Signal can do what they want including dabbling in crypto currency without being open about it. Signal can also have extremely "interesting" bugs (didn't it at some point send messages to random people?) and glaring security issues (relatively trivial remote code in the desktop client IIRC a few years ago).

Last I checked WhatsApp was supposedly also good since they now use good encryption despite now being owned by Facebook, sending my social graph to them and sending peoples entire backups (including chats with me) unencrypted to Google for "free" (IIRC) backup.

That said these days I am definitely looking for Telegram alternatives.

▲

tptacek 5 days ago | parent [-]

Your bank doesn't operate in Telegram's threat model! You are never concerned that your bank's servers are attacking your transactions: if you can't trust your bank, you're fucked anyways. That's precisely what's not supposed to be the case about a messaging service!

	▲	nout 4 days ago \| parent [-]
		I agree with your bank related statements, but for the wrong reasons. You should not trust your bank.

▲

tptacek 5 days ago | parent | prev [-]

Is the protocol the paper was written about no longer deployed anywhere, or is this just a dunk?

	▲	jonstaab 3 days ago \| parent [-]
		It was (and still is) deployed in a number of places, so it's a valid criticism in that context. That said, it's mostly dunk.

▲

5 days ago | parent | prev [-]

[deleted]

▲

vnuge 5 days ago | parent | prev [-]

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 4 days ago | parent | next [-]

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 5 days ago | parent | prev [-]

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 5 days ago | parent [-]

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.

▲

some_furry 4 days ago | parent [-]

> 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.

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?

▲

vnuge 4 days ago | parent [-]

Regardless of the signer interface the procedure call remains the same. The client application determines what method it wants to use, then the plaintext is passed to the signer (web extension, nip46 remote signing, android etc) with the nip44.encrypt or nip04.encrypt procedure calls.

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.

▲

some_furry 4 days ago | parent [-]

That doesn't answer my question at all.

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?

▲

vnuge 4 days ago | parent | next [-]

We are obviously speaking from different understandings. I would say neither. I would need you to define your terms differently maybe.

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.

▲

duskwuff 4 days ago | parent | prev [-]

I think that the (unsatisfying) answer is that there's no established standard for how protocol selection works. nip04 and nip44 are completely different types of messages, and it's up to the client how it'll use and/or respond to them.

	▲	vnuge 4 days ago \| parent \| next [-]
		I guess it's worth also saying, there is no algorithm selection. Nip04 is dead for DMs. It doesn't need to be backward compatible. A user can't know which client another user is on, nor what their capabilities are, nostr is not smart in that way. Most, if not all, operations on nostr are completely stateless. 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.
	▲	vnuge 4 days ago \| parent \| prev [-]
		Kind of. They are standards for encryption, not the direct message itself. You'd be speaking about nip17. Which i've been mis-speaking as nip19. 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.

▲

sealeck 5 days ago | parent | prev | next [-]

> how can you verify that a user with a certain public is who they say they are instead of an impostor

This sounds awfully much like a cryptography problem to me!

▲

phaedrus30 5 days ago | parent | prev [-]

[dead]

▲

fiatjaf 5 days ago | parent | prev | next [-]

Unfortunately this paper doesn't live up to its goal of being a cheap attack on Nostr.

The fact is that clients do verify signatures from events received from servers, that is in the protocol specification and should be obvious to anyone mildly honest.

The entire assumption of the paper is that clients don't do that and it is void. Yes, they did find a couple of clients 2 years ago that didn't verify signatures -- so much for a vulnerability in the protocol. I guess they wanted Nostr to have a code police arresting client developers who didn't finish their implementation?

Aside from that the attacks they demonstrated depend on a bunch of other absurd circumstances (like you have to manually and voluntarily type the URL of the attacker server in order to be attacked) but it's not even worth talking about them since the basic assumption is so completely false already.

The encrypted messages stuff is not even a core part of Nostr anyway, Nostr is a broadcasting protocol for public or semi-public content. Encryption can be added on top and there are multiple ways and proposals for how to do it, including an implementation of MLS and other methods and I personally mostly do not care about any.

I wish the paper authors were more honest and republished their work with the title: "the dangers of trusting a cryptographic signature without verifying it", but I imagine that it would have been too obvious and worthless if it was phrased like that.

▲

tptacek 5 days ago | parent [-]

They're academic cryptography researchers. They do not care what messaging system you use. This is what academic messaging cryptography papers look like; a paper like this is why Matrix transitioned (is transitioning?) from ad hoc cryptography to MLS.

	▲	mediumsmart 3 days ago \| parent [-]
		Thanks for clearing up that the issue is academic as in irrelevant concerning nostr

▲

jb55 5 days ago | parent | prev | next [-]

This is completely nonsense, most clients do in fact check signatures. All relays do as well.

> Two major clients, the mobile phone Damus app and the web Iris app, don't even verify signatures to begin with.

Author of Damus here. this is an analysis of an old version. This has since been fixed. In the early days we connected to a fixed relay list of trusted relays. These relays verified signatures. This was just a pragmatic tradeoff thing until we had an optimized work queue for verifying notes (this lead to nostrdb, a custom embedded nostr database built on lmdb. it's a sqlite but for nostr https://github.com/damus-io/nostrdb)

> DMs in this system are unauthenticated CBC, so attackers can simply bitflip messages and events to say what they want.

not really true since the whole note is covered by a secp256k1 signature.

> The apps do automatic link-preview, so they've managed to reconstitute the EFAIL attack: attackers can locate links within messages (they'll be revealed by SNI and DNS anyways) and then bitflip them to point to attacker-controlled servers, exposing both the URLs (which will often contain tokens) and, with a bit of extra work, the message itself (by tacking `?foo=` onto a URL).

you can turn off these, you can turn off images as well. people should run a VPN of course if they are worried about these things.

▲

akerl_ 5 days ago | parent | next [-]

How does a VPN protect against flipping a URL to exfiltrate the message contents to an attacker-controlled server?

▲

tptacek 5 days ago | parent | prev [-]

I don't think you can say "this is complete nonsense" and "this has since been fixed" in the same comment. Also: don't use ECC signatures as MACs. Signatures are not MACs.

▲

nbngeorcjhe 5 days ago | parent | next [-]

> Also: don't use ECC signatures as MACs. Signatures are not MACs.

Could you explain more? What are the downsides of a signature vs. a MAC here?

▲

nout 5 days ago | parent | prev [-]

He says "this is complete nonsense" specifically about the statement quoted. Not about the whole report.

▲

tptacek 5 days ago | parent [-]

They're saying that about a concrete claim the paper makes that they concede in the next paragraph.

	▲	nout 5 days ago \| parent [-]
		I don't want to speak for Will, but from my read he is specifically highlighting that "The event protocol that drives the system doesn't authenticate public keys" is the nonsense, because the protocol specifies that clients validate signatures on events using the public keys. This makes sense in nostr, because anyone at any point can mint new public key and start posting events and other people are free to start following them, from which point they can ensure that the new events are coming from the person holding the same private key. And this is what relays and clients do.

▲

irq-1 5 days ago | parent | prev | next [-]

I tried to find out what key algorithm is used -- not listed anywhere. Everything led to pages about Blech32 (a bitcoin key encoding).

https://hellonostr.dev/en/introduction/

The encoding seems to have an unmentioned/unaddressed version number included, both in the nostr doc and the bitcoin docs.

npub1abcxyz... is npub (header) 1 (version) abcxyz... (key)

Now take a look at the doc (linked above.)

	▲	vnuge 5 days ago \| parent [-]
		nip01 defines the use of secp256k1. Again, the same as bitcoin.

▲

jonstaab 5 days ago | parent | prev | next [-]

The criticisms are either implementation dependent (not checking signatures, which defeats the entire purpose of the protocol), or based on a very early proof of concept encryption scheme which has since been superseded (by NIP 44, which was independently audited). There's nothing substantial or actionable here (any more).

▲

Imustaskforhelp 5 days ago | parent | prev [-]

why is this the first time that I came across these issues. Someone should talk about these issues asap. What federated platform might be the more secure tho protocol wise, bluesky (at protocol) or fediverse

	▲	nout 5 days ago \| parent [-]
		The paper seems to be referencing issues in client apps during early development of those apps that have since been fixed. So that's likely why it's not being talked about now.