For example, Is possible to combine (Concatenate or Chain or XOR) Skein SHA-3 candidate with Grostl SHA-3 candidate to increase security?
Note: I just want more secure output and CPU cycles does not matter
|show 1 more comment|
The basic problem with combining primitives in a hashing or encryption function is that when doing so, you have to be sure that the combination doesn't expose some weakness. When talking about hashing, the three main desirable qualities are one-way transformation (absolutely critical), even distribution (after hashing a sufficiently large number of messages and plotting a histogram of the hash values, you would expect all buckets of the histogram to be equal), and high avalanche effect (related to randomness, adding or changing a single bit in the message should produce a massive and theoretically unpredictable change to the hash value).
When coming up with a hash algorithm, designers combine primitives in such a way that they can mathematically or empirically demonstrate the relative level of strength in these three areas. Conversely, third parties can demonstrate weaknesses in these areas. For a simple example, take the original FNV-1 checksum hash; for each byte of input, the working hash is multiplied by the FNV prime and then XORed with the input byte. People using it found that while it worked well for checksums, if these two operations were reversed, the algorithm exhibited much better avalanche characteristics and more even distribution, leading to the commonly-used "FNV-1a" variant described in the whitepaper.
By combining hash algorithms in a particular order, you may or may not create a stronger algorithm. You may increase the one-wayness of the algorithm, but conversely you may at the same time reduce the set of possible hashes (either by hashing a hash into a lower-bit output or reducing the distribution of hash values within an absolute range). The same applies to performing primitives of a hashing function in differing order, as evidenced by the above example.
Lastly, the combination of primitives you chose may induce a weakness; neither FNV-1 nor 1a are crypto hashes for many reasons, one of them being that regardless of which way you perform the primitives, the least significant byte is always the XOR of all input bytes each XORed with 1. That reduces the set of all possible collisions with a particular hash by half; a cracking algorithm could very quickly spin through this "carry XOR (lsb XOR 1)" sequence to determine that a candidate message won't work. By doing so you effectively reduce the complexity of brute-forcing a collision with the given hash by a power of 2, thus breaking "strong collision resistance". If a crypto hash had this weakness it would be considered broken.
If you want a secure hash, consider bcrypt. First off, bcrypts are relatively small to store as strings since they're Base64-encoded (60 chars/bytes, vs 64 for a hex-encoded 256-bit hash), but they store as much entropy as a 256-bit hash. Second, not only is bcrypt slow, it's configurably slow, by increasing the number of steps for a key initial stage of hash generation by powers of two. Thus, the algorithm can easily be adapted to keep up with Moore's law; every year and a half, you just increment the complexity of the hash and presto, it takes twice as long to brute-force the hash, offsetting the empirical doubling of processing power during that time.