签名与验证
数字签名包含生成与验证两个过程。签名者使用私钥和待签数据，按规定算法生成签名；验证者使用对应公钥、数据及签名检查它们的关系。公钥可以公开，私钥必须秘密保管，否则得到私钥的他人可能冒充签名者。
许多方案在签名前先对消息计算密码学摘要，再把摘要作为签名过程的输入，但不能把所有算法都简化为“用私钥加密摘要”。FIPS 186-5 对 RSA、ECDSA、HashEdDSA 与 EdDSA 的输入处理作了区分。签名算法有自己的生成和验证规则，不一定具有可以反向解密的形式。
签名绑定的是指定数据
有效签名使验证者能够检测与签名不匹配的数据修改。在正确算法、参数和实现的安全前提下，攻击者不应能在不知道私钥时，为不同消息伪造该签名者的有效签名。这里保护的是被签过程实际覆盖的数据，而不是读者想当然认为相关的全部内容。
例如若一个协议只签署某段数据，未被覆盖的附加说明不会因为与签名一起出现就自动受到保护。实际系统需要明确消息的编码、范围和解释方式。验证失败也不能单凭结果确定是正文被改、签名损坏还是选用了错误公钥，只能说明给定输入未通过相应验证。
身份绑定需要额外保证
数学验签成功不等于已经确认现实身份。任何人都可以生成自己的密钥对，并给公钥贴上他人的名字。验证者还需要可靠地确认公钥属于声称的签名者，并确认密钥与参数有效以及相关私钥的持有保证。证书和可信的公钥基础设施是实现身份绑定的常见方式。
FIPS 186-5 因而把数学验证与取得这些保证的完整确认过程区分开来。公钥不需保密，但不能任由替换；私钥一旦失密，签名的身份解释也会受到影响。数字签名所能支持的来源证据，始终依赖密钥管理和具体信任依据。
参考：[1]
不保密，也不证明事实
签名与加密解决不同问题。签名可以随公开正文一起发布，允许任何获得正确公钥的人验证；若还需要限制谁能读正文，就必须另行采用保密机制。TLS 1.3 同样区分认证与记录层的数据保护，签名不是对称认证加密的替代品。
签名还不能证明消息中的事实正确、建议可靠或软件行为安全。一个经验证的来源仍可以签署错误内容。这一限制来自签名的验证对象：密码学检查的是数据与密钥的关系，不是在审查陈述本身。手写签名扫描图像也不是这种密码学过程，外观相似并不提供同等的修改检测能力。