• Create Account

### #ActualVortez

Posted 19 April 2013 - 09:18 AM

You have to keep one thing in mind; it's not the bit length of the hash that is relevant, but the entropy of its source. If the source has less than 32 bits of entropy, then so will the hash. If you take the hash of every character of your password individually to get a set of keys, then each key has no more than 6 bits of entropy even if you calculate a 32-bit hash from it, since those 6 bits can only possibly generate 64 of the roughly 4.2 billion possible 32-bit hashes. One possible idea here could be to split the password into sets of 6 characters (6 characters then providing 36 bits, just above 32-bits for a hash), and do as many passes as you have 6-character sets.

Yea, i agree this should be improved, i wrote this thing in a day, about a year ago, so i might need to fiddle with it a little more. And the only 2 things i could think of to use it would be for files and network encryption.

And thx for the link Alvaro.

Here's the examples pics i was talking about:

This is the original image

This is the encrypted image using my old code (this is the best i could get before, and the first version was wayyy worst)

And this is the encrypted one using the new algo descripted above

hehe you could see the patern in the old code pretty well, at the time i tough it was fine... until i checked it out this way.

Still pretty good for something home made i guess.

### #7Vortez

Posted 19 April 2013 - 09:03 AM

You have to keep one thing in mind; it's not the bit length of the hash that is relevant, but the entropy of its source. If the source has less than 32 bits of entropy, then so will the hash. If you take the hash of every character of your password individually to get a set of keys, then each key has no more than 6 bits of entropy even if you calculate a 32-bit hash from it, since those 6 bits can only possibly generate 64 of the roughly 4.2 billion possible 32-bit hashes. One possible idea here could be to split the password into sets of 6 characters (6 characters then providing 36 bits, just above 32-bits for a hash), and do as many passes as you have 6-character sets.

Yea, i agree this should be improved, i wrote this thing in a day, about a year ago, so i might need to fiddle with it a little more. And the only 2 things i could think of to use it would be for files and network encryption.

And thx for the link Alvaro.

Here's the examples pics i was talking about:

This is the original image

This is the encrypted image using my old code (this is the best i could get before, and the first version was wayyy worst)

And this is the encrypted one using the new algo descripted above

Still pretty good for something home made i guess.

hehe you could see the patern in the old code pretty well, at the time i tough it was fine... until i checked it out this way.

### #6Vortez

Posted 19 April 2013 - 09:03 AM

You have to keep one thing in mind; it's not the bit length of the hash that is relevant, but the entropy of its source. If the source has less than 32 bits of entropy, then so will the hash. If you take the hash of every character of your password individually to get a set of keys, then each key has no more than 6 bits of entropy even if you calculate a 32-bit hash from it, since those 6 bits can only possibly generate 64 of the roughly 4.2 billion possible 32-bit hashes. One possible idea here could be to split the password into sets of 6 characters (6 characters then providing 36 bits, just above 32-bits for a hash), and do as many passes as you have 6-character sets.

Yea, i agree this should be improved, i wrote this thing in a day, about a year ago, so i might need to fiddle with it a little more. And the only 2 things i could think of to use it would be for files and network encryption.

And thx for the link Alvaro.

Here's the examples pics i was talking about:

This is the original image

This is the encrypted image using my old code (this is the best i could get before, and the first version was wayyy worst)

And this is the encrypted one using the new algo descripted above

Still pretty good for something home made i guess.

hehe you could see the patern in the old code pretty well, at the time i tough it was good... until i checked it out this way.

### #5Vortez

Posted 19 April 2013 - 09:01 AM

You have to keep one thing in mind; it's not the bit length of the hash that is relevant, but the entropy of its source. If the source has less than 32 bits of entropy, then so will the hash. If you take the hash of every character of your password individually to get a set of keys, then each key has no more than 6 bits of entropy even if you calculate a 32-bit hash from it, since those 6 bits can only possibly generate 64 of the roughly 4.2 billion possible 32-bit hashes. One possible idea here could be to split the password into sets of 6 characters (6 characters then providing 36 bits, just above 32-bits for a hash), and do as many passes as you have 6-character sets.

Yea, i agree this should be improved, i wrote this thing in a day, about a year ago, so i might need to fiddle with it a little more. And the only 2 things i could think of to use it would be for files and network encryption.

And thx for the link Alvaro.

Here's the examples pics i was talking about:

This is the original image

This is the encrypted image using my old code (this is the best i could get before, and the first version was wayyy worst)

And this is the encrypted one using the new algo descripted above

Still pretty good for something home made i guess.

### #4Vortez

Posted 19 April 2013 - 09:00 AM

You have to keep one thing in mind; it's not the bit length of the hash that is relevant, but the entropy of its source. If the source has less than 32 bits of entropy, then so will the hash. If you take the hash of every character of your password individually to get a set of keys, then each key has no more than 6 bits of entropy even if you calculate a 32-bit hash from it, since those 6 bits can only possibly generate 64 of the roughly 4.2 billion possible 32-bit hashes. One possible idea here could be to split the password into sets of 6 characters (6 characters then providing 36 bits, just above 32-bits for a hash), and do as many passes as you have 6-character sets.

Yea, i agree this should be improved, i wrote this thing in a day, about a year ago, so i might need to fiddle with it a little more. And the only 2 things i could think of to use it would be for files and network encryption.

And thx for the link Alvaro.

Here's the examples pics i was talking about:

This is the original image

This is the encrypted image using my old code (this is the best i could get before)

And this is the encrypted one using the new algo descripted above

Still pretty good for something home made i guess.

### #3Vortez

Posted 19 April 2013 - 09:00 AM

You have to keep one thing in mind; it's not the bit length of the hash that is relevant, but the entropy of its source. If the source has less than 32 bits of entropy, then so will the hash. If you take the hash of every character of your password individually to get a set of keys, then each key has no more than 6 bits of entropy even if you calculate a 32-bit hash from it, since those 6 bits can only possibly generate 64 of the roughly 4.2 billion possible 32-bit hashes. One possible idea here could be to split the password into sets of 6 characters (6 characters then providing 36 bits, just above 32-bits for a hash), and do as many passes as you have 6-character sets.

Yea, i agree this should be improved, i wrote this thing in a day, about a year ago, so i might need to fiddle with it a little more. And the only 2 things i could think of to use it would be for files and network encryption.

And thx for the link Alvaro.

Here's the examples pics i was talking about:

This is the original image

This is the encrypted image using my old code

And this is the encrypted one using the new algo descripted above

Still pretty good for something home made i guess.

PARTNERS