1

Assuming most-secure algorithms used for either, what I'd like to understand and get the answer for, is whether a salted hash is more secure than an encrypted hash?

Although similar to this question (Salting in encryption, rather than hashing) I believe it is subtly different in that the question is about salting an encrypted hash.

From what I've read, in principle salting is more secure as the hash cannot be determined without knowing the salt value.

By comparison, a decryption algorithm "could" be cracked, therefore revealing the hash.

  • Salting is standard practice. It's not very common to encrypt a hash. When asking if something is "more secure" it's very helpful to explain what properties you'd consider as more secure. Sometimes defences can be great against a foreign intelligence agency - but weak against a disgruntled employee. – paj28 Nov 13 '17 at 21:36
  • In the context of this question, "more secure" is: Will either method ultimately reveal the hash without the respective decryption key or salt value? – gb5757870 Nov 13 '17 at 21:46
6

Encryption is the exact opposite of Hashing.

  • Encryption is reversible, by means of the key.
  • Hashing is not reversible and there for only 1 way.

Now salting protects a hash from being pre-calculated and eliminates the risk from pre-calculated rainbow tables (as long as there does not exists a rainbow table for the hash and salt combo).

Now Hashing also has a parameter of being 'costly', or in other words the act of hashing must take some time. (at least for passwords) as to eliminate leaking details about the process (e.a. time based attacks).

Encryption does not add any significant properties to the hash and it does not protect against rainbow attacks, like the salting does.

Often encryption is suggested by people that go not understand cryptographic hash functions and encryption. For 1 knowledge proofs (proving the password is correct without revealing the password) hashing is better than encryption.

5

You're comparing two different kinds of defenses that work against two different kinds of threats, without stating what kinds of secrets you're trying to protect or what kinds of threats you're trying to defend against. And you're not giving us full protocols to work with, so we're going to make guesses about what you're trying to do. So please understand in advance if the answer doesn't meet your expectations.

The first thing to remember about salt is that it's not kept secret, and it's not intended to be kept secret. The sole reason salt exists is to make it difficult to guess the value of the data in the case where the data being hashed needs to remain secret AND it's possible that the data may collide with other data. For example if you and I both chose the same password and both password hashes are kept in the database, someone looking at the database could see that the hash of my password is the same as yours. But when I know your salt (remember, salt is not secret), I can try to brute-force guess your secret by running my guesses through your salt+hash algorithm.

The next question is how are you encrypting the hash? Are all hashes encrypted with the same key? If so, then collisions between secrets are still possible and it behaves no differently than an unsalted hash. For example, if my secret is "Squeamish Ossifrage", the hash digest might be 123456, and the encrypted hash digest using key ABC might be XYZ999. If your secret is also "Squeamish Ossifrage", then your hash digest is also 123456, and the encrypted hash digest using key ABC is also XYZ999. An attacker could compare entries in the database and by seeing we both have XYZ999 would know that your secret is the same as mine.

Encrypting a hash with a secret key does one thing: it prevents someone else from computing the hash because they don't know the secret key. Otherwise, it functions equivalent to a hash.

And do NOT worry about "a decryption algorithm could be cracked." If you've chosen a strong algorithm as you stated in your preconditions that's not a realistic concern. (And if you've chosen AES-256 and it's cracked, the whole world has a lot more to lose than whatever secrets you're keeping.)

  • FYI, encrypting the same data with the same key doesn't necessarily mean the encrypted data will be the same. Most cryptographic schemes use an initialization vector specifically to prevent that. That doesn't mean salting an encrypted hash is unnecessary though, since if the encryption key is discovered the salt will still serve its normal function of protecting against the use of precomputed hash tables in attempts to recover the plaintext password. – Ajedi32 Nov 13 '17 at 22:26
  • 3
    @Ajedi32 yes, the Initialization Vector acts exactly like a salt in that case, preventing collisions. But we don't have enough details from the question to know if that's how he's going to use it. Based on the original question, I didn't see that adding details about how the IV worked would have improved it. – John Deters Nov 13 '17 at 22:36
  • 1
    Don't salts also protect against attacks that use precomputed data, like the infamous rainbow tables? Regardless, +1 for the good analysis. – jpmc26 Nov 13 '17 at 22:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.