计算 MD5散列的 CPU 密集程度是否比 SHA 家族函数低？

在“标准”膝上型电脑 x86硬件上计算 MD5散列比 SHA-1或 SHA-2的 CPU 密集程度低吗？我感兴趣的是一般信息，而不是特定芯片的信息。

更新: 在我的例子中，我感兴趣的是计算文件的散列。

123706 次浏览
小开
最佳答案

是的，MD5在某种程度上不那么占用 CPU 资源。在我的 Intel x86(Core2 Quad Q6600,2.4 GHz，使用一个核心)上，我得到了32位模式:

MD5       411
SHA-1     218
SHA-256   118
SHA-512    46

而这个是64位模式:

MD5       407
SHA-1     312
SHA-256   148
SHA-512   189

对于“长”消息，数字以每秒兆字节为单位(这是超过8kB 的消息所得到的数字)。这是与 Sphlib一起实现的，Sphlib是一个用 C (和 Java)实现的 hash 函数库。所有的实现都来自同一个作者(我) ，并且在优化方面做出了可比较的努力; 因此速度差异可以被认为是函数真正固有的。

作为一个比较，考虑一下最近的硬盘运行速度大约是100MB/s，而且任何超过 USB 的硬盘都会低于60MB/s。尽管 SHA-256在这里看起来“很慢”，但对于大多数情况来说，它已经足够快了。

请注意，OpenSSL包含一个32位的 SHA-512实现，它比我的代码快得多(但是没有64位的 SHA-512快) ，因为 OpenSSL 实现是在汇编中并且使用 SSE2寄存器，这是无法在普通 C 中完成的。 SHA-512是这四个功能中唯一受益于 SSE2实现的功能。

编辑: 在 这一页(存档)上 ，可以找到关于许多散列函数速度的报告(单击“ Telechargez mainentant”链接)。这份报告是用法语写的，但大部分都是表格和数字，而且数字是国际性的。实现的散列函数不包括 SHA-3候选函数(除了 SHABAL) ，但我正在处理它。

小开

MD5也受益于 SSE2的使用，查看 BarsWF，然后告诉我它没有。所有它需要的是一个小的汇编知识，你可以制作自己的 MD5 SSE2例程(s)。然而，对于大量的吞吐量，与重新安排输入数据以与所使用的 SIMD 指令兼容所花费的时间相比，在散列过程中存在速度的折衷。

小开

在我的2012款 MacBook Air (Intel Core i5-3427U，2 x 1.8 GHz，2.8 GHz Turbo)上，SHA-1比 MD5(在64位模式下使用 OpenSSL)稍微快一些:

$ openssl speed md5 sha1
OpenSSL 0.9.8r 8 Feb 2011
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md5              30055.02k    94158.96k   219602.97k   329008.21k   384150.47k
sha1             31261.12k    95676.48k   224357.36k   332756.21k   396864.62k

更新: 使用 OS X 10.910个月后，SHA-1在同一台机器上变慢了:

$ openssl speed md5 sha1
OpenSSL 0.9.8y 5 Feb 2013
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md5              36277.35k   106558.04k   234680.17k   334469.33k   381756.70k
sha1             35453.52k    99530.85k   206635.24k   281695.48k   313881.86k

第二次更新: 在 OS X 10.10上，SHA-1的速度回到了10.8级:

$ openssl speed md5 sha1
OpenSSL 0.9.8zc 15 Oct 2014
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md5              35391.50k   104905.27k   229872.93k   330506.91k   382791.75k
sha1             38054.09k   110332.44k   238198.72k   340007.12k   387137.77k

第三次更新: 使用 LibreSSL 的 OS X 10.14更快(仍然在同一台机器上)。SHA-1仍然领先:

$ openssl speed md5 sha1
LibreSSL 2.6.5
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md5              43128.00k   131797.91k   304661.16k   453120.00k   526789.29k
sha1             55598.35k   157916.03k   343214.08k   489092.34k   570668.37k
小开

真正的答案是: 看情况

有几个因素需要考虑，最明显的是: 运行这些算法的 CPU 和算法的实现。

例如，我和我的朋友都运行完全相同的 openssl 版本，并且在不同的 Intel Core i7 CPU 上得到略有不同的结果。

更新2021 在 Ryzen 93900x 上的 Ran openssl speed sha1 md5: Sha1现在比 md5快2-3倍，并且随着数据量的增加差异也在增加

The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
md5             171084.26k   373867.24k   660204.56k   783808.17k   840138.75k   843743.23k
sha1            309769.46k   772013.89k  1523885.48k  2017251.67k  2226836.82k  2251024.61k

更新完毕

我的测试使用的是 Intel (R) Core (TM) i7-2600 CPU@3.40 GHz

The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md5              64257.97k   187370.26k   406435.07k   576544.43k   649827.67k
sha1             73225.75k   202701.20k   432679.68k   601140.57k   679900.50k

还有他的 Intel (R) Core (TM) i7 CPU 920@2.67 GHz

The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md5              51859.12k   156255.78k   350252.00k   513141.73k   590701.52k
sha1             56492.56k   156300.76k   328688.76k   452450.92k   508625.68k

我们都在运行2014年10月15日 ArchLinux 官方包中的 OpenSSL 1.0.1 j 的完全相同的二进制文件。

我的观点是，随着 sha1安全性的增加，CPU 设计人员更有可能提高 sha1的速度，并且更多的程序员将致力于算法的优化，而不是 md5sum。

我猜测 md5将不再使用的一天，因为它似乎没有优势超过 sha1。我还在实际文件上测试了一些案例，结果在两种情况下总是相同的(可能受到磁盘 I/O 的限制)。

一个大的4.6 GB 文件的 md5sum 比同一个文件的 sha1sum 花费的时间完全相同，许多小文件(同一目录中的488个)也是如此。我做了十几次测试，结果都是一样的。

--

这将是非常有趣的进一步调查。我想有一些专家可以提供一个可靠的答案，解释为什么 sha1在新的处理器上比 md5更快。

小开

在 Power9上，sha1sum 比 md5sum 快得多

$ uname -mov
#1 SMP Mon May 13 12:16:08 EDT 2019 ppc64le GNU/Linux


$ cat /proc/cpuinfo
processor       : 0
cpu             : POWER9, altivec supported
clock           : 2166.000000MHz
revision        : 2.2 (pvr 004e 1202)


$ ls -l linux-master.tar
-rw-rw-r-- 1 x x 829685760 Jan 29 14:30 linux-master.tar


$ time sha1sum linux-master.tar
10fbf911e254c4fe8e5eb2e605c6c02d29a88563  linux-master.tar


real    0m1.685s
user    0m1.528s
sys     0m0.156s


$ time md5sum linux-master.tar
d476375abacda064ae437a683c537ec4  linux-master.tar


real    0m2.942s
user    0m2.806s
sys     0m0.136s


$ time sum linux-master.tar
36928 810240


real    0m2.186s
user    0m1.917s
sys     0m0.268s
小开

作为一个 花一点时间优化 MD5的性能的人，我认为我应该提供比这里提供的基准更多的技术解释，给将来碰巧发现这一点的人。

MD5的“工作”比 SHA1少(例如更少的压缩轮) ，因此人们可能认为它应该更快。然而，MD5算法基本上是一个大的依赖链，这意味着它不能很好地利用现代超标量处理器(即每时钟指令较低)。SHA1具有更多的并行性，因此尽管需要完成更多的“计算工作”，但在现代超标量处理器上，它通常比 MD5更快。
如果在较老的处理器或者超标量“宽度”较小的处理器(比如基于 Silvermont 的 Atom CPU)上进行 MD5与 SHA1的比较，通常会发现 MD5比 SHA1快。

SHA2和 SHA3的计算密集程度甚至比 SHA1更高，而且通常要慢得多。
但是，需要注意的一点是，一些新的 x86和 ARM CPU 具有加速 SHA1和 SHA256的指令，如果使用这些指令，显然对这些算法有很大帮助。

顺便说一句，SHA256和 SHA512的性能可能表现出类似的奇怪行为。SHA512比 SHA256“工作”得更多，然而，两者之间的一个关键区别是，SHA256使用32位单词运行，而 SHA512使用64位单词运行。因此，在64位字大小的平台上，SHA512通常比 SHA256快，因为它一次处理的数据量是 SHA256的两倍。相反，在32位字长的平台上，SHA256的性能应该优于 SHA512。

请注意，以上所有内容只适用于单缓冲区散列(目前为止最常见的用例)。如果您喜欢并行计算多个散列，比如使用多缓冲区 SIMD 方法，那么行为会有所改变。

小开 
[
Is MD5 faster or SHA1? ]


It's implementation dependent:


|*|
[
Theoretically the MD5 algorithm would do less work than SHA1, but the design of MD5 itself determined that the algorithm cannot effectively exploit computation parallelism (i.e. cannot effectively utilize a multi-processor system; or processors that utilize instruction-level parallelism). While SHA1 would provide better opportunity for so.


This is part of the reason why in some implementations SHA1 would outperform MD5. ]


|*|
[
There are also processors that provide dedicated hardware acceleration support for SHA1.


When properly utilized, such implementations tend to easily outperform software based MD5 implementations:


[ Quote dr-js @ CE 2021-01-28 10:31 UTC:
https://security.stackexchange.com/a/95697


2021 update with OpenSSL 1.1.1d: now we see md5 is often slower on newer CPU, and for larger chunks:


[
## PC i7-1165G7 @ 2.80GHz (2020)
OpenSSL 1.1.1d  10 Sep 2019 / built on: Mon Dec  7 20:44:45 2020 UTC
type      16 bytes    64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
md5     189018.70k  418310.85k   712090.28k   890189.14k   956293.12k   962560.00k
sha1    287134.62k  746529.17k  1474064.38k  1973607.08k  2197842.60k  2192179.20k
sha256  222301.71k  603962.47k  1213340.33k  1665262.59k  1849016.32k  1847388.84k


## Server AMD EPYC 7571 (2018)
OpenSSL 1.1.1d  10 Sep 2019 / built on: Mon Dec  7 20:44:45 2020 UTC
type      16 bytes    64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
md5      93668.33k  213979.18k   378971.56k   467472.38k   501205.67k   504064.68k
sha1    165020.82k  442991.72k   888443.48k  1188591.62k  1319236.95k  1330080.43k
sha256  142886.55k  375612.63k   791567.70k  1095950.34k  1234381.48k  1246827.86k


## Server E5-2682 v4 @ 2.50GHz (2016)
OpenSSL 1.1.1d  10 Sep 2019 / built on: Mon Dec  7 20:44:45 2020 UTC
type      16 bytes    64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
md5     101505.24k  207422.92k   393158.83k   453332.99k   527085.34k   490711.72k
sha1     98091.83k  249828.79k   389640.36k   675694.25k   686966.33k   721021.61k
sha256   55421.86k  130103.33k   251929.17k   302571.86k   296977.81k   338439.56k
] ]


Worth noticing that even SHA-256 could be faster than MD5 in such cases. ]




To put it in a simple (though not so accurate) statement:


|*| For high-end processors, SHA1 tends to be faster.
|*| For low-end processors, MD5 would be faster.




[ Quote Nyan @ CE 2020-12-10 10:18 UTC:
https://stackoverflow.com/a/64928816


Note that all of the above only applies to single buffer hashing (by far the most common use case). If you're fancy and computing multiple hashes in parallel, i.e. a multi-buffer SIMD approach, the behaviour changes somewhat. ]

提交答案