pull down to refresh

100 sats \ 4 replies \ @optimism 7 Aug 2025 \ 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 2025

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 2025

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?

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

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