4 ms·

If you're picking a new algorithm anyway, go with BLAKE2 or BLAKE3, which are faster than SHA-1 or SHA-2 (and certainly faster than chaining them), intentionall

by geofft 6y ago

If you're picking a new algorithm anyway, go with BLAKE2 or BLAKE3, which are faster than SHA-1 or SHA-2 (and certainly faster than chaining them), intentionally tunable to whatever output size you want, and also flexible / more robust in a few more ways (for instance, it's not susceptible to length extension attacks so you don't need HMAC, the intuitive approach of using hash(key + data) as a MAC is sound). BLAKE2 is surprisingly widely supported - e.g., recent versions of Python have it built into the standard library. BLAKE3 is new as of this year but worth a shot if it's easy for you to incorporate. There's nothing really wrong with SHA-2 for existing applications (well, other than the length extension thing), but if you don't need to be compatible with hashes/applications that already exist, consider BLAKE2 as the current "default" hash.

IncRnd 6y ago
Speed of digest creation is not a feature, when considering a security context. If the hash output is not used in a security context then speed is a good thing.
- cesarb 6y ago
  This is a sadly prevalent misconception. When hashing a password, you want it to be as slow as possible (and salted), so that given the hash, it's harder for an attacker to brute force the password; but when using hashing on other security contexts (for instance, message authentication), you do want it to be as fast as possible. That is: for key derivation from an user-entered password (which might have poor entropy), use algorithms specialized for that like PBKDF2 or Argon2. For everything else, you can use a modern fast cryptographic hash algorithm like BLAKE2 or BLAKE3.
- geofft 6y ago
  This is incorrect. If you are hashing passwords (or doing equivalent operations - specifically, the inputs are much lower entropy than the bit length of the hash output, and attackers have basically unlimited guesses), then you want a password-hashing algorithm, and not a general-purpose cryptographic hash, and you want it to be much, much slower than any general-purpose cryptographic hash - i.e., each attempt should take a good fraction of a second. Argon2 and scrypt are good password-hashing algorithms. None of MDx nor SHA-x nor BLAKEx are suitable here, at least not directly. (You can use them as a primitive in a password-hashing algorithm - for instance, Argon2 happens to use BLAKE2 internally - but then it doesn't matter if the primitive is "too fast," the password-hashing algorithm will just run it multiple times to slow things down.) For all other purposes, including signing and verifying files (documents, executables, etc.), signing and verifying cryptographic certificates, signing and verifying chats, etc., - i.e., cases where the input is higher entropy than the hash length and you're using the hash to allow you to sign/verify a smaller item than the original message - you want a fast, secure cryptographic hash, because that's how you build a fast, reliable system that people will use and not decide they want to use plaintext instead. Also, as it happens, most cryptographic hashes (not password-hashing algorithms) that are slow are also weaker than the cryptographic hashes that are fast. These are two different use cases that demand two different tools, and it's dangerous to lump them in under the terms "security context," because you'll end up with less secure and less usable systems. Password hashing needs a password hashing algorithm to be even slightly secure, and everything else needs a good hash, not just a slow one.
  - deleted 6y ago
    [deleted]

by geofft 6y ago

IncRnd 6y ago

Speed of digest creation is not a feature, when considering a security context. If the hash output is not used in a security context then speed is a good thing.

cesarb 6y ago
This is a sadly prevalent misconception. When hashing a password, you want it to be as slow as possible (and salted), so that given the hash, it's harder for an attacker to brute force the password; but when using hashing on other security contexts (for instance, message authentication), you do want it to be as fast as possible. That is: for key derivation from an user-entered password (which might have poor entropy), use algorithms specialized for that like PBKDF2 or Argon2. For everything else, you can use a modern fast cryptographic hash algorithm like BLAKE2 or BLAKE3.
geofft 6y ago
This is incorrect. If you are hashing passwords (or doing equivalent operations - specifically, the inputs are much lower entropy than the bit length of the hash output, and attackers have basically unlimited guesses), then you want a password-hashing algorithm, and not a general-purpose cryptographic hash, and you want it to be much, much slower than any general-purpose cryptographic hash - i.e., each attempt should take a good fraction of a second. Argon2 and scrypt are good password-hashing algorithms. None of MDx nor SHA-x nor BLAKEx are suitable here, at least not directly. (You can use them as a primitive in a password-hashing algorithm - for instance, Argon2 happens to use BLAKE2 internally - but then it doesn't matter if the primitive is "too fast," the password-hashing algorithm will just run it multiple times to slow things down.) For all other purposes, including signing and verifying files (documents, executables, etc.), signing and verifying cryptographic certificates, signing and verifying chats, etc., - i.e., cases where the input is higher entropy than the hash length and you're using the hash to allow you to sign/verify a smaller item than the original message - you want a fast, secure cryptographic hash, because that's how you build a fast, reliable system that people will use and not decide they want to use plaintext instead. Also, as it happens, most cryptographic hashes (not password-hashing algorithms) that are slow are also weaker than the cryptographic hashes that are fast. These are two different use cases that demand two different tools, and it's dangerous to lump them in under the terms "security context," because you'll end up with less secure and less usable systems. Password hashing needs a password hashing algorithm to be even slightly secure, and everything else needs a good hash, not just a slow one.
- deleted 6y ago
  [deleted]