Welcome to HBH! If you have tried to register and didn't get a verification email, please using the following link to resend the verification email.

Uncrackable Encryption?


Uncrackable Encryption?

By bl4ckc4t avatarbl4ckc4t | 8908 Reads |
0     0

I know, I know, no encryption is uncrackable. But this one is going to be harder than any to crack. I spent several hours thinking of ways to make it harder for us to crack into a website. It would be harder even if we had access to the bakups.

The concept is, stack encryption algorithms on top of each other, forming them into one, causing one encryption that will take decades to crack even if it is a 3 letter password.

SHA-1 is 160 bit encryption. MD5 is 128 bit encryption.

For now, MD5 is most used, but easiest to crack.

Heres the code for the index.php or html, whichever you prefer:

Heres the login.php:

You see it starts by getting the user and pass. It then uses SHA-1 to hash the user and password separately. It then creates a hash of the login.php. After all these hashes have been generated, it then uses them as salts on top of each other to double dutch them

into an MD5 hash.

Lets calculate that: 2 beginning sets of SHA-1 Thats 360 bits add the digital checksum of the login.php 540 bits

take that 540 times another 180 bits 97,200 bits times the 128 bit encryption of MD5 12,441,600 bits TOTAL.

Thats a lot of bits. Even the NSA wouldn't be able to crack that without a few decades work. I would have to say

it would be illegal in a lot of the world but it will be damn secure ;)

Say someone got your backups. The hash they get is double dutched with MD5 on top, they would have to wait for

it to crack- showing an SHA-1 hash. They begin cracking the SHA-1 hash. OH LOOK! 3 more SHA hashes to crack.

As we all know, brute forcing a password over 6 characters is a pain. try brute forcing that double dutch

rendering the MD5 into 40 characters. That in turn is 120 char + a couple of periods. The login.php hash will

have a lot of char in it if someone doesn't know which is which. the username can have alot of char, if the

person is smart, the pass will be at least 8 characters.

What do you all think?

Bl4ckC4t

Comments
ghost's avatar
ghost 18 years ago

Correct me if I'm wrong but aren't hashes unique only up to a certain amount of digits? This way a hash of a 500 word string could be the same of the hash of a 4 digit string..

ghost's avatar
ghost 18 years ago

Erm, gut instint here but wouldn't piling hashs on top of each other increase incidence of collisions? let me work it out and ill get back to you

ghost's avatar
ghost 18 years ago

Okay say you can only have 100 posible hashs, so you have 100 results, you hash them and some of them may hash to the same thing, so say you know have 50 possibilities, but if you hash them you may end up with some of he ones you droped earlier (they hash to the same thing) and you end up with less hashs, pressumably it will eventually end up with 0 hashs and so infinate collisions, im not sure if this is 100% true maybe it platues at some point

ghost's avatar
ghost 18 years ago

It would be INSANE to brute it… BUT the collision algorithm would perform even better than it usually does because u stacked alot of encryption ontop of each other.

bl4ckc4t's avatar
bl4ckc4t 18 years ago

Yea, I didnt take into account the collision possibility. Although, the collisions wouldnt be as bad (i believe) if you changed the double dutch to go into SHA-1 over MD5. It would probably cut the collision rate in half.

Bl4ckC4t

ghost's avatar
ghost 18 years ago

For the algorythme I don't think using sha1_file is a good idea. Imagine you change just a caracter in this file and all your hash can't no longer be used except if you have a backup of that file … For the method in itself i think using random salt for each password is way much better in security, except if someone find where you stock your salt for the password.

bl4ckc4t's avatar
bl4ckc4t 18 years ago

Your encrypting the login page. Not very many people change the login page, its the least risk for screwing it up.

ghost's avatar
ghost 18 years ago

I would also like to add that it doesn't matter how much you encrypt it when your code is exposed. It's not that hard to write a brute forcer for double dutch or something similar.

ghost's avatar
ghost 18 years ago

There is a uncrackable encryption :) its called randomized one time pad. But the cons are that it requires a unique key and a key with an equal length to the tobecipherd text. google it :)

ghost's avatar
ghost 18 years ago

Wippi! That rocked (:

Thanks dude.

ghost's avatar
ghost 18 years ago

Wippi! That rocked (:

Thanks dude.

ghost's avatar
ghost 17 years ago

Zarray: "There is a uncrackable encryption its called randomized one time pad. But the cons are that it requires a unique key and a key with an equal length to the tobecipherd text. google it"

yes but it'd be useless for this, since the key would need to be transfered over the internet, and someone could probably be able to see it (the key has to remain a secret obviously).

j4m32's avatar
j4m32 13 years ago

@revolt0163 : Not necessarily, in the case of a server side script demonstrated (PHP), just store it server side since the client doesn't need to decode it, no "transfer" across the internet is required for that. Store the cyphertext in a session or a cookie… the key can be kept pretty much private.

If you were one time padding the request data: yes this would be the case.

ghost's avatar
ghost 13 years ago

  1. You mean, sha1(x) is less secure than sha1(sha1(s))?

  2. By first applying sha1 you compress the input and therefor reduce the entropy. Then, you reduce is further by using md5 (128 bit).

  3. As already said, your salt is too static ;)

ic0ns's avatar
ic0ns 13 years ago

this encryption is barely better than normal sha1, u got it wrong with Kerckhoffs's Principle.

Imagine the Attacker knows your Cryptosystem. The attacker uses the same method you use to check if the password ist correct after the login.

The Username ist public, and the hash of the loginscript is public so the only left unknown parameter is the password, u bruteforce the password using your formula for verification , … , profit