pull down to refresh
100 sats \ 5 replies \ @ek OP 8h \ 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
reply
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.