Live data from Hacker News

Nostr

nostr.com

261–270 of 347 posts

Re: Nostr

#261
post #244

Earlier quoted context omitted.

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

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

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.

Re: Nostr

#262

A big misconception I've seen is the assumption that Nostr relays are federated and share messages between one another. This is not how it works. So if you're building a "Twitter clone" the client app must search multiple relays and post to multiple relays. If clients are not using a relay in common they cannot see one another. The end result is a bad experience for both user and developer. Using a single relay is ce…

Since relays don't own user generated content, there is no need to "federate" client's generally rely on user-selected relay sets. The user chooses where they want to read/write events to/from.

That said, many of the "larger" relays do store events from other relays (federation if you prefer). Primal does, TheForrest does, nostr.land and so on. Nostr.land specifically has a purpose of aggregating notes from many other public relays, with spam filtering. It's a paid relay built for that purpose. Don't want that, use someone else.

Most users get to see 99% of notes from the current relay federation now, but it's also impossible to check those metrics.

Certain clients and signers store notes privately so if a relay ever decides to censor your notes you just publish to a different relay if they don't have your notes already.

Chances are if you use ANY of the popular paid relay providers, your going to get warnings on 3/4 write events that the other relays _already_ have the note published to the first. It's usually that quick...

Finally, relays "federate" by acting as clients themselves. Most relay software available already offers this as an option, may use it as a local cache for when on mobile and network/wifi is slow. Their local relay slowly pulls notes from other relays (or outbox) and caches those notes for when they load their client up. It's cache and the client dev didn't even have to write that functionality, it was transparent.

Finally, other's mentioned outbox, which has it's own set of issues as well, but it doesn't matter because a client developer can choose to give the user the option if they want. Going from federated, to peer-to-peer which was the intention.

Re: Nostr

#263

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 ser…

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

Re: Nostr

#264

Earlier quoted context omitted.

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.

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.

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

Re: Nostr

#265

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 ser…

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

Re: Nostr

#266
post #236

Why can't these projects separate the use-cases from philosophies and from implementation when presenting them? At first glance I don't understand what this is. Is it a social network? A protocol? "Pro-censorship? I need to read some blog article... It's been like this with scuttlebutt/gossip, and rest of the alternative internet/fediverse with mastodont and activitypub and diaspora. Instead of asking questions like…

Nostr is essentially a compromise between p2p and traditional web architectures. It cuts with the grain of the internet by using web servers, while reducing the dependence users have on servers by using keys for identity and digital signatures for authenticating data.

The effect is that users have "credible exit" (among other things), which has been discussed for years. This doesn't really create any new "use cases", which is why the use case is often described as "whatever, it's the new internet".

What it does do is introduce a very different set of trade-offs which favor user control over platform control (with the attendant UX trade-offs (or at least a different set of UX idioms)).

The reason the focus is on social is because that represents the majority of applications that do exist, the original motivation for building the protocol, and a value proposition (censorship resistance) that lots of people can relate to.

Re: Nostr

#267
post #232

Earlier quoted context omitted.

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

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.

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

Re: Nostr

#268

Earlier quoted context omitted.

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 (N…

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.

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.

Re: Nostr

#269

>apolitical communication commons Some people say that labeling yourself apolitical is 1, a polticial statement 2, a privilege itself which puts you into a certain socio-political position

This is exactly what struck my eye. As someone from RU, I came to strongly identify "apolitical" with silent status quo supporters. Under an authoritarian regime, that means prosecuting people and lack of freedom of speech. Nostr? They'll just declare hosting a relay illegal and criminalize use, like they already did for other services.

They key is that your nostr app connects to hundreds of relays (and can work over Tor too), so that shutting down any single relay doesn't have notable effect.
Post reply on HN