2

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

Romario
  • 21
  • 1
  • 1
    What makes you believe Skein is not secure enough for your purposes? More isn't always better in terms of security (and can, in specific cases, actually be worse), and in general there is a practical limit, in that throwing more iterations/cascades essentially changes nothing. Note, though, that if done properly, you can combine hash functions into something "better", but it's often not really elegant nor efficient. Also, if CPU cycles do not matter at all, I suggest iterating Skein an infinite number of times :-) – Thomas Sep 08 '12 at 14:14
  • 3
    Have a look at a similar question by me – Guarding against cryptanalytic breakthroughs: combining multiple hash functions. – Paŭlo Ebermann Sep 08 '12 at 14:31
  • 1
    @Thomas, Well in my case, I would like to come up with my two combine hash functions to protect a certain document's data integrity that I have. And of course, I want this protection to last for the next few years, So I decided to choose to combine two of SHA-3 candidates, Any suggestions? – Romario Sep 08 '12 at 14:46
  • 1
    @Paulo, I already read your question more than one time, but all the researches involved before SHA-3 algorithms, So Does this apply to SHA-3 candidates also? – Romario Sep 08 '12 at 14:49
  • 1
    What are you using the hash function for? Only integrity checking? Then concatenating the hashes should work. (Obviously makes the hash longer) – CodesInChaos Sep 08 '12 at 15:17
  • 1
    I don't think there really is a difference here between combining the SHA-3 candidates and combining other hash functions (maybe other than when combining functions which are somehow similar to each other such that their security cancels each other out – but this obviously also depends on the combination mode.) – Paŭlo Ebermann Sep 08 '12 at 20:14

1 Answers1

6

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.

KeithS
  • 540
  • 1
  • 3
  • 11
  • The output encoding is independent of the hash function – you can use Base64 for SHA-256 as well as hex encoding for bcrypt or the other way around, or you can store both directly as bytes. Second, bcrypt and other slow hashes are meant for another goal than fast (secure) hashes, namely for hashing low entropy information and making brute forcing hard. Bcrypt is not a general-purpose hash. – Paŭlo Ebermann Oct 28 '12 at 13:38