hzrd149 / nostrudel

A sandbox for exploring nostr
https://nostrudel.ninja/
MIT License
122 stars 34 forks source link

"Public Key Color" is easy to attack #162

Open Giszmo opened 4 months ago

Giszmo commented 4 months ago

I noticed a new feature dropped today - public key color. Mine is green, so I first took it as some trust rating.

Truth is, the human eye can't tell 3 byte ... 16 million colors apart. It's closer to 3 semi byte ... 64 colors.

All those early vanity keys will end up black but a vanity black-enough pubkey would cost on average 64 tries. If the public key color ever catches on and becomes relevant, it's really trivial to fake.

To save the feature I'm thinking about making it a bit harder for impersonators:

  1. make the account color contingent on the logged in user. Instead of first bytes of Alice pubkey, use first bytes of sha256(Alice, Bob) for Bob and sha256(Alice, Carol) for Carol. Now the impersonator has real trouble to impersonate Alice such that both Bob and Carol would fall for it at almost no cost except for the requirement to be logged in. To not have this feature when not logged in I think is ok. It can also fallback on some standard empty key then or a random number stored in a cookie.
  2. add colors. Make it use the first 12 byte instead of only 3. Users will less confuse this with a trust rating and attackers have to brute force more to impersonate somebody image
  3. Like 1 but instead of using the logged in user's pubkey, use a random number stored encrypted with the profile. Attackers would actually be unable to fake the color from public data even if the target would share screenshots. This approach would save the esthetics of the currently implemented feature as a single color would suffice.

Assuming 64 colors are what we can somewhat tell apart, implementing the first two measures would add a cost of brute forcing 4 billion pubkeys per victim. For DMs that is still cheap but impersonators could not easily get away replying in public.