Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bruteforcing the Devil

blog.passcod.name

Post reply on HN
Print view View original

21–29 of 29 posts

Re: Bruteforcing the Devil

#21

Post by lunixbochs »

pedrox wrote: post #19

This hash is very weak. You can actually find many preimages of a given hash value in seconds with a meet-in-the-middle attack: https://gist.github.com/pedrox/eb8d674bf2b8be63da0f

You can brute force it insanely fast by iterating from the rightmost character and caching the entire hash prefix.

This hash doesn't scramble input very well, so you can fiddle with individual characters to converge on any desired hash value.

Record the "closest" hash value to your target generated by this loop, apply (only) that character change, repeat. If the hash value stops converging, add a character. This naive version pretty often does the job in 5 full iterations or so, which means (5 * len(s) * len(alphabet)) = maybe ~3000 total hashes to get a solution.

    for i in xrange(len(s)):
        copy = s
        for c in alphabet:
            copy[i] = c
            diff = abs(hash(copy) - 666)
            best = min(diff, best)

Re: Bruteforcing the Devil

#22

Post by pedrox »

pedrox wrote: post #19

This hash is very weak. You can actually find many preimages of a given hash value in seconds with a meet-in-the-middle attack: https://gist.github.com/pedrox/eb8d674bf2b8be63da0f

Also, this hash function is linear so it has the equivalent substrings property. One can take advantage of it and be able to generate preimages even faster. Take a preimage and find m equivalent strings for n substrings of it. Replacing the substring with their equivalent will get you n to the m-th preimages that hash to the same value.

Re: Bruteforcing the Devil

#23

Post by passcod »

panarky wrote: post #20

I’m half tempted to buy a few hours of highcpu AWS compute power and get it done nowish instead ... I set myself a $50 spending limit, which gave me about 24 hours of compute on an instance with 32 virtual cores The price of a c3.8xlarge with 32 cores and 60 GB is currently $0.28 in us-west-2. You could get 178 hours of compute for your $50 budget.

This is for a spot instance, which could get stopped at any moment if the spot price increases, and that would be pretty bad for that task as I could lose computation results. The on-demand price is about $1.60 an hour. But wait! I'm not using the same dollar, I live in New Zealand, which makes that about NZ$1.90 an hour, or NZ$45 for 24 hours.

Re: Bruteforcing the Devil

#24

Post by passcod »

foxhill wrote: post #18

i was intrigued by this, so i done it in C. on my 4-core MBP (2.6ghz ivy bridge) i can manage ~1.8 billion hashes per second. i could parallelize with OpenCL, but i think this is enough. after a few minutes, i get ARbyhlf as a valid name (although i don't know if this is actually valid.. but it definitely might be) (removed) edit: just realised that my nonce calculation was wrong.. http://pastebin.com/bcHcECPJ

Most of the time is spent on generating the random string, which was because I very quickly realised looking through the entire possibility space in order would be unproductive. Granted, my entire approach was unproductive, as shown by linuxbochs, pedrox, and others below :)

I actually did some micro-benchmarking in the midst of all that and found that hashing a single, static, string took something of the order of 20ns. That's half a billion hashes per second, or 2 billion on four cores. Add a little overhead for string generation, and yeah, we get the same number.

Re: Bruteforcing the Devil

#25

Post by passcod »

lunixbochs wrote: post #12

I came up with a mutation-based solution to this. Supply any string and it finds a valid hash in as few edits as possible. Example: http://bochs.info/img/mutation-20140606-024906.png One could definitely optimize this to be less destructive and produce more pronounceable results. It's basically two pieces: an engine for suggesting mutations, and a simple algorithm to score and pick mutations. Changes to either half (…

When Pfiffer told me peh would post that on HN, my reaction was something like "Fine by me, but I'm pretty sure I'm going to get schooled." Looks like I was right.

I got schooled, I'm learning, next time I'll be more clever about it, thank you!

Re: Bruteforcing the Devil

#26

Post by foxhill »

passcod wrote: post #24
foxhill wrote: post #18

i was intrigued by this, so i done it in C. on my 4-core MBP (2.6ghz ivy bridge) i can manage ~1.8 billion hashes per second. i could parallelize with OpenCL, but i think this is enough. after a few minutes, i get ARbyhlf as a valid name (although i don't know if this is actually valid.. but it definitely might be) (removed) edit: just realised that my nonce calculation was wrong.. http://pastebin.com/bcHcECPJ

Most of the time is spent on generating the random string, which was because I very quickly realised looking through the entire possibility space in order would be unproductive. Granted, my entire approach was unproductive, as shown by linuxbochs, pedrox, and others below :) I actually did some micro-benchmarking in the midst of all that and found that hashing a single, static, string took something of the order of 2…

> Most of the time is spent on generating the random string

when i took out string generation, i went from 1.2 GH/s to 1.8GH/s (although, i'm assuming my string generation was much simpler)

> I very quickly realised looking through the entire possibility space in order would be unproductive

you say that, but it's not as unproductive as you might think. assuming the hash function is uniformly distributed (hah), there are 4 billion hash values that could result from a string. if we can check 2 billion a second, we should see a result every few seconds. maybe my search space pruning was particularly bad, because i see on average ~4-10 a minute, and they are usually quite clustered together. this suggests the hash is not uniformly distributed (although a cursory glance at the function should make it obvious to people with a maths background).

anyways, it was good fun to poke around :) cheers for sharing!

Re: Bruteforcing the Devil

#27

Post by gone35 »

na85 wrote: post #6

Aw guys, don't go start posting on their site (which I won't link) with devil names. Everyone knows communities turn to shit when they get too big and 300 different users posting all with blank icons is going to kill the fun for them. I'm not even a member of Merveilles but that makes me sad for them.

Well; for what ostensibly is a secretive, millenial "circle of artists and wizards"; that is an awfully non-cryptographic, weak hash function. Apparently (variants thereof) are commonly used in some JavaScript circles to mimic a popular implementation of Java's String.hashCode() method [1,2,3].

[1] http://werxltd.com/wp/2010/05/13/javascript-implementation-o...

[2] http://stackoverflow.com/questions/6122571/simple-non-secure...

[3] http://en.wikipedia.org/wiki/Java_hashCode()

Re: Bruteforcing the Devil

#28

Post by makoConstruct »

gone35 wrote: post #27
na85 wrote: post #6

Aw guys, don't go start posting on their site (which I won't link) with devil names. Everyone knows communities turn to shit when they get too big and 300 different users posting all with blank icons is going to kill the fun for them. I'm not even a member of Merveilles but that makes me sad for them.

Well; for what ostensibly is a secretive, millenial "circle of artists and wizards"; that is an awfully non-cryptographic, weak hash function. Apparently (variants thereof) are commonly used in some JavaScript circles to mimic a popular implementation of Java's String.hashCode() method [1,2,3]. [1] http://werxltd.com/wp/2010/05/13/javascript-implementation-o... [2] http://stackoverflow.com/questions/6122571/simple-no…

You expected something more esoteric? I think it's a matter of perspective. Sure, as a crypto challenge, it's weak. But if you think of it as our standard UI for configuring one's user icon...
Post reply on HN