lightninglabs / taproot-assets

A layer 1 daemon, for the Taproot Assets Protocol specification, written in Go (golang)
MIT License
456 stars 110 forks source link

[enhancement]: Mitigate homograph attacks from human-interpreted strings #507

Open dstadulis opened 11 months ago

dstadulis commented 11 months ago

Background

As a taproot-assets user I want to only need to visually inspect an asset name in order to confirm that a bootstrapped asset has the name I believe it should have

As a taproot-assets asset issuer I want to ensure that my asset name cannot be confused with visually indistinguishable asset names in order to preserve my asset's name recognition and deny fraud


Given that many unicode glyphs appear visually indistinguishable from each other but map to different code points, there is a potential attack vector against humans visually comparing asset names in which an attacker could attempt to defraud a user by using two homoglyphs. Domain names call this the IDN homograph attack

Mitigation options

Strings sensitive homograph attacks:

Crypt-iQ commented 11 months ago

Using only an asset's name is fragile imo because it's hard to tell the difference between some ascii characters like l and I or l and 1. Isn't there an asset hash that people can use instead?

jharveyb commented 11 months ago

Some notes on normalization that help avoid some cases of this:

https://go.dev/blog/normalization

Using only an asset's name is fragile imo because it's hard to tell the difference between some ascii characters like l and I or l and 1. Isn't there an asset hash that people can use instead?

Yes, the asset ID would be unique even across visually-similar asset tags. I think option 3 / convert asset ID to visual fingerprint seems best.

You could maybe have a universe reject visually-similar asset tags but that doesn't sound robust tbh / adds a form of squatting.

Crypt-iQ commented 11 months ago

Another string that might be sensitive (adding to the list) is the proof courier address