Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Graphics Open Source Programming Security

Visual Hash Turns Text Or Data Into Abstract Art 86

Posted by timothy from the picasso-on-security dept.
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."
This discussion has been archived. No new comments can be posted.

Visual Hash Turns Text Or Data Into Abstract Art More

Visual Hash Turns Text Or Data Into Abstract Art

Comments Filter:

  • Obligatory (Score:3, Funny)

    by Anonymous Coward on Friday July 15, 2011 @06:47PM (#36781576)

    Hash turns a lot of things into abstract art.

  • Pretty but... (Score:1)

    by Anonymous Coward

    Is there any way to get the data back out again? or is it for visualization/differentiation?

    • 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,

      • Re:Pretty but... (Score:4, Informative)

        by reiisi ( 1211052 ) on Friday July 15, 2011 @07:23PM (#36781828) Homepage

        (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.

        • I guess that business about short-term memory and age is not just superstition.

          Apologies to anyone who chooses to be offended.

        • (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.

          • Re: (Score:2)

            by reiisi ( 1211052 )

            MarkDown -- okay, I see I need to use github more.

            Might want to give a nod to the node-walk in the readme, and you may want to add sub-parameters, including, not just a set of good node frequencies or other parameters of the node walk, am I making sense?, but also, perhaps, a salt file to help work with short input sets like passwords and passphrases and account numbers and such.

            (Started to add PINs to that list, but now I'm thinking that's a really bad idea. On the other hand, this sort of thing suggests t

            • ... and you may want to add sub-parameters, including, not just a set of good node frequencies or other parameters of the node walk, am I making sense?

              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.

        • (Why the readme file is README.md, I can't guess.)

          http://daringfireball.net/projects/markdown/ [daringfireball.net]

      • Hash does not imply one way. Not all hashes are cryptographically safe. Nor or all hashes guaranteed to be collision free or even resistant.

        I don't think hash means what you think it does.

        • "Hash" the word doesn't imply much of anything; but any function with for which the set of legal inputs is larger than the set of possible outputs must be one-way in general(there may be a number, potentially a very large one, of special cases that are reversible; but it cannot be reversible in general). Most functions described as hash functions fall into that category. They may well have other problems, like making it quite easy to construct inputs that yield a desired output, or having a set of reversibl

  • Fact. (Score:5, Funny)

    by fuzzyfuzzyfungus ( 1223518 ) on Friday July 15, 2011 @06:50PM (#36781602) Journal
    Bruce Schneier just replaced his copy of Photoshop with /dev/random and a copy of Vash...
  • Well, to be secure, you'll want to hash your data with a standard hash algorithm, and then submit the hash to this "vash" thing. Who knows, it might actually be useful, once the actual hashing algorithm is separate from representation.
    • 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.

      • If you can read the code and compile it yourself (and it is short enough to understand, which it may be), you can be pretty sure that it doesn't harvest short inputs and phone home.

        (If it doesn't, that is. I haven't read the source code, yet.)

        Not to say that hashing a hash would necessarily be a bad thing for some applications, for instance, add some time to the brute-force approaches that short input become vulnerable to.

    • 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

      • Re: (Score:1)

        by Anonymous Coward
        (Just to save anybody the trouble of correcting me, it would be the case that the sequence of images thus generated would make brute-forcing the password much easier: If you knew the sequence of N images, with M legal characters for the password, you'd only have to do N rounds of between 1 and M guess-and-checks, rather than between 1 and N^M guess-and-checks... So, it would be grossly unsafe to let an attacker have accurate copies of your image sequence. It would still, though, be substantially less unsafe

        • Given a small enough input set, the output of a normal hash approaches 1-to-1. That is a problem.

          Better, as you say, than what currently exists, but a problem, nonetheless.

          • Not really... When are you relying on collisions to obscure your data?

            • If you hashed each character as it was entered, that would be a pretty serious issue(it would basically just reduce the whole thing to a computationally pathological substitution cipher, which would be pretty pointless); but if you re-hash the entire contents of the password field every time a character is added or removed, you merely(if one can use the word to describe such a gigantic loss...) suffer the loss of complexity from N^M guesses to N rounds of M guesses...

      • Re: (Score:2)

        by reiisi ( 1211052 )

        I'm thinking they'd want to add a different hashing algorithm for short data like passwords and passphrases, and some sort of salt, as well.

        Not ready, as it is, for that application, in spite of the developers suggesting it as a possible application.

        • Can't you add that salt yourself, before passing your data to Vash?

          • Since universal login is all the rage, the salt is going to have to be standardized somehow.

            For applications like universal login, at any rate. (I truly wish the Mozilla group hadn't decided to put that siren in their boat.)

            • Since universal login is all the rage, the salt is going to have to be standardized somehow.

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

  • This is news? (Score:4, Funny)

    by Ellis D. Tripp ( 755736 ) on Friday July 15, 2011 @06:55PM (#36781648) Homepage

    A sufficient quantity of hash will turn ANYTHING into abstract art, no?

  • This would be awesome for validating SSH keys. You could flash up an image instead of:

    RSA key fingerprint is e2:1b:ec:de:3e:72:1a:9a:4e:82:a0:5f:8f:d3:01:af.

    And it would be a much better indicator if the key had changed.

    • Re: (Score:1)

      by Anonymous Coward

      Don't think so. The whole idea of the "visual hash" is to make a long, complicated hash value into something easier to memorize. As a consequence, you're not memorizing the equal of 128bits (or more, for longer hashes) worth of data when you memorize the picture. So brute-forcing a "collision" is much easier to do when you're trying to duplicate a picture than if you were trying to duplicate an exact hash output. You just need something that looks sufficiently like the target image, which won't be nearly as

      • 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.

    • Re: (Score:2)

      by t2t10 ( 1909766 )

      Or you just turn on visual hashs in ssh_config. It's ASCII art instead of color images, but that's because you usually use ssh over consoles.

  • Looks good to me. (Score:3)

    by Ambvai ( 1106941 ) on Friday July 15, 2011 @07:07PM (#36781736)

    Huh. The AACS key in lower case and spaced with colons looks surprisingly nice.

  • Looks quite familiar (Score:3)

    by Qzukk ( 229616 ) on Friday July 15, 2011 @07:24PM (#36781832) Journal

    A lot of the examples look like something off of The Random Art Gallery [random-art.org].

  • I am the author (Score:3, Interesting)

    by terrence2 ( 2376276 ) on Friday July 15, 2011 @07:31PM (#36781892)
    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.

    • How hard is it to found a collision? (Score:1)

      by Anonymous Coward

      Suppose Alice memorizes her server ssh key fingerprint using Vash. How hard is it for an attacker to come up with another key having a _similar_ Vash that can spoff Alice?

      • 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 cryptog

  • No idea how useful it is going to be. One application I can see is feedback whether you typed in the right password/passphrase before it gets stored (to prevent giving one system the password for a different system). A second one is giving feedback about password/passphrase correctness, again before processing.

  • ...is rather fitting.

  • Reminds me of visprint (Score:3)

    by raph ( 3148 ) on Friday July 15, 2011 @07:58PM (#36782064) Homepage

    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.

    • Re: (Score:2)

      by gl4ss ( 559668 )

      your system seems slicker. this is just random shapes and really short hashes produce similar images to really long hashes.

  • looks to be suffering from graphic repetition (Score:3)

    by petsounds ( 593538 ) on Friday July 15, 2011 @08:04PM (#36782096)

    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.

    • After playing around with the "try it yourself" input, it does seem that the generated images differ quite drastically from small changes in the source text. So monitoring changes in keys seems a plausible use.

    • 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.

      • Thanks for the insight into its inner workings. I hadn't read about Mersenne Twisters before.

        What about using diamond-square fractals (e.g. plasma/cloud fractals - http://en.wikipedia.org/wiki/Plasma_fractal [wikipedia.org]) to generate unique terrain? I would think humans might recognize differences in terrain (which our brains have probably evolved to do) more readily than differences in abstract images.

      • Random elements (like position and color) are only a very small part of the algorithm.

        Tell me more of these non deterministic "random" elements; How exactly can you produce a deterministic resulting image?

        Might I suggest you use pseudo-random elements instead? Additionally, I suggest that you take a look at turtle graphics [wikipedia.org] -- You can then easily produce distinct shapes with wildly different "spiro-graph like" images... [wikipedia.org]

        Finally, I would suggest creating many significant improvements and then stopping. You know what makes Cryptographic Hashing functions useful? The fact that, given the

        • Finally, I would suggest creating many significant improvements and then stopping. You know what makes Cryptographic Hashing functions useful? The fact that, given the same inputs, version 0.9alpha and version 99-nonnillion point oh of a SHA-512 implementation will always generate the same results.

          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.

          • 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.

            o_O Stop.

            I'm sorry, perhaps I took the above statement to mean you would, in fact, be changing the output of Vash in a future version...
            Let's face it -- The visuals do need to be improved, do so significantly, then stop.

            Perhaps I'm totally off base here, and the currently released version of Vash isn't actually considered a version that your future versions of Vash will have their output compared against... (In which case I'd like to apologize for our discrepancy in versioning terminologies)

            Alterna

            • 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.

        • Re: (Score:1)

          by KlomDark ( 6370 )

          > ::yawn:: Actually, I'm only posting to remove an accidental "redundant" moderation... Carry on, newb.

          I laughed at your sig, it was funny. Then I realized in your next posting that it wasn't a sig.

          Why do you got to be like that? That was pretty unnecessary. Teach, don't insult. Life is short. // Turtle graphics? LOL, WUT?

    • Re:looks to be suffering from graphic repetition (Score:5, Insightful)

      by fhage ( 596871 ) on Friday July 15, 2011 @09:21PM (#36782434)

      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.

      I agree the images seem unremarkable and not very memorable. How about using the hash to walk the space of facial parameters, generating character faces instead of curves.

      It's amazing how many Mii's one can recognize and remember. Use 2 different hashes and generate a male, female pair.

      • Re: (Score:3, Informative)

        by terrence2 ( 2376276 )

        It's amazing how many Mii's one can recognize and remember. Use 2 different hashes and generate a male, female pair.

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

    • Re: (Score:2)

      by mgiuca ( 1040724 )

      But that's why it's using a cryptographic hash first (SHA-512). The process is text -> SHA-512 hash -> image. Even if the image generation algorithm might only move the flower a little to the left if you change one bit of the hash, it doesn't matter. Because if you change one bit of the text, the hash will completely change, and so will the image. There is no computationally feasible way to change one bit of the hash.

      Yes I realise I am more than a week late in posting this.

  • 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

  • I'll try to put together some specific thoughts on *why* I think VisualIDs did it better, and what the issues with Vash are, in the morning. For the time being, I guess I'll just throw that out there as a conversation-seed and let people Google it....

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

      • Re: (Score:2)

        by Rozzin ( 9910 )
        Part of it is that, going by the examples, this statement in the Vash FAQ is just flat-out wrong:

        How does Vash work for color blind or other visually impaired individuals?

        Despite its visually striking and distinctive impact, color plays only a small role in differentiating between Vash images.

        Rather, it shows that the intent is right but the execution has failed: that no two images are differentiated only by being coloured differently is good, but that the shapes composing a given image are defined ent

  • It's disheartening to see something which I voted down on the Firehose as an obvious slashvertisement appear anyway. Will the "Understanding Mormonism" and link to an ad farm spam show up too?

  • Looks like a Vashslertisement.

Slashdot Top Deals

Pascal is not a high-level language. -- Steven Feiner

Close