3 ms·

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]