Optimize generation

[Spudinski]

Re: Optimize generation

Nyna,

Although I get your point here, I just want to say a few things.

SHA1 isn't that new, neither MD5, they have been used evectivley for a couple of years now.

But not so long ago, researchers found a flaw in the md5 algorithm, like two files could have the same md5 checksum.

MD5 is just a very popular encryption, meaning that rainbow tables for it is very popular, but hte truth is that there are many SHA1 and SHA128 rainbow tables.

Any further than that is used for files, or large quantities of data.

With most of the applications I'm building now, I use very high encryption, the encryptions as the NSA, FBI, and even the military.

They use encryptions such as Blowfish, Twofish and AES(Rijndael), it requires that you specify a key to encrypt and decrypt the data.

That means that even if a malicious hacker gets hold of your encrypted passwords, they will not be able to do anything with it.

[Floydian]

Re: Optimize generation

spudinski, spudinski, ALL hashing methods suffer from collisions... Whether or not we have found ways to cause them is of now importance. I don't care if your hash produces a 1 million character string, there will still be collisions.

[Spudinski]

Re: Optimize generation

Actually, the only ever successful attacks on AES was side-channel attacks.

Without the key, any form of data encrypted with AES or Twofish (etc.) is nothing.

If I have the wrong definition of collisions, pelase correct me.

I'm not trying to implicate anyone here, and so I stand under correction.

[Floydian]

Re: Optimize generation

When you are speaking of "keys" you are speaking of encryption which is different that a hash. A hash is a message digest and no matter what data you hash, you always get the same message digest every time you hash the same data.

Encryption on the other hand does not have that problem. Using a key, you change the encrypted string from what it would be with a different key to what it is with the key your using.

Encryption differs from hashing also, in that when data is encrypted it's possible to use the key to unlock that information as opposed to a message digest which there is no key for and no *simple* method of decoding it.

For any message digest that is generated, there would be more than one data set that the generated hash could have been generated from. Therefore a collision is when more than one data set can produce the same hash. And since there is an infinite amount of data combinations possible, and only a finite number of message digests for any hash method known, any genuine method of breaking a hash would allow you to find an infinite number of data sets that would fit the hash ;)

Collisions occur in hashes, but not in encryption. At least, if they do occur with encryption, it would be far far more rare and that just doesn't seem possible because unlocking the encryption would result in more than one unlocked set of data.

The thing about encryption is that for any encrypted string, there would be more than one possible data set that that encrypted string could have resulted from. However, the introduction of the key dramatically increases the number of possible combinations of data set and keys. The key is not limited in size and therefore makes collisions in encrypted strings theoretically impossible.

It should be noted that for any encrypted string, there would be more than one key that could unlock the data, however the resulting data set would be different depending upon what key you used. That means that the data that is encrypted would only be obtained by having the key ;) Otherwise, you would end of with meaningless data!

For this reason, hashes are used a lot for passwords because you hash the pass and compare the stored hash with the hash produced from the submitted pass. You could just as well use encryption and compare encrypted strings stored in a database with submitted passwords that are encrypted, but collisions would occur there because you aren't attempting to decrypt the encrypted string, but merely comparing encrypted strings and there are only a finite number of encrypted strings when the encrypted string is of a known length.

[Spudinski]

Re: Optimize generation

Differnet hashing functions have different digest sizes.

But I can see your point, no matter how long or short an hash is, it can be compared with another.