This is obviously AI to everyone but the most gullible people imaginable. However, this is becoming more and more common and we should really crack down on it before it completely escapes social acceptability containment.
Cashu is a working chaumian ecash protocol built on Bitcoin. It is quite functional and has some subset of bitcoiners actually using with, with many wallets and mints building on the protocol.
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.
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.
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.
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!
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.
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!
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.
> 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?
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.
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?
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.
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.
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.
I've been a ruby user for almost 15 years. I've been to several RubyConfs in that time. I have never found that to be true. It's a thin veneer over rampant toxicity and political extremism. Many of the evangelists in the Ruby community garnered a horrible reputation outside of Ruby, then migrated to insular social media applications which no one uses, causing the slow and persistent decline in the popularity of the language.
Although I haven't been in the ruby community as long as you, I have been to two RubyConfs. I didn't notice any overt toxicity or political extremism when I went but I'd be interested to hear more about your experience if you don't mind sharing?
I started using Ruby almost 20 years ago. I've been to a boat load of Ruby conferences. I even ran a hippy dippy Ruby event on the east coast for about 10 years.
It was welcoming.
Then 2016 happened. Then some Rubyists began spewing hate and distrust at people just because of their religion.
It wasn't political until certain groups made it political.
I never looked up the origin of the name before. Interestingly enough, I associate Bellingcat with permanent cold warriors, a group of people who seem determined to fulfill the moral of the tale.
The sales pitch: It's permissionless, but also has baked in compliance. These two things are not compatible. Stripe must comply with US regulation, they aren't going to launch a financial network that is actually permissionless.
As an avid X user, I think she did an astonishing job keeping the platform afloat at all given that the owner is borderline insane and uses the platform as his personal playground.
As was probably covered in the thread yesterday, it's kind of an impossible position. Anything she did can and would be attributed to Elon. Anything she could have done to challenge Elon would have resulted in being pushed out. Nobody could have been in that position and done well. She wasn't in a good position to be a scapegoat, nor to do anything, really. The whole thing was pointless. Sounds like she made some good money.
Yeah I can't imagine her actually doing some big decisions on her own, when Manchild keeps jumping all over the place and keeps flipping his emotional opinions faster than I can flip (manual) light switch.
Afloat in what sense? Usage is down. At least for me, the vast majority of my social and professional network has moved to other platforms. And every time a public figure (journalist, politician) does post it feels like they're immediately swarmed by right-wing propaganda idiots/bots. Feels like a complete mess.
The article says that it belonged to a species of deer called “wapiti”. Since I never heard of it, I looked it up and it’s just an elk. Why didn’t the article just say “elk” which is the much more common term?
- Elk is ambiguous. There's an Elk/Wapiti in North America, Central Asia, and East Asia, and another species of deer referred to as an "Elk" by people in Eurasia, but which is known as a "Moose" in North America.
- Because journalists these days don't have time to look these kinds of things up. The original paper only refers to it as wapiti/cervus canadensis/deer. If the whoever wrote that article knew it refers to an elk, they'd have pointed that out for the reader.
Elk is pretty ambiguous — it refers to different species depending on the context (in Europe, ‘elk’ refers to what in north America is called a moose. Wapiti is a name for what ‘elk’ refers to in North America). You get a similar problem with the words ‘hawk’ and ‘buzzard’
And badger -- In Europe they are small adorable members of the Meles genus. In the Americas, Africa, and Asia the word refers to larger and more aggressive animals in the Taxidea and Mellivora genera that just look superficially like Meles.
The wapiti is the animal on the reverse of the Canadian 25 cent definitive coin. Perhaps the folks who write the article are just educated and worldly.
Which is ironic, considering how Bitcoin security budget will very likely decrease as time goes on with Bitcoin halvenings and low transaction fees going to miners
