How long should I wait before using a newer (hopefully improved) hash function? For instance:
Is SHA-3 ready for use because of extra testing that went on during the NIST competition?
10
- sha-3 is ready for use now. imho it's better for hashing; more of the qualities we want for a hash.dandavis– dandavis2017-10-07 00:24:28 +00:00Commented Oct 7, 2017 at 0:24
- 3you mean, "when is a hash function deemed ready?" ? Or, "how long should I wait before replacing existing hash functions with newer ones?" ? Your title is ... ambiguousschroeder– schroeder ♦2017-10-09 14:32:40 +00:00Commented Oct 9, 2017 at 14:32
- What are you using the hash function for? Password storage? Something else?Anders– Anders2017-10-10 12:35:22 +00:00Commented Oct 10, 2017 at 12:35
- @Anders, See my comments on the accepted answer. I'm looking for a general-purpose hash function that has longevity (unlike SHA-1). SHA-3 fits the bill, as long as it is wrapped in PBKDF2 when used for passwords.NH.– NH.2017-10-12 14:47:21 +00:00Commented Oct 12, 2017 at 14:47
- @schroeder, I was under the impression that new hash functions (or crypto in general) shouldn't be used until it has been in the wild for awhile, but perhaps that was mistaken.NH.– NH.2017-10-12 14:54:06 +00:00Commented Oct 12, 2017 at 14:54
| Show 5 more comments
2 Answers
How long should I wait before using a newer (hopefully improved) hash function?
The better question to ask is: "How long should I wait before switching off my current hash". What are you on now? If your data is protected with MD5 or SHA1 then please switch. Please switch now. If you're already on something that's believed to be unbroken, then you have no reason to "upgrade".
The general rule with crypto is to assume everything will be broken eventually, so pick something that's not known to be broken at the time, and have a plan in place to switch your data over to a new algorithm in a hurry if an attack does get published.
At the time of writing, the following are all perfectly acceptable, not known to be broken, hash functions / key derivation functions:
- BLAKE, SHA2, SHA3, ... , bcrypt, scrypt, PBKDF2, argon2, ...
Choose the one that best fits your application.
Is SHA-3 ready for use because of extra testing that went on during the NIST competition?
If NIST has standardized it (which they have in FIPS-202), then it's ready for use!
As @RoryAlsop said, beware that if you need your data to be compatible with multiple pieces of software, then be aware of compatibility issues; just because SHA3's been standardized for two years, doesn't mean that it's been widely adopted.
One final note, reading between the lines, you seem to be implying that SHA3 is a "a newer (hopefully improved) hash function". I want to correct this.
While it is newer, it is not "better" than SHA2, in fact SHA3 offers exactly the same security levels as SHA2. NIST launched the SHA3 competition not because they wanted to "improve" on SHA2, but because they were uncomfortable with the "all your eggs in one basket" nature of only having one approved hash algorithm. That's not to say there's anything wrong with SHA2, but if something does come up, they want to have a migration path at the ready.
SHA3 for password hashing.
Bad idea. SHA3 is ideal for file hashing (because it's fast), but it would actually be considered a weakness to use it for password hashing (because it's fast).
See NIST SP-800-63b:
Examples of suitable key derivation functions include Password-based Key Derivation Function 2 (PBKDF2) [SP 800-132] and Balloon [BALLOON]. A memory-hard function SHOULD be used because it increases the cost of an attack.
SHA3 is designed to be efficient, it is neither slow (time-hard) nor big (memory-hard).
PBKDF2 and Balloon are schemes that wrap around a standard hash function to make it time-hard / memory-hard, respectively. So if you only wanted to support one hashing primitive in, say, your embedded hardware device, you can wrap PBKDF2 / Balloon around SHA3 and still have FIPS-certified crypto, but please don't use naked SHA3 on passwords.
- I thought SHA3 offered customizability of computation time (think baloon or scrypt or something that can have lots of iterations to slow it down). Is that true?NH.– NH.2017-10-09 15:08:32 +00:00Commented Oct 9, 2017 at 15:08
- @NH. uhh, not sure. I thought
rateandcapacity(the block size and internal state size) where the only tunable params. My understanding is that a requirement of the SHA3 competition was "efficient in software and hardware", and hardware likes fixed constants. You can certainly wrap SHA3 inside a construction like repeated-salt-and-hash, or PBKDF2 to get tunable computation time. But if you want a slow hash function, then something designed to be efficient probably isn't for you; go with scrypt or argon2 which are explicitely designed to be inefficient.Mike Ounsworth– Mike Ounsworth2017-10-09 15:14:13 +00:00Commented Oct 9, 2017 at 15:14 - oh how sad. I really wanted a one-hash-function-to-rule-them-all! Guess I'll still have to use (& recommend) a different function for file hashing than for password hashing.NH.– NH.2017-10-09 16:27:38 +00:00Commented Oct 9, 2017 at 16:27
- @NH. lol yeah. SHA3 is ideal for file hashing (because it's fast), but it would actually be considered a weakness to use it for password hashing (because it's fast). I'll edit something into my answer.Mike Ounsworth– Mike Ounsworth2017-10-09 16:33:36 +00:00Commented Oct 9, 2017 at 16:33
Generally, once a function has been approved as a replacement for an existing one it is worth looking at how you would migrate, so that once there are identified weaknesses you can carry out that transition.
New functions are developed so that there is a replacement - as it is a given that weaknesses will be found in older ones.
So it's not a case of waiting for the new function to have extra testing (although obviously for approval by e.g. NIST there is a lot of testing that has happened) - its a case of waiting for there to be a need.
