32 ms·

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 var

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.

sealeck 1y ago
> 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!
tptacek 1y 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.
- jonstaab 1y ago
  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 1y ago
    From a brief scan, NIPS 44 seems reasonable; it's just AEAD ChaCha20, which is boring, which is good.
    - deleted 1y ago
      [deleted]
    - eduction 1y ago
      Interesting way to spell “i was extremely wrong”
      - skinkestek 1y ago
        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 1y ago
        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 1y ago
        I agree with your bank related statements, but for the wrong reasons. You should not trust your bank.
- vnuge 1y 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.
  - duskwuff 1y 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 1y 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.
      - some_furry 1y ago
phaedrus30 1y ago
[dead]

sealeck 1y ago

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

tptacek 1y 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.

jonstaab 1y ago
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 1y ago
  From a brief scan, NIPS 44 seems reasonable; it's just AEAD ChaCha20, which is boring, which is good.
  - deleted 1y ago
    [deleted]
  - eduction 1y ago
    Interesting way to spell “i was extremely wrong”
    - skinkestek 1y ago
      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 1y ago
        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 1y ago
        I agree with your bank related statements, but for the wrong reasons. You should not trust your bank.
vnuge 1y 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.
- duskwuff 1y 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 1y 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.
    - some_furry 1y ago

phaedrus30 1y ago

[dead]