验证 HMAC 生成的哈希需要验证器知道 key 。所以它是对称的。除了 SSL 之外，更相似的非对称解决方案是什么？因为我希望签名像 md5 哈希一样小。并且生成和验证程序要简单。我正在研究 Rabin 的签名算法，但找不到任何实现或伪代码。
最佳答案
最小的非对称签名来自elliptic curve ECDSA 等密码系统。 ECDSA 签名方案需要的签名长度大约是具有同等安全性的对称密码 key 长度的四倍。因此，安全性与 128 位 AES 相当的方案将具有 512 位签名。这是目前最先进的技术——签名较小但安全性相同或更高的方案尚不清楚。
如果您不需要那么高的安全性，您可以使用 192 位曲线来生成 384 位签名。您可以降低到 320 位签名(160 位曲线)，并且仍然具有与 80 位对称密码相当的安全性。如果您真的不是特别关心安全性，可以使用 112 位曲线，提供与 DES 一样难以破解的 224 位签名。
以下曲线是我为每个安全级别推荐的曲线:
SecP112R1:224位签名，56位安全级别
SecP128R1:256位签名，64位安全级别
SecP160K1:320位签名，80位安全级别
SecP192K1:386位签名，96位安全级别
SecP224K1:448位签名，112位安全级别
SecP256K1:512位签名，128位安全级别
对于每条曲线，私钥与曲线的大小相同。公钥(压缩形式)比曲线大小大一位。签名是曲线大小的两倍。因此对于 SecP256K1，私钥为 256 位，公钥为 257 位，签名为 512 位。这些是原始二进制值的最小大小。
警告:我认为 160 位曲线对于安全性是一个因素的任何目的都是最小的。如果生成、使用 key 然后在短时间范围内丢弃，则较小的曲线可能是合适的。为了长期安全，应使用 256 位曲线。整个系统在依赖之前应由有能力的专家进行评估。
关于ssl - 非对称 HMAC，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/9897023/