hash()

(PHP 5 >= 5.1.2, PHP 7, PECL hash >= 1.1)

生成哈希值（消息摘要）

说明

参数

要使用的哈希算法，例如："md5"，"sha256"，"haval160,4"等。

要进行哈希运算的消息。

设置为TRUE输出原始二进制数据，设置为FALSE输出小写 16 进制字符串。

返回值

如果$raw_output设置为TRUE，则返回原始二进制数据表示的信息摘要，否则返回 16 进制小写字符串格式表示的信息摘要。

更新日志

范例

一个hash()例程

以上例程会输出：

ec457d0a974c48d5685a7efa03d137dc8bbde7e3

使用 PHP 5.4 或者更高版本计算 tiger 哈希值

以上例程在PHP 5.3中的输出：

146a7492719b3564094efe7abbd40a7416fd900179d02773
64359b7192746a14740ad4bb7afe4e097327d0790190fd16

以上例程在PHP 5.4中的输出：

64359b7192746a14740ad4bb7afe4e097327d0790190fd16
146a7492719b3564094efe7abbd40a7416fd900179d02773

参见

• hash_file() 使用给定文件的内容生成哈希值
• hash_hmac() 使用 HMAC 方法生成带有密钥的哈希值
• hash_init() 初始化增量哈希运算上下文
• md5() 计算字符串的 MD5 散列值
• sha1() 计算字符串的 sha1 散列值

I was interested how "long" each hash is, so I did:

which produce (long hashes are cropped)
md2      32 a9046c73e00331af68917d3804f70655          
md4      32 866437cb7a794bce2b727acc0362ee27
md5      32 5d41402abc4b2a76b9719d911017c592
sha1     40 aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d
sha256    64 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e730
sha384    96 59e1748777448c69de6b800d7a33bbfb9ff1b463e44354c3553
sha512    128 9b71d224bd62f3785d96d46ad3ea3d73319bfbc2890caadae2d
ripemd128   32 789d569f08ed7055e94b4289a4195012
ripemd160   40 108f07b8382412612c048d07d13f814118445acd
ripemd256   64 cc1d2594aece0a064b7aed75a57283d9490fd5705ed3d66bf9a
ripemd320   80 eb0cf45114c56a8421fbcb33430fa22e0cd607560a88bbe14ce
whirlpool  128 0a25f55d7308eca6b9567a7ed3bd1b46327f0f1ffdc804dd8bb
tiger128,3  32 a78862336f7ffd2c8a3874f89b1b74f2
tiger160,3  40 a78862336f7ffd2c8a3874f89b1b74f2f27bdbca
tiger192,3  48 a78862336f7ffd2c8a3874f89b1b74f2f27bdbca39660254
tiger128,4  32 1c2a939f230ee5e828f5d0eae5947135
tiger160,4  40 1c2a939f230ee5e828f5d0eae5947135741cd0ae
tiger192,4  48 1c2a939f230ee5e828f5d0eae5947135741cd0aefeeb2adc
snefru    64 7c5f22b1a92d9470efea37ec6ed00b2357a4ce3c41aa6e28e3b
gost     64 a7eb5d08ddf2363f1ea0317a803fcef81d33863c8b2f9f6d7d1
adler32    8 062c0215
crc32     8 3d653119
crc32b     8 3610a686
haval128,3  32 85c3e4fac0ba4d85519978fdc3d1d9be
haval160,3  40 0e53b29ad41cea507a343cdd8b62106864f6b3fe
haval192,3  48 bfaf81218bbb8ee51b600f5088c4b8601558ff56e2de1c4f
haval224,3  56 92d0e3354be5d525616f217660e0f860b5d472a9cb99d6766be
haval256,3  64 26718e4fb05595cb8703a672a8ae91eea071cac5e7426173d4c
haval128,4  32 fe10754e0b31d69d4ece9c7a46e044e5
haval160,4  40 b9afd44b015f8afce44e4e02d8b908ed857afbd1
haval192,4  48 ae73833a09e84691d0214f360ee5027396f12599e3618118
haval224,4  56 e1ad67dc7a5901496b15dab92c2715de4b120af2baf661ecd92
haval256,4  64 2d39577df3a6a63168826b2a10f07a65a676f5776a0772e0a87
haval128,5  32 d20e920d5be9d9d34855accb501d1987
haval160,5  40 dac5e2024bfea142e53d1422b90c9ee2c8187cc6
haval192,5  48 bbb99b1e989ec3174019b20792fd92dd67175c2ff6ce5965
haval224,5  56 aa6551d75e33a9c5cd4141e9a068b1fc7b6d847f85c3ab16295
haval256,5  64 348298791817d5088a6de6c1b6364756d404a50bd64e645035f

I was curious about hashes behavior (time and length), so i ran this code (yeah, I'm cheating because i took two examples from this page)

I found interesting that today (may 31, 2018), I found 103 algos, 65 more than 9 years ago (based on this comment: https://secure.php.net/manual/en/function.hash.php#89574 )
Also, here is my results: https://ideone.com/embed/0iwuGn
I'm not posting here due to message length limitations.

The well known hash functions MD5 and SHA1 should be avoided in new applications. Collission attacks against MD5 are well documented in the cryptographics literature and have already been demonstrated in practice. Therefore, MD5 is no longer secure for certain applications.
Collission attacks against SHA1 have also been published, though they still require computing power, which is somewhat out of scope. As computing power increases with time and the attacks are likely to get better, too, attacks against systems relying on SHA1 for security are likely to become feasible within the next few years.
There is no lack of potential alternative hash algorithms, as the many choices for the "algo" argument of PHPs hash() function already suggests. Unfortunately, there is lack of analysis, as to how secure these alternative algorithms are. It is rather safe to assume, though, that the SHA2 family with its most prominent members SHA-256 und SHA-512, is better than SHA1.
When storing password hashes, it is a good idea to prefix a salt to the password before hashing, to avoid the same passwords to hash to the same values and to avoid the use of rainbow tables for password recovery. Unlike suggested in other articles, there is no security advantage in putting the salt in the middle, or even at both the beginning and the end, of the combined salt-password-string.
Rather, there are two other factors, that determine the strength of the salt: Its length and its variability. For example, using the same salt for all passwords is easy to implement, but gives only very little additional security. In particular, if users type the same passwords, they will still hash to the same value!
Therefore, the salt should be random string with at least as many variable bits, as there are bits in the hash result. In the user database, store username, the randomly generated salt for that user, and the result of hashing the salt-password-string. Access authentication is then done by looking up the entry for the user, calculating the hash of the salt found in the database and the password provided by the user, and comparing the result with the one stored in the database.

Performance test results on my laptop:
Results are here shorten to fit php web notes ...
This was tested with 1024000 bytes (1000 KB) of random data, md4 always gets the first place, and md2 always get the last place :)
Results: (in microseconds)
  1. md4              5307.912
  2. md5              6890.058
  3. crc32b            7298.946
  4. crc32             7561.922
  5. sha1             8886.098
  6. tiger128,3          11054.992
  7. haval192,3          11132.955
  8. haval224,3          11160.135
  9. tiger160,3          11162.996
 10. haval160,3          11242.151
 11. haval256,3          11327.981
 12. tiger192,3          11630.058
 13. haval128,3          11880.874
 14. tiger192,4          14776.945
 15. tiger128,4          14871.12
 16. tiger160,4          14946.937
 17. haval160,4          15661.954
 18. haval192,4          15717.029
 19. haval256,4          15759.944
 20. adler32            15796.184
 21. haval128,4          15887.022
 22. haval224,4          16047.954
 23. ripemd256           16245.126
 24. haval160,5          17818.927
 25. haval128,5          17887.115
 26. haval224,5          18085.002
 27. haval192,5          18135.07
 28. haval256,5          18678.903
 29. sha256            19020.08
 30. ripemd128           20671.844
 31. ripemd160           21853.923
 32. ripemd320           22425.889
 33. sha384            45102.119
 34. sha512            45655.965
 35. gost             57237.148
 36. whirlpool           64682.96
 37. snefru            80352.783
 38. md2              705397.844
Code for generating this:
(compatible both with browser and cli mode)

Of the hash algorithms currently available, SHA3 was chosen by NIST from fifty-one submitted candidates and subsequently mandated by the U.S. Department of Commerce for Federal Government use.
http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf
So if you're wanting to select a hash algorithm, you can consider SHA3 to be "good enough for government work".

Just a quick note about these benchmarks and how you should apply them.
If you are hashing passwords etc for security, speed is not your friend. You should use the slowest method.
Slow to hash means slow to crack and will hopefully make generating things like rainbow tables more trouble than it's worth.

I haven't done any test or actual study (I'm using crc32 and storing it in mysql signed int types), but if your algorithm of choice is bigger them the supported integer of your database I suppose it is possible that the raw_format option is the best option to store directly in the database without type casting demands for it results in a binary string value.
To check if your algorithm of choice have the supported integer size in your database just strlen the raw_format output and see how many bytes it have (for example: crc32 have 4 bytes output, sha256 have 32 e md5 possue 16).

PS: You can always use floating points to store a very big number but for "common humans" binary types by and large are easier to check, understand and maintain, so i recommend to use binary, but if you are about speed them floating point could be your friend.
PS: remembering ... without the raw_format the returned value are hexadecimal values without the 'Hx' complement, so to transform the result into a decimal just hexdec as shown ...

PS: Just registering ... I have noticed here some tests where 'crc32' is slower than md5, AFAIK by definition a CRC32 algorithm (there are several algorithms to calculate CRC32) is faster than MD5 and Adler-32 is faster than CRC32 (CRC32 is more consistent than Adler-32, less consistent than MD5, but if you want to safely validate the recommended would be SHA256 or better yet SHA512 because they are less likely to collide, so less vulnerable to collision attacks)

I made a PHP script that will let you sort all the available hashes on your system by generation time or by the length of the hash. It shows a general correlation on my system (longer hashes take longer to calculate) but some are faster than others, for example, sha512 makes the (joint) longest hash, but is actually only ninth slowest (from 43 hashes available on my machine)
As I understand it, the strength of a hash is dependant on the number of collisions that it has (where two input values produce the same hash) so with an infinite number of input values but a finite number of hashes, there are a (theoretically) infinite number of collisions. But, if you have a longer hash, then you're dividing infinity by a larger number, so you'll have fewer collisions.
In reality the number of collisions will be limited by the minimum and maximum password lengths that you choose to allow, so that if you enforce a policy where passwords must be exactly a certain length (20 characters for example) you'll have a large number of unique passwords, but a smaller number of potential inputs than you have hashes coming out, so that should prevent collisions entirely. In theory.
Tl;dr: I think that longer hashes are better.
Anyway, here's the code: 

On two different servers I found that crc32() relates to hash('crc32b',)
This may be good to know if you are writing a crc32_file function based on hash_file.
(The example does not compensate for negative crc32 results)

Also if you are looking for a way to reduce collisions and still keep the hash result small (smaller than say md5) you could get a nice database friendly 64 bit value by using hash/crc32 and hash/crc32b, which is slower than a single md5 but the result may be more suitable for certain tasks.

鹏仔微信 15129739599 鹏仔QQ344225443 鹏仔前端 pjxi.com 共享博客 sharedbk.com