In aide the author offers more than one hash algorithm to do the check-sum, why is that?

Aren't a single one, i.e sha512 enough for determining file changes? I believe these algorithms are all testified in mathematical area, shouldn't be a problem here, am I wrong?

2 Answers 2


There is little reason to use more than one hash at the same time. There are no known collisions against SHA-2. In theory using several at the same time can be an insurance against attacks on the hash function, but I don't think that's a big issue for AIDE.

But allowing choice can be useful. The current default might get broken at some point. Once that happens switching the hash in a config file is easier than rolling out a new version of the software.

Hashes also have different performance characteristics. For example SHA-256 is faster than SHA-512 on 32 bit systems, but slower on 64 bit systems. So you might want to choose the one that matches your CPU architecture.
Or if you need high performance(for example you use SSD RAIDs) you can use faster hashes that aren't approved by NIST.

  • 1
    Agreed - I think OP's confusion was between using multiple hashes at the same time vs. having a choice of hash.
    – Polynomial
    Commented Jan 3, 2013 at 15:52
  • 2
    @Polynomial I think the software supports that as well. One of the examples combines MD5 and SHA1. Which IMO is a dumb choice, I'd take a single SHA-2 hash over that any time. Commented Jan 3, 2013 at 15:56

To add some information over @CodesInChaos's good answer:

Using several hashes simultaneously has been suggested as a way to cope with future weaknesses of hash functions. For instance, you hash with MD5 and with SHA-1, so that your system remains robust even if one of them gets broken (regardless of which is broken). This is equivalent to defining a new hash function (let's call it SHAMD-51) which offers as output the concatenation of what SHA-1 and MD5, respectively, would produce over the input data.

It is easy to see that concatenation will give you a function which will be at least as resistant to collision as the strongest of the two. Unfortunately, resistance to preimages will be closer to that of the weakest of the two functions. Generally speaking, concatenation is not a good way of building hash functions: you do not get your money worth, i.e. not as much security as you could pretend for, given your computing effort and the output size you have to contend with. See this answer for some more analysis and pointers.

Offering the choice between several hash functions is much better, since it allows you to select one which matches your architecture, for better performance. Note that hashing tends to be fast anyway; when hashing files from disk, or data from the network, the hash function is rarely the bottleneck. As for all performance issues, the first thing to do is to measure: there is no performance issue unless one has been reliably detected and quantified.

Choice of hash function is also neat when you have to comply with inflexible regulations (which could mandate use of an "Approved" function, with an uppercase letter).

In practice, a lot of systems where multiple hash functions can be used together do so because of some irrational belief that cryptography is like ranch sauce which can make the worst roadkill edible as long as you add enough of it.

Note: there is no mathematical proof that any given hash function is secure. Actually, there is no mathematical proof that there can exist such a thing as a secure hash function. The best we have are hash function which were deployed "in the wild" for a long time, and survived the wanton assaults from hordes of enraged cryptographers. The SHA-2 functions (SHA-256, SHA-512) are such functions.

  • "resistance to preimages will be closer to that of the weakest of the two functions" I don't agree. First pre-images can be much weaker than either function or stronger than either, so you can't really say much, except that it doesn't guarantee anything. For second pre-images you can apply the same argument you applied to collisions to see that it's as least as strong as the stronger function. Commented Jan 3, 2013 at 20:04
  • "Note that hashing tends to be fast anyway; when hashing files from disk, or data from the network, the hash function is rarely the bottleneck." ... well, kind of. It's all relative; there are hashes designed for pure speed in checksum applications, such as Murmur and FNV. These are by no means cryptographically strong, of course, but they leave SHA2 in the dust. SHA2 is in turn light-years faster than implementations designed specifically to be slow as a counter to low input entropy, such as bcrypt/scrypt/PBKDF2.
    – KeithS
    Commented Jan 4, 2013 at 21:12
  • @KeithS: what matters here is whether the hash function is faster than disk I/O. This depends on the disk and the CPU (and what you want to do with the CPU besides hashing), but, usually, SHA-256 is faster (i.e. the CPU spends part of its time waiting for more data). For non-cryptographic purposes, MD4 (formerly a crypto hash, but broken) is quite fast (on some architectures, it has been reported to be faster than CRC32, while providing much better detection of accidental alterations). Commented Jan 4, 2013 at 21:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .