Hashing

「 Overview 」




Recommended 「 In Order 」


BLAKE2b ( 512 | 256 )

BLAKE (what BLAKE2 was on) received a significant amount of cryptanalysis,
even more than Keccak (the SHA3 finalist), as part of the SHA3 competition,
and now quite popular in software (e.g. it’s used in Argon2 and many other
password hashing schemes).

SHA ( 256 | 512 )

SHA2 is the most popular hash function, meaning it’s widely available in
cryptographic libraries, it’s still secure besides Length Extension Attacks
(please see point 3 of the Notes section) and it offers decent performance.

SHA3 ( 256 | 512 )

If it was more common in software, then I would recommend it over SHA2
to prevent length extension attacks, but I’d still recommend BLAKE2b in such
a case due to the improved software performance and equivalent security.

BLAKE3 256

The fastest cryptographic hash in software (assuming you don’t suffer from
performance issues in the main implementation) at the cost of having a
lower security margin and being limited to a 128-bit security level.

However, it improves on BLAKE2 in that there’s only one variant that covers
all use cases (it’s a regular hash, PRF, MAC, KDF, and XOF), but depending on
the cryptographic library you use, this isn’t necessarily something you’ll notice
when using BLAKE2b anyway.




Avoid 「 Unordered | All Unsuitable 」


Non-cryptographic Hash Functions

And Error-Detecting Codes

Such as CRC. The clue is in the name, these are not secure.

〔 MD5 〕〔 SHA1 〕

Both are very old and no longer secure.

For instance, there’s an attack that breaks MD5 collision resistance in 2 ^ 18 time.
This takes less than a second to execute on an ordinary computer.

Insecure SHA3 Candidates

Such as EDON-R

If you want to use something from the SHA3 competition, then consider:

BLAKE2b:

SHA3:

BLAKE3:

RIPEMD

〔 Whirlpool 〕 〔 SHA224 〕 〔 Streetbog 〕 〔 MD6 〕

And Other Uncommonly Used Hashes


These are all worse in one way or another than the
 recommended algorithms, which is why they aren’t used.


For instance:

Chained Hashes

HASH-B( HASH-A( Message ) )

This can be insecure.


SHA1 for example has worse collision resistance than SHA256,
meaning a collision for SHA1 results in a collision for

SHA256( SHA1( Message ) )

and is obviously less efficient than hashing once.


Just don’t do this.

128-Bit Hashes

You shouldn’t go below a 256-bit output with
hash functions to ensure 128-bit security.




Notes


「 1 」

These hash functions are not suitable for password hashing.

These algorithms are fast, whereas password hashing
needs to be slow to prevent bruteforce attacks.

Furthermore, password hashing requires using a random salt
for each password to derive unique hashes when given the same
input and to protect against attacks using precomputed hashes.

「 2 」

These unkeyed hash functions are not suitable for authentication.

You need to use MACs such as keyed BLAKE2b-512 and HMAC-SHA512
for authentication because they provide the appropriate security guarantees.
↳ Check out the Message Authentication Codes section

「 3 」

Beware Of Algorithms Susceptible To Length Extension Attacks


Such as:


An attacker can use Hash( MessageA ) and the length of MessageA
to calculate Hash( MessageA | MessageB ), with MessageB being
controlled by the attacker, without knowing what MessageA is.

Therefore, concatenating things like Hash( Secret | Message )
with these algorithms is a bad idea.

Instead consider:

as none of these are susceptible to Length Extension Attacks .

Also, please read point 5 of the Message Authentication Codes notes as
concatenating parameters incorrectly can lead to another type of attack.



「 Overview 」