Slashdot Mirror
Visual Hash Turns Text Or Data Into Abstract Art
Makoss writes "Normal cryptographic hash functions turn any input text or data into a compact set of bits; useful for computers, not useful for humans. Visual hash functions turn data into graphical representations which are more easily recognizable and memorable to humans. You've seen Identicons and other simple geometric image generators already, but Vash takes the technique beyond basic geometry and produces some really striking images."
Hash turns a lot of things into abstract art.
Bruce Schneier just replaced his copy of Photoshop with /dev/random and a copy of Vash...
A sufficient quantity of hash will turn ANYTHING into abstract art, no?
Remember "News for Nerds, Stuff that Matters"? Help make it a reality again! http://soylentnews.org
Unless the name is grossly misleading, "hash" implies one way, by design.
With a suitably poorly designed hash algorithm, it may be possible to extract certain outputs; but that's a bug, not a feature(also, assuming the hash produces outputs of some limited size and accepts inputs of size bounded only by your computational resources and patience, as they tend to, it is easy to see that it cannot be reversible in general because the set of possible inputs is vastly larger than the set of possible outputs, so it must be the case that multiple inputs map to the same output, so there is no unambiguous "back" for that output...) .
What's too bad is that the system is (comparatively) slow: having a new vash computed on the contents of (say) a password field after each keystroke would make entering passwords under error-prone conditions(such as touchscreen keyboards, or pitiful human weakness) much, much, easier without being nearly as insecure as the prevailing "show the last character entered until you enter the next one" scheme.
Since humans are pretty good at visual recognition, they'd pick up that the picture was 'wrong' after a typo almost immediately; but the shoulder-surfer would learn substantially less than they otherwise would.
Huh. The AACS key in lower case and spaced with colons looks surprisingly nice.
(Why the readme file is README.md, I can't guess.)
After downloading and reading bits of the docs (but not the code), it appears that it hashes the data you give it (SHA-1 or MD5) and builds the graphic based on the hash.
(You specify the hashing algorithm by a parameter, and, no, they don't recommend the parameter that specifies MD5. I didn't read far enough to guess as to why the parameter is not the name of the algorithm.)
So, since it appears that not every geek here is familiar with hashing (Huh?), I'll point out the obvious: The hash does not give enough information to reproduce the original data. (But what about very short inputs, like passwords, which they, erm, suggest?) Also, since the hash is cryptographically hard, reversing it is rather difficult even if you can afford to search through the pseudo-reversion set.
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
A lot of the examples look like something off of The Random Art Gallery.
If I have been able to see further than others, it is because I bought a pair of binoculars.
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.
(Why the readme file is README.md, I can't guess.)
.md is the extension for MarkDown, which github automatically turns into pretty html.
(You specify the hashing algorithm by a parameter, and, no, they don't recommend the parameter that specifies MD5. I didn't read far enough to guess as to why the parameter is not the name of the algorithm.)
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.
I did a couple of things like this back in the mid-90's. One used iterated fractals. I think the original idea was by Ian Goldberg, and I added the coloring.
http://www.tastyrabbit.net/visprint/
But I wasn't satisified by the fact that lots of different hash values produced similar-looking images, so I also cooked up one that had a guarantee that a single-bit change in the hash led to at least a single-bit difference in the image, and came up with these snowflakes:
http://members.shaw.ca/dlakwi/snowflake/snowflake.html
Could be this is a better and slicker implementation than any of this stuff, but the underlying ideas are not quite new.
LILO boot: linux init=/usr/bin/emacs
From a quick look at the example hash images, it looks like the code is just randomly choosing placement, coloring and alpha levels of predefined graphic elements. For instance, almost every image I saw had an image of a flower-like object.
While this does make for unique and more pleasing-to-the-eye images, I doubt that humans would feel confident in picking out their unique hash among similar others. The graphical elements themselves would have to be generated via an algorithm for the images to feel truly unique ("feel" being determined by the limitations of human visual processing and pattern recognition abilities).
One of the potential uses listed on the Vash FAQ is to recognize changes in crytographic keys for security purposes. I don't know enough about how the code generates the images to know whether a minor change in the key would generate a completely different picture, or merely move over the flower a little to the left and change the red to a bit lighter hue. If the latter, most would be hard-pressed to spot any difference at a quick glance.
Perhaps having the algorithm also add a unique animation sequence would help make these visual representations more identifiable to users. If a flower's rotation suddenly goes from 6 RPM to 60 RPM, that would be a much quicker tipoff that something has changed.
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.
Vash makes extensive use of structure, intensity, and position in its image generation. Despite its visually striking and distinctive impact, color plays only a small role in differentiating between Vash images.
Try 3.1415 and 3.1415926535897932
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.