在上一章中，我们探讨了如何使用公钥加密在公钥设置中实现保密性。使用数字签名方案提供公钥设置中的完整性（或真实性）。这些可被视为消息身份验证码的公钥模拟，尽管我们将看到，这些原语之间有几个重要的区别。签名方案允许已建立公钥pk的签名者使用相关私钥sk对消息进行“签名”，其方式使任何知道pk的人（并且知道此公钥是由S建立的）可以验证消息是否源自S且在传输过程中未被修改。（请注意，与公钥加密不同，在数字签名的上下文中，公钥的所有者充当发送者。）作为一个典型的应用程序，考虑一个软件公司想要以一种经过验证的方式传播软件更新；也就是说，当公司发布更新时，任何一个客户都有可能验证更新是真实的，恶意的第三方永远不能欺骗客户接受UPDA。该公司实际上没有发布的te。为此，该公司可以生成公钥pk和私钥sk，然后以某种可靠的方式将pk分发给其客户，同时对sk保密。（与公钥加密一样，我们假设公钥的初始分发是正确的，以便所有客户端都有正确的pk副本。在当前示例中，pk可以与客户端购买的原始软件捆绑在一起。）发布软件更新m时，公司使用其私钥sk计算m上的数字签名σ，并将（m，σ）发送给每个客户端。每个客户端可以通过检查σ是否是m上关于公钥pk的正确签名来验证m的真实性。
恶意方可能试图通过向客户端发送（m'，σ'）来发布欺诈性更新，其中m'表示公司从未发布过的更新。此m'可能是以前某个更新的修改版本，也可能是全新的，与以前的任何更新无关。如果签名方案是“安全的”（从某种意义上说，我们很快会更仔细地定义），但是，当客户机尝试验证σ'时，它会发现这是m'上关于pk的无效签名，因此会拒绝该签名。即使m'仅从真正的更新m略微修改，客户机也会拒绝。
上述内容不仅是数字签名的理论应用，而且是当今广泛用于分发软件更新的应用。
与消息身份验证代码的比较 Comparison to Message Authentication Codes
消息认证码和数字签名方案都用于确保传输消息的完整性。虽然第10章中比较公钥和私钥设置的讨论主要集中在加密上，但该讨论也适用于消息完整性。使用数字签名而不是消息身份验证码简化了密钥分发和管理，特别是当发送方需要与多个接收方通信时，如上面的软件更新示例所示。通过使用数字签名方案，发送方避免必须与每个潜在接收方建立不同的密钥，并且避免必须针对每个这样的密钥计算单独的MAC标签。相反，发送方只需要计算一个可由所有接收方验证的签名。
与消息认证码相比，数字签名的一个质量优势是签名是可公开验证的。这意味着，如果接收者验证给定消息上的签名是否合法，则接收该签名消息的所有其他方也将验证该签名是否合法。如果签名者与每个接收者共享一个单独的密钥，则消息身份验证码无法实现此功能：在这种设置中，恶意发送者可能会针对其与接收者a共享的密钥计算正确的MAC标记，但针对其与不同用户B共享的密钥计算不正确的MAC标记。在这种情况下，A知道他从发送者那里收到了真实的消息，但不能保证B会同意。
公开可验证性意味着签名是可转移的：签名者S在消息m上的签名σ可以显示给第三方，第三方可以验证σ是m上关于S公钥的合法签名（这里，我们假设该第三方也知道S公钥）。通过制作签名的副本，该第三方可以向另一方显示签名，并说服他们S已验证m，依此类推。正如我们将在第12.7节中讨论的那样，公开验证性和可转让性对于将数字签名应用于证书和公钥基础设施至关重要。
数字签名方案还提供了非常重要的不可否认性。这意味着，一旦S签署了一条消息，他以后就不能否认已经这样做了（假设S的公钥已被广泛宣传和分发）。数字签名的这一方面对于法律应用至关重要，因为接收人可能需要向第三方（比如法官）证明签名人确实“证明”了特定的消息（例如合同）：假设法官知道S的公钥，或者以其他方式公开，邮件上的有效签名可作为S确实签署此邮件的令人信服的证据。消息身份验证代码不能提供不可否认性。要看到这一点，假设用户S和R共享一个密钥
在私钥与公钥加密的情况下，消息身份验证码具有比数字签名更短、生成/验证效率大约高2-3个数量级的优点。因此，在不需要公开可验证性、可转移性和/或不可否认性的情况下，并且发送方主要与单个接收方通信（发送方能够与该接收方共享密钥），应当使用消息认证码。
与公钥加密的关系 Relation to Public-Key Encryption
数字签名常常被错误地视为公钥加密的“反面”，发送者和接收者的角色互换。从历史上看，事实上，有人建议可以通过“反转”公钥加密来获得数字签名，即通过解密消息m（使用私钥）来对消息m进行签名以获得σ，并通过加密签名σ（使用相应的公钥）来验证签名σ，并检查结果是否为m。以这种方式构造签名方案的建议是完全没有根据的：在大多数情况下，它根本不适用，在适用的情况下，它会导致签名方案不安全。
京公网安备 11010502036488号