Speed Hashing
codinghorror.com
Speed Hashing
1–10 of 133 posts
Re: Speed Hashing
#2[deleted]
Re: Speed Hashing
#3One very curious thing to me is that for the upcoming SHA-3 standard, Wikipedia lists the cycle timings for each hash method. I would have thought that slower hashing speed would be a good thing, but the faster the candidate algorithm the better it appears.
Perhaps the faster the hash is easier implement in hardware / less power for embedded devices?
Re: Speed Hashing
#4Hashes are designed to be fast. Password hashes (MD5crypt / SHA1crypt / bcrypt / scrypt / PBDKDF2) are designed to be slow to make dictionary attacks harder, but the hashes used in SSL and the like are designed to be as fast as possible without sacrificing too much security.
Re: Speed Hashing
#5People should be using stuff like PasswordMakerPro (https://chrome.google.com/webstore/detail/ocjkdaaapapjpmipmh...) or something similar to generate big ugly(using the whole character set) passwords.
However, secure passwords are still a crutch. We should be fixing the problem of asking for passwords. We already have solutions for this, but they are not widely used. StartSSL(http://www.startssl.com/) gives you a secure certificate which can be used to login to their site. I would love to see the browser makers make it easy for users to use client side certificates.
Re: Speed Hashing
#6Nitpick: this statement is not exactly true: "Hashes are designed to be tamper-proof".
This only applies to cryptographic hash functions, like SHA-1 and Skein. There are non-cryptogaphic hash functions which are not designed to be secure, like Dan Bernstein's DJB-family of hashes (DJBX33A and DJBX33X), that are used e.g. for hash tables with string keys.
Re: Speed Hashing
#7One very curious thing to me is that for the upcoming SHA-3 standard, Wikipedia lists the cycle timings for each hash method. I would have thought that slower hashing speed would be a good thing, but the faster the candidate algorithm the better it appears. Perhaps the faster the hash is easier implement in hardware / less power for embedded devices?
Writing hash functions is always a trade off between security and speed. SHA-3 contest has separate requirements for security, and they naturally want the fastest hash function that fulfills the requirements.
The complexity of a hardware implementation is also a factor.
Re: Speed Hashing
#8One very curious thing to me is that for the upcoming SHA-3 standard, Wikipedia lists the cycle timings for each hash method. I would have thought that slower hashing speed would be a good thing, but the faster the candidate algorithm the better it appears. Perhaps the faster the hash is easier implement in hardware / less power for embedded devices?
Imagine an implementation of git fsck, which checks that all the files in the repository match their sha1 based file names. The less time it takes to hash each file, the faster overall checking time, so it is better to use a hash which is designed to be fast.
Re: Speed Hashing
#9Nitpicks. It seems that he's talking about password hashing:
> "Hashes are designed to be tamper-proof". Wrong. Cryptographically secure hash functions are.
> "Hashes, when used for security, need to be slow." Wrong. Password hashes needs this; not SHA1/MD5 etc.
Re: Speed Hashing
#10Hashes are designed to be fast. Password hashes (MD5crypt / SHA1crypt / bcrypt / scrypt / PBDKDF2) are designed to be slow to make dictionary attacks harder, but the hashes used in SSL and the like are designed to be as fast as possible without sacrificing too much security.
As often, he plays fast and loose with terminology and uses "checksums" for "hash functions" and "hashes" for "cryptographic hash functions".
> the hashes used in SSL and the like are designed to be as fast as possible without sacrificing too much security.
See also: map and set hashes. There, you're looking for speed and good distribution across the buckets, a slower hash function is not something to look forward to.