Message Digest Strength: Concatenation vs Iteration

Question

If I have 3 fields that get exposed "in the clear", and I want to digitally sign these fields to make sure that they're not tampered with using a secure hash function. I have 2 options:

1. I can concatenate the 3 fields and use a digest to hash the whole thing as a single string, i.e., hash(field1 + field2 + field3 + salt)
2. I can iteratively hash the individual results, i.e., hash(field1 + hash(field2 + hash(field3 + salt)))

Obviously approach 1 will be faster than approach 2, but will approach 2 be any "stronger" in terms of preventing one from discovering the value of the salt by reverse-engineering the inputs from a wide variety of outputs (I believe so, but is it worth the extra cpu cost)?

Answer 1

First I must issue the standard comment that hashing is not signing. A digital signature is a process which involves keys and verifiers. Here, you just want to hash some data and keep the hash value in a "safe" place, so that you could extend the integrity of the hash value to the hashed data: you make sure that the hash value is not tampered with, and, by recomputing the hash over the data elements, and finding the same hash value, you gain confidence in the idea that the field elements were not tampered with either.

Then I must issue the second standard comment, which is that there is no performance issue until duly measured in realistic conditions. Hashing is fast. With even a not-so-fast hash function, a basic PC will be able to perform millions of hash operations per second.

Now, I see that you want to use a "salt". A salt is a piece of public data, whose purpose is to be distinct for each instance, so as to prevent decryption cost sharing. This makes sense in a setup where there is some encrypted data; as far as I can see from what you describe, there is nothing encrypted in your problem.

... unless you actually mean that you will keep your "salt" secret, and store the hash value along with the data field. In which case we are not talking about hashing anymore. Your "salt" would be more appropriately called a "key", since it is meant to remain confidential. And you do not want a hash but a MAC. Sometimes, MACs are called "signatures". This is not proper, but less improper than calling hashes "signatures". If what you want is a MAC (and your salt is really a key), then you should use neither of your constructions. Building a MAC is not easy: many handmade constructions fail utterly when it comes to security. Fortunately, there is a standard MAC called HMAC. HMAC uses an underlying hash function (use SHA-256) and a key in a smart way which turns them into a MAC. HMAC is supported by many cryptographic libraries.

Answer 2

Use an HMAC (hash-based message authentication code) instead of trying to make up your own. It will be more secure, and almost any platform already has a free implementation that you can use that someone else develops, tests, and maintains.

Who can say whether it "is worth the extra cpu cost"? How often will you be doing this? Will you actually have to buy more CPUs? How much do you pay for electricity? On the other side of the balance, what will it cost you if someone successfully tampers with data "protected" by a home-brewed algorithm?