PHP-SHA1 Crack Notice. - Page 2

[digital-ether]

But hashes are ONE WAY FUNCTIONS!

Trivial example - the hash function is strlen().
That means the hash of "SEND ONE DOLLAR" and "SEND 1M DOLLARS" are the same. But there is zero information in the hash result to tell you which one it was.

The hash of an entire book (say war and peace) would still only be 40 characters. Are you seriously thinking you could recover the entire book? Who needs ZIP, when we've got your reversible hash.

Now SHA1 is more secure, because there is a lot less chance of getting the same result from any given two messages.
It is also more secure, because it is hard to arrange for a particular message to have a particular SHA1 result.

You can't get back the original text just by "reversing" the process, even if you could.

Read Bruce Schneier's post from 5 YEARS AGO.
If you've only managed a couple of rounds, are you doing anything which isn't just brute force (or something slightly less expensive).

Sha512. That's a great algorithm to crack. But sha1 first.
As for about how bytes are lost and removed, I have created algorithms that generates those bytes from existing data. That is a very simple and effective concept. Got me very far until I came across this one variable which I will need to write a big algorithm for. So when you think about it I am like Macgyver and Neo combined. I see everything as a matrix and use existing items to solve the hardest problems. With that concept in mind I should be able to crack this layer of sha1 and possibly the entire algorithm.

Wow...

[JRM]

Although I'm ignorant about cryptology that sounds very logical.
But how comes Even 100 characters long produce 40 Hash character. It kinda abracadabra doesn't it?

Not really. It's just a 'hash" of the original input string. The string is not "recoverable " from the hash. The original information is actually lost. However, the same hash is produced for a given input. When you make the encrypted password the first time , it is stored in the database. When you log in, you produce the hash once again and compare that with what was stored. The original information is only relevant in the hash sum that is created from it.

Think of it like a 40 bit shift register that you can shift any number of bit sequences though it, but you only have 40 represented no matter what.
( I don't mean to imply that this how sha1 works, but just an analogy of how to boil 100 down to 40)

[Salem]

If you want to find out if your technique is any good, then post your description on one of the main sci.crypt newsgroups.
http://en.wikipedia.org/wiki/Cryptography_newsgroups

[JRM]

If you want to find out if your technique is any good, then post your description on one of the main sci.crypt newsgroups.
http://en.wikipedia.org/wiki/Cryptography_newsgroups

Yes, that would be the appropriate forum for the "SHA1 crack notice".
I bet he would get some very valuable feedback from them.

[cwarn23]

The only way you can possibly make a hash undecryptable is by appending a string with a character repeated by 2^40 times to the hash input. Then it would take 2TB of memory to decode.

[liamfriel]

What do you mean by "run a muck"? I thought it would be wise.

It was wise of you to let us know - but not everyone on this site is wise.... or nice!

Gratz on nearly cracking it though

[Fest3er]

But hashes are ONE WAY FUNCTIONS! ... You can't get back the original text just by "reversing" the process, even if you could. ...

One other item to note concerning when hashes are used to store passwords. One doesn't need the original password. One only needs a short-ish string of typeable characters that yield the same hash. You'll recall that that is pretty much what doomed md5sum: theoretical proof that two different sources texts could yield the same hash.

Come to think of it, the OP could verify his method by attacking MD5 first, as a proof-of-concept.

[cwarn23]

Come to think of it, the OP could verify his method by attacking MD5 first, as a proof-of-concept.

Why is attempting to dehash md5 any different then attempting to dehash sha1? Sure they have different algorithms but they are both based on the same principles. Anyways it was all going good until I came across this one mathematical problem. It involves predicting future loop rounds based on data in the current loop round. Currently my mind is going loopy but I will get there eventually and if/when I do it will be a major breakthrough in computer science as no-one has ever been able to solve this loop puzzle before. That is why this loop puzzle is included in many hashing algorithms. Example of the theory

a=1
b=47
c=88
tmp=23
for(i=0;i<80;i++) {
tmp=tmp+a+b+c+random_number
b=a
c=b
a=tmp
tmp=c
}

And in that code you need to find the value of random_number in each loop round then place it into an array[80]; So far I managed to replicate all of the variables except "a". The variable a is the previous tmp. So I will setup a challenge and that is can anybody reverse the process in the above code (c++ or php) and to reverse it you need to find all 80 values of random_number.

[Fest3er]

Why is attempting to dehash md5 any different then attempting to dehash sha1?

MD5 was shown, some years ago, to be somewhat more susceptible to hash collisions. That's why its use in tighter security situations is deprecated. So it should be easier to 'crack' MD5 than SHA1.

If your goal is to obtain the original cleartext, I believe you will fail. But if you are trying to find any reasonable cleartext that will result in the same hash, I think you may find a modicum of success.

That said, carry on! This is how knowledge is advanced.

[cwarn23]

After many weeks of studying and attempting to reverse the sha1 algorithm I have come to the following conclusion:

The Sha1 algorithm cannot be reversed due to the use of it's binary operators. If the binary operators were all reversible then the sha1 would too be reversible.

[Stefano Mtangoo]

After many weeks of studying and attempting to reverse the sha1 algorithm I have come to the following conclusion:

I hope you have got great experince while jumping the hoops.

[tubthumper]

You seem to forget the fact that a smart developer adds security measures to prevent crack attempts from shallow developers like you.
SHA1 is a 160-bit one-way encryption algorithm, so the end result is always 160 bits. If you make the input longer than 160 bits, you've made the hash dramatically more secure. I generally try to make mine 3~4 times the length of the resulting digest.
You've failed.
Let's see you crack this:
I append
'fahrpghuerigh;4A$FE%gERGSUGI%PFH%FAHgfuoaghfu4.fgrvhjkhjzdfgvo8et7rfgAA$F*YROAGSY?R*OSGSERGJAIRgf'
before the string and
'hfphgasp9rhy4GFRG(GUZ%IJGJ%VW%G@$GT^$@*%)%@*!@%hf87ohs780erhss805ryg7u5sgwh54fqhj,fgq4f'
after the string. Well, my input has now become
'fahrpghuerigh;4A$FE%gERGSUGI%PFH%FAHgfuoaghfu4.fgrvhjkhjzdfgvo8et7rfgAA$F*YROAGSY?R*OSGSERGJAIRgfBLABLABLABLABLAhfphgasp9rhy4GFRG(GUZ%IJGJ%VW%G@$GT^$@*%)%@*!@%hf87ohs780erhss805ryg7u5sgwh54fqhj,fgq4f'
Good luck attempting to create a collision as well, since you have to consider the prepended and appended strings.
Essentially, your menial efforts to attempt to prove SHA1 insecure have been thwarted.
I hope you enjoyed your wasted time.

[cwarn23]

I have a theory on how to crack sha1 but it will take 5 years of new computer technology before I can apply this theory. This theory is based on the IBM guess and go devision theory. It would require 64GB of ram and 2TB of diskspace. With the IBM guess and go theory of division it can also be applied to other operators such as reversing 2+2=4 reverses to 4=2+2 && 4=3+1 && 4=4+0. Then can be filtered by checking if it is comparable with the next irritation. So that would crack the first 80 irritations of the sha1 algorithm getting the word[] array which would then be processed by the next loop. But I will need to wait for computers with 64GB of ram to become publicly available.

You seem to forget the fact that a smart developer adds security measures to prevent crack attempts from shallow developers like you.
SHA1 is a 160-bit one-way encryption algorithm, so the end result is always 160 bits. If you make the input longer than 160 bits, you've made the hash dramatically more secure. I generally try to make mine 3~4 times the length of the resulting digest.
You've failed.
Let's see you crack this:
I append
'fahrpghuerigh;4A$FE%gERGSUGI%PFH%FAHgfuoaghfu4.fgrvhjkhjzdfgvo8et7rfgAA$F*YROAGSY?R*OSGSERGJAIRgf'
before the string and
'hfphgasp9rhy4GFRG(GUZ%IJGJ%VW%G@$GT^$@*%)%@*!@%hf87ohs780erhss805ryg7u5sgwh54fqhj,fgq4f'
after the string. Well, my input has now become
'fahrpghuerigh;4A$FE%gERGSUGI%PFH%FAHgfuoaghfu4.fgrvhjkhjzdfgvo8et7rfgAA$F*YROAGSY?R*OSGSERGJAIRgfBLABLABLABLABLAhfphgasp9rhy4GFRG(GUZ%IJGJ%VW%G@$GT^$@*%)%@*!@%hf87ohs780erhss805ryg7u5sgwh54fqhj,fgq4f'
Good luck attempting to create a collision as well, since you have to consider the prepended and appended strings.
Essentially, your menial efforts to attempt to prove SHA1 insecure have been thwarted.
I hope you enjoyed your wasted time.

[Stefano Mtangoo]

Boy! I thought you have given up!

[cwarn23]

Boy! I thought you have given up!

I have for the next 7 or so years until hardware technology advances.