pull down to refresh
100 sats \ 4 replies \ @optimism 6h \ parent \ on: Not in The Prophecies: Practical Attacks on Nostr nostr
This only works when message signature isn't verified?
reply
Based on my understanding of NIP-59, the correct approach for unwrap, unseal, render would be:
- Check the
sig
on the kind1059
(and thep
tag), if no match against the givenpubkey
then discard because it's spoofed. - Decrypt the
content
of the kind1059
, this results in a json string of a kind13
and not an url. - Check
pubkey
to be a known sender and then thesig
on the decrypted kind13
message to match that key, if no match then then discard 1 - you now have authenticated the entire message includingpubkey
andcontent
to be from a known contact. - Decrypt the sealed kind
n
(often kind14
) from the previously decrypted kind13
, 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
-
And notify your contact and everyone that wants to listen because this is a spoofing attack! Be the Karen! ↩
reply
Re:But if the client uses cache-after-verifyCache 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 theid
from the event payload each time you load it; do not rely solely on a relay-supplied or previously cachedid
. 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.