SEP - Identicons for Stellar accounts

[Gleb Pitsevich]

Starting a conversation on whether it makes sense to have a SEP for the standard algorithm for generating identicons for Stellar accounts.

Here's the draft SEP:

https://github.com/stellar/stellar-protocol/pull/467/files

Identicons compliant with this proposal have been already integrated in a few projects in the ecosystem, including Lobstr, Stellarterm and StellarExpert.

Links to JS and Python implementation are included.

Worth noting, that our initial implementation used an md5 hash of the full address to generate the identicons.

After a conversation with @Orbitlens, we've switched to using only first 16 bytes of the key, since public key is a pseudo random sequence.

This improves the speed of the icon generation, but has a side effect that the addresses with the same starting bytes would have the same identicon.

Example:

https://id.lobstr.co/GA2T66AMBWHNR7S23MMQ4RR5KIPITETFOUC6DATE74FIFGRYKQIW7RWV.png

https://id.lobstr.co/GA2T66AMBWHNR7S23MMQ4RR5KIPITEVFPSVCD7JO25YILFQY3WHQG3UR.png

So, technically, for any given Stellar address, it is rather easy to find a different Stellar address with the same identicon.

On a separate note, given that most clients tend to display such address as something similar to GA2T...7RWV, it might be worth changing the logic to use *the middle bytes* of the public key. Also, people would often check the first and last digits in the address anyway, but rarely check all the characters in the middle. Using middle bytes also makes more sense in that regard.

Anyways, please let me know if you have any feedback.

Thanks,

Gleb.

[Antoine Bodin]

> Starting a conversation on whether it makes sense to have a SEP for the standard algorithm for generating identicons for Stellar accounts.

Yes, it makes sense to standardize it.

That would be a useful security enhancement.

> On a separate note, given that most clients tend to display such address as something similar to GA2T...7RWV, it might be worth changing the logic to use *the middle bytes* of the public key.

Agreed, but...

The attack you're trying to prevent is people generating valid pubkeys that would collide with user's identicon.

Even when starting at byte 4, there's room to perform that attack.

I can see two solutions:

- Using bigger identicons.

- Include a checksum of the whole key (and see if it can still be broken).

There are fast & portable hashing non-cryptographic algorithms. Those are not collision-safe, but may be enough for checksum purposes (eg: MurMurHash3 is about 50 lines).

--
You received this message because you are subscribed to the Google Groups "Stellar Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stellar-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/9301f922-4f57-4cb0-9b52-3c48563cfc49%40googlegroups.com.

[Leigh McCulloch]

A few websites appear to be using this format for identicons of Stellar accounts so I agree it makes sense to merge this draft. Merged as SEP-33.