pull down to refresh

100 sats \ 4 replies \ @optimism 7 Aug \ parent \ on: Not in The Prophecies: Practical Attacks on Nostr nostr
This only works when message signature isn't verified?
write
preview
100 sats \ 3 replies \ @ek OP 7 Aug
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 7 Aug
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 7 Aug
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 7 Aug
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