为了完整地保护字节流，可以在概念上使用对称加密(例如使用SHA-1的HMAC)或非对称加密(例如使用RSA的数字签名)。非对称加密比对称加密要昂贵得多，这是常识。然而，我想有硬数字，并想知道是否存在现有的加密库(例如openssl)的基准套件，以便获得对称和非对称加密算法的一些测量结果。不幸的是，我从内置的"openssl速度"应用程序中得到的数字不能相互比较。
也许有人已经为此目的实现了一个小的基准测试套件?谢谢,马丁
我不认为基准在这里是有用的，因为您比较的两个东西是为不同的用例构建的。HMAC是为你有一个可以用来验证消息的共享秘密的情况而设计的，而签名是为你没有共享秘密的情况而设计的，而是希望任何拥有你的公钥的人都能够验证你的签名。在很少的情况下，任何一种原语都是同样合适的，当有这种情况时，很可能会有一个明显的安全偏好，而不是性能。
证明HMAC将更快是相当简单的，然而:签名消息需要首先对其进行哈希，然后计算哈希上的签名，而计算HMAC需要首先对其进行哈希，然后计算HMAC(这仅仅是两个额外的单块哈希计算)。然而，出于同样的原因，对于加密原语的消息长度和速度的任何合理假设，速度差异将可以忽略不计，因为最大的部分成本是在两个操作之间共享的。
简而言之，您不应该根据性能上微不足道的差异来选择密码系统的结构。
所有的数字签名算法(RSA, DSA, ECDSA…)都是从使用哈希函数对源流进行哈希开始的;之后只使用哈希输出。因此，对长数据流签名的渐近代价与对同一流进行哈希的渐近代价相同。HMAC在这方面是类似的:首先你在哈希函数中输入一个固定大小的小报头，然后是数据流;在最后你有一个额外的哈希操作，它对一个固定大小的小输入进行操作。因此，HMACing一个长数据流的渐近代价与哈希一个长数据流的渐近代价是相同的。
综上所述，对于适当长的数据流，数字签名和HMAC的CPU开销是相同的。速度差异不会很明显(数字签名末尾的复杂部分比HMAC更昂贵，但简单的PC仍然可以在不到一毫秒的时间内完成)。
但是，哈希函数本身可以产生影响，至少如果您可以以高带宽获取数据。在一台典型的PC上，您可以希望使用SHA-1以大约300 MB/s的速度散列数据，但使用SHA-256"只能"达到150 MB/s。另一方面，一个好的机械硬盘或千兆以太网的读取速度很难超过100 MB/s，所以SHA-256不会成为这里的瓶颈。