我正在努力保护 RESTful API，并使用Amazon AWS HMAC 模型作为我的指南。我正在努力想出一种安全的方式来存储对称密钥。标准做法是什么？这是在 Solaris 环境中运行的 Java Web 应用程序。
是否有任何理由使用对称密钥，伴随着安全存储和共享密钥通信的痛苦，而不是非对称密钥？我知道存在速度差异，因此存在一些扩展问题，但我还缺少什么？
为什么 HMAC 使用对称密钥？
信息安全
hmac
休息
不对称
2021-08-19 11:11:11
1个回答
根据定义， HMAC中使用的密钥是对称的：相同的密钥用于计算MAC 值并验证MAC 值。数字签名算法是非对称的，这意味着用于验证的密钥与用于生成的密钥不同；这种“差异”很明显：用于生成的密钥不能与用于验证的密钥重新计算（至少，没有人在现有技术的非荒谬时间内找到一种方法）。
在验证者必须能够验证签名但没有被授予生成自己的其他签名的权力的情况下，数字签名是有意义的。这是不可否认场景的典型特征：只有签名者必须能够产生有效的签名，否则签名不能被第三方明确归因（例如法官）给那个特定的签名者。但是在亚马逊AWS等认证场景中，没有第三方可以说服；只有客户和亚马逊。当一个 HMAC 值被成功验证时，亚马逊服务器确信知道 HMAC 密钥的人参与其中；由于该密钥只有客户端和服务器本身知道，并且服务器记得自己没有使用该消息的密钥，因此服务器很容易得出结论，客户端计算了 HMAC。
数字签名意味着一些开销：
更多 CPU：生成数字签名和验证数字签名需要比 HMAC 更多的工作（对于大消息，差异可以忽略不计，但对于小于几千字节的小消息，差异可能很大）。
更多的网络带宽：一个非常健壮的 HMAC 值适合 16 个字节，而同等健壮的 RSA 签名将使用 256 个字节（使用 DSA 或 ECDSA 可以降低到大约 64 个字节）。同样，这在处理大量小消息时很重要。
更大的存储空间：一个 RSA 公钥（用于验证）将使用 256 个字节；私钥将使用更多（大约一或两千字节）。ECDSA 可以在一定程度上提供帮助（任一密钥大约 32 个字节），但它仍然大于 HMAC 密钥的 16 个字节。
随机性：许多数字签名需要一些每个签名的随机性，这必须从加密安全的 PRNG中获得。
更复杂：数字签名中涉及的数学和代码比 HMAC 更复杂（HMAC 只是一对哈希函数调用；数字签名以哈希函数调用开始，然后做更奇怪的事情）。为了安全，复杂性不好。
因此，您不想在可以使用更简单的 HMAC 提供同样出色服务的上下文中使用数字签名。在我看来，最有说服力的原因是最后一个：应该避免复杂性。