If you are not doing anything special to filter the images, it's not terribly difficult to find a duplicate. If Alice is concerned about her security, she would do well to check every bit of her fingerprint twice. If Alice is my grandmother, on the other hand, I would be lucky if she even glances at the fingerprint at all, much less verifying it. In short, the point of Vash is to augment existing security mechanisms to make them more accessible to an audience with less understanding of public key cryptography. It's definitely not as good as the raw hex string, but it should allow you to use public key cryptography at all in markets where you might not have wanted to before.

That said, you really should be filtering the outputs. A good keygen implementation will need to take into account the visual properties of the output signature, as well as the cryptographic properties of the key (e.g. so that you can have a checkbox for colorblindness in your UI). The generator is random and will occasionally spit out images that are just obviously not useful and filtering the outputs solves many of these problems. If your keys are distributed centrally, the problem is even easier because you can conceivably ensure that all images are sufficiently different from one another.

If you are building a system that uses hashes that cannot upgrade cleanly when the hash function it is using is compromised, then your system has a serious design problem. Our documentation notes that you should store the algorithm identifier alongside the hash because not doing so is simply wrong, no matter what hash function you are using, visual or otherwise.

VisualID's do have some very nice aspects. I would appreciate hearing your thoughts.

Have you seen RoboHash? It works along the same lines, only with robots.

This is the purpose of the algorithm string. The same algorithm string and data pairing will produce the same images, regardless of Vash's version.

You are quite welcome.

An excellent idea, thank you. I'm always on the lookout for more distinctive shapes to use as inputs and this thread has been most bountiful in that regard.

I've already got an issue in the tracker for that :-). I want to make the full suite of low-level parameters tweakable through a special algorithm string, so that people can make their own unique stylings using Vash's generator, without having to do any coding.

You would need to find a collision in SHA512 and in the Mersenne Twister, at the same time. So no, I don't think so.

Individual bit flips will lead to wildly different images. What's actually going on behind the curtain is: the input data gets run through SHA512, which seeds a Mersenne Twister, which drives a guided random walk over a collection of input nodes to build a tree. Random elements (like position and color) are only a very small part of the algorithm. However, as you note, we really do need more terminal elements, and that is one of the main things I want to do for version 2.

Thank you for that: this is something I had not thought of. I've added an issue to the tracker.

.md is the extension for MarkDown, which github automatically turns into pretty html.

The algorithm string also controls the node frequencies of the guided random walk that builds the function tree. Different algorithm specifiers can give you wildly different looking images. At the moment, it just changes the hash function, but future versions will add new node types and need a way to those parameters to generate backwards-compatible images.

Full disclosure: I am the primary author (probably should have mentioned that before replying to other posts, whoops). I'll be watching the comment stream, if you have any questions.

SSH has been generating random ascii art with ssh-keygen for ages now, using basically the same principle. Besides, for most users, this should be way more secure than throwing a raw hex string at them and expecting them to manually diff it against their paper copy.

It uses SHA512 internally to normalize the input data, so you get all the benefits of a normal hash as well as a pretty image.