vnuge (u/vnuge) - Readit News

vnuge commented on Nostr nostr.com/... · Posted by u/dtj1123

duskwuff · 6 months ago

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 · 6 months ago

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 commented on Nostr nostr.com/... · Posted by u/dtj1123

duskwuff · 6 months ago

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 · 6 months ago

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.

vnuge commented on Nostr nostr.com/... · Posted by u/dtj1123

some_furry · 6 months ago

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 · 6 months ago

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.

vnuge commented on Nostr nostr.com/... · Posted by u/dtj1123

some_furry · 6 months ago

> 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 · 6 months ago

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.

vnuge commented on Nostr nostr.com/... · Posted by u/dtj1123

duskwuff · 6 months ago

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 · 6 months ago

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.

vnuge commented on Nostr nostr.com/... · Posted by u/dtj1123

irq-1 · 6 months ago

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 · 6 months ago

nip01 defines the use of secp256k1. Again, the same as bitcoin.

vnuge commented on Nostr nostr.com/... · Posted by u/dtj1123

tptacek · 6 months ago

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.

vnuge · 6 months ago

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.

vnuge commented on Nostr nostr.com/... · Posted by u/dtj1123

dbushell · 6 months ago

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 centralised and defeats the point. Using multiple relays is slow and cumbersome and requires the user to know/care which relays they are connecting to.

When I played with Nostr a couple years ago the "NIPs" were already a complete mess. Later NIPs supersede earlier NIPs changing how clients are supposed to interpret messages. At least some are flagged as "unrecommended: deprecated" now.

vnuge · 6 months ago

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.

vnuge commented on Ask HN: What are you working on? (March 2025) · Posted by u/david927

vnuge · a year ago

All kinds of personal FOSS projects I have mostly yet to release.

[1] noscrypt - portable C cryptography library for nostr [2] vnlib - C# + C libraries for server applications, eventual high performance alternative to ASP.NET. It's really just a collection of libraries that are optimized for long running server applications. [3] vncache - vnlib cache extensions and cluster cache server over web-sockets [4] cmnext - self-hosted, vnlib based, json-file CMS + podcast 2.0 server [5] simple-bookmark - kind of deprecated, vnlib based, self hosted bookmark server

My software homepage (most up-to-date) https://www.vaughnnugent.com/resources/software/modules

I know most of yall will probably want GitHub links so here [1] https://github.com/VnUgE/noscrypt [2] https://github.com/VnUgE/vnlib.core [3] https://github.com/VnUgE/VNLib.Data.Caching [4] https://github.com/VnUgE/cmnext [5] https://github.com/VnUgE/simple-bookmark

vnuge commented on I'm closing up shop on my Mastodon for the foreseeable future vkc.sh/its-not-you-its-me... · Posted by u/justaj

lrvick · 2 years ago

Any medium where you invite commentary from strangers on the internet is going to be full of ignorant commentary.

If this is something that stresses you out, probably best to disable comments from anyone you do not follow.

Simple as that.

I do not think this is a problem with the tool.

I do think over-exposure to internet commentary is toxic. Like alcohol, it is a poison that is only fun if you are capable of moderation. Not everyone is, and that is okay.

For me I was addicted to reading comments from viral nonsense I did online. Giving up LTE and carrying always-accessible always-online devices meant I can only access the Internet from fixed locations that I am only willing to spend a limited amount of time in.

The internet does not follow me or summon me with notifications anymore. I visit the internet on my terms.

For me, this made me much happier with my relationship to the internet. YMMV.

vnuge · 2 years ago

This is a huge step I took a few years ago as well. My mobile phone is still a smart phone but It can only do dumb phone things + email which I keep quiet and check on a schedule. No notifications really of any kind. No real social media and I never receive notifications from any of them I have to schedule time to check on them. It has become quite freeing although I definitely miss the "euphoria" of that world if it makes sense, which is a sign of addiction I didn't realize till I opted out.