pull down to refresh

100 sats \ 5 replies \ @ek OP 14h \ on: Not in The Prophecies: Practical Attacks on Nostr nostr
PoC for plaintext recovery:
If I understand this right, this doesn't allow you to recover the plaintext for any message. It must be a link or not contain any whitespace.
It works by changing the first encrypted block of a message into a link to the attacker's server, and when the recipient's client fetches the link preview, it appends the rest of the message to the URL, but only up to the next whitespace.
Cool, but not arbitrary plaintext recovery afaict
write
preview
100 sats \ 4 replies \ @optimism 13h
This only works when message signature isn't verified?
reply
100 sats \ 3 replies \ @ek OP 12h
Mhh, good point, I would think so
But if the client uses cache-after-verify, then it won't verify the signature again for the same event id
reply
100 sats \ 2 replies \ @optimism 12h
Based on my understanding of NIP-59, the correct approach for unwrap, unseal, render would be:
  1. Check the sig on the kind 1059 (and the p tag), if no match against the given pubkey then discard because it's spoofed.
  2. Decrypt the content of the kind 1059, this results in a json string of a kind 13 and not an url.
  3. Check pubkey to be a known sender and then the sig on the decrypted kind 13 message to match that key, if no match then then discard 1 - you now have authenticated the entire message including pubkey and content to be from a known contact.
  4. Decrypt the sealed kind n (often kind 14) from the previously decrypted kind 13, which isn't signed, but that's ok because we've authenticated the seal.
Relevant: Moxie's cryptographic doom principle
PS: Always turn off link previews if you can, and if you can't just realize you don't have any privacy.
Re:
But if the client uses cache-after-verify
Cache what? That any message from a pubkey no longer needs to be verified? What's this feature?

Footnotes

  1. And notify your contact and everyone that wants to listen because this is a spoofing attack! Be the Karen! ↩
reply
100 sats \ 1 reply \ @ek OP 11h
Re:
But if the client uses cache-after-verify
Cache what? That any message from a pubkey no longer needs to be verified? What's this feature?
It's a vulnerable performance optimization. See Q4 in FAQ above:
When caching events, first verify them successfully and re-compute the id from the event payload each time you load it; do not rely solely on a relay-supplied or previously cached id. Vulnerable clients followed the “cache-after-verify” rule but still failed integrity checks because they cached only the id and skipped this re-computation step.
reply
75 sats \ 0 replies \ @optimism 11h
I think the main cause of this is the hash being included in the message. That's the design error that puts bad ideas into people's heads.
I guess they kind of address it but probably the best thing would be to delete it from the message altogether.
reply