English version · 区块链学习导航 · 上一篇：密码学哈希
区块链学习 · 文章 BC013
数字签名让人能够在特定方案假设下，检查消息是否由相关签名密钥授权。私钥提供签名能力，相应公钥支持核验，而不需要公开秘密。
这种分离很有力量，但结论有明确范围。有效签名不自动证明谁坐在设备前、对方理解了什么、消息是否真实，或请求动作是否应该成功。
本文跟随一次虚构文档批准，区分密钥控制、消息含义与应用权限，不要求开设账户或处理真实秘密。
选择适合你的阅读路线
本篇目录
- 1. 密钥对把行动权与检查分开
- 2. 三种操作，分别产生不同结果
- 3. 签名不是“用私钥加密”
- 4. 实例：批准展览清单
- 5. 准确消息才是批准对象
- 6. 身份需要原始密钥之外的绑定
- 7. 有效签名仍可能请求无效动作
- 8. 再次使用签名，不等于重新批准
- 9. 密钥失陷，改变成功检查的含义
- 10. 公开核验不提供保密
- 11. 消息里的时间戳，仍然是一项声明
- 12. 复核者应该检查什么？
- 纸笔练习：四个看起来相似的批准
- 常见问题
- 资料来源与范围
- 学习机制：从密钥对、签名与验证顺序开始。
- 理解批准对象：阅读文档案例和上下文检查。
- 评估安全说法：关注身份、权限失陷与重放。
- 安全练习：使用纸笔核验题和答案。
1. 密钥对把行动权与检查分开
在公钥签名系统中，私钥是用于生成签名的秘密材料；公钥则是别人用来核验的信息。
数学关系允许核验者在不知道签名秘密的情况下检查。在方案安全假设和适当实现下，持有公钥，不应让人能够实际伪造任意未经授权消息的有效签名。
这不同于把同一个密码分享给所有核验者。公开验证密钥本来就用于检查，私有签名权限则不应公开。
但公钥可见，不代表它自动识别主人。需要建立哪个密钥对应正在检查的机构、账户或角色。否则，无关密钥下完全有效的签名，只是正确回答了错误问题。
2023年2月3日发布的NIST数字签名标准FIPS 186-5，是签名算法一手参考。它描述机制，不包办完整身份或机构批准流程。
2. 三种操作，分别产生不同结果
密钥生成按照方案产生签名和验证所需材料。安全生成与处理是系统的一部分，不是可有可无的细节。
签名使用私有签名权限、消息，以及方案规定的其他输入，产生签名值。算法之间过程不同，不能假定所有方案使用相同公式或同样方式的随机性。
验证根据相关公钥和方案规则，检查消息与签名。结果支持或否定这项密码学关系。
验证不需要对方取得私钥。如果某个所谓检查服务，仅为核验公开签名就索要真实私钥或助记词，这与上述基本分离不符。
本课保持概念性，不提供密钥生成代码，也不建议初学者自创签名实现。
3. 签名不是“用私钥加密”
一种常见简化，是把签名说成用私钥执行加密。它不能可靠地解释现代签名方案。
加密与签名具有不同目标和算法。加密保护保密性，让授权解密恢复明文；签名支持核验授权消息。带签名的消息仍可能完全可读。
签名过程可以涉及哈希和其他数学操作，但称它为加密，会让读者误以为具备保密保证，也可能误解具体算法运行方式。
更稳妥的功能说明是：签署者为消息产生方案定义的签名；核验者使用公开验证密钥检查。
这样不必把所有签名方案都假装成反向加密，也能准确理解职责。
4. 实例：批准展览清单
设想成年策展人莉娜获准批准一份虚构展览清单，用于内部规划。机构认可某个特定公钥承担这项批准角色。
文件具有版本标识和指纹。批准消息说明覆盖哪个版本，以及批准代表什么。在本例中，它只代表内部规划批准，不代表允许公开发布，也不保证每个陈述都经过独立调查。
莉娜的签名系统对明确批准消息生成签名。复核者随后取得消息、签名、相关公钥，以及用于目标比较的文件。
复核者检查文件是否匹配指定版本，签名是否在认可密钥下通过；还要按照机构流程，检查该密钥是否有权进行这种批准。
这些步骤支持关于版本及批准权限的有限结论，不自动证明莉娜本人在场、判断完美，或每条说明真实。
5. 准确消息才是批准对象
“批准第七版”与“确认收到第七版”不同。“批准内部审核”与“批准公开发布”也不同。
界面应使授权内容可以理解。如果屏幕显示无害摘要，实际签名字节却授权更广动作，签名仍可能通过，而人机交互已经误导用户。
结构化消息需要明确表示与解释。签名保护签名过程规定的消息，不保护后来网站随意放进标记里的描述。
W3C的可验证凭证数据完整性1.0于2025年5月15日成为推荐标准，将证明用途、验证关系和数据处理纳入周边设计。这说明数学签名检查只是一部分。
认真复核应同时问：“签名通过了吗？”以及“通过的消息究竟授权什么？”
6. 身份需要原始密钥之外的绑定
假设文件由公钥K对应的权限签署。密码学检查可以正确，但K是谁？
应用可能通过账户注册表、证书安排、机构目录或其他身份机制，把密钥连接到角色。机制具有自己的维护和信任假设。
如果复核者从同一条不可信消息里取得密钥，而消息自称来自博物馆，有效签名只说明它与所提供密钥一致，不独立证明博物馆批准。
必须通过合适可信过程，把密钥连接到目标权限。员工角色或密钥变化时，这种绑定也可能变化。
所以，公钥、账户地址、机构名称和法律主体，不能直接当成可互换标签。它们可以连接，但连接必须解释并检查。
7. 有效签名仍可能请求无效动作
现在假设批准密钥只能批准内部草稿，不能批准公开发布，却签署了公开发布请求。
密码学签名可以正确通过；如果角色没有相应权限，应用仍应拒绝。签名有效与政策允许，是两项检查。
区块链交易也有同类区别。密钥可以授权消息，但动作仍可能因为余额、状态、权限或其他协议条件不满足而失败。
以太坊交易文档展示了授权位于更广交易过程中的一种安排。不同网络规定自己的字段和规则。
可以这样理解：验证告诉应用某些与消息签名权限有关的信息；应用仍需判断当前环境中是否允许执行。
8. 再次使用签名，不等于重新批准
已经记录的签名，再次展示时可能仍能通过数学检查。但这不表示应用应重复执行动作，或在所有环境接受它。
回到莉娜的清单：对一个明确版本和用途的批准，不应悄悄变成对另一版本或用途的批准。协议需要把相关上下文纳入签署和检查范围。
交易系统同样需要防止不当重放。计数器、花费条件、标识和用途相关环境，可以按设计发挥作用。必须对实际协议评估具体机制。
以太坊账户文档介绍其交易计数器；比特币则使用围绕输出的花费条件及其他交易规则。这些是例子，不是通用配方。以太坊账户 · 比特币交易。
核心是：旧的授权证据，不自动成为新动作的新授权。
9. 密钥失陷，改变成功检查的含义
攻击者控制签名权限后，可能产生能够通过验证的签名。算法不一定失败，失败的是谁控制密钥这一假设。
机构需要程序阻止未来滥用、建立替代权限，并解释哪些旧记录可能受影响。签名本身不揭示密钥准确何时失陷。
同样，无法访问私钥可能让后续签名停止，即使公开记录仍然可见。密码学验证不会恢复丢失的签名能力。
NIST的密钥管理建议第一部分第五次修订版说明密钥管理跨越整个生命周期。本课采用这个原则，但不为某个钱包或机构指定恢复操作。
保护签名权限和规划替换，与检查一次签名，是不同任务。
10. 公开核验不提供保密
数字签名可以公开验证，消息本身也可以公开。这通常有用：许多读者能检查同一批准，而不需要获得秘密签名材料。
但签名不隐藏消息。如果文档需要保密，应用应另行设计披露限制。
根据使用方式，公钥与签名也可能形成可关联记录。密钥叫“公开”，不等于其所有用途都与隐私无关。
在展览例子中，公开带签名的内部清单，可能暴露本来限制的信息。签名有效，不代表披露合适。
应分别问：谁能够核验声明？谁有权知道内容？
11. 消息里的时间戳，仍然是一项声明
签名消息可以包含日期时间。签名可以保护内容中的该值不被未发现地改动，却不单独证明时钟准确，或签署恰好发生在那个时刻。
如果应用需要更强时间证据，就需要合适时间戳或记录安排，并说明它实际证明什么。
同样，进入账本可以提供协议特定的排序或记录证据，却不应随意扩大成每个现实事件时间的证明。
在莉娜的例子中，“中午批准”字段属于声明。机构能否把它作为准确时间依赖，取决于周边流程。
更广泛的要点是：受保护的内容，与关于内容真实情况的独立证据，需要区分。
12. 复核者应该检查什么？
概念性复核可以使用六问。
- 消息：准确签署了哪些内容与用途？
- 方案：采用什么签名方法和验证规则？
- 密钥绑定：为什么认可此公钥代表相关权限？
- 许可：该权限是否允许执行动作？
- 上下文：消息是否对应这个版本、系统和用途？重复使用是否正确处理？
- 密钥状态：按政策掌握哪些替换、丢失或失陷信息？
不同应用不必采用相同格式。清单是职责的教学地图，不声称一个签名API完成所有检查。
绿色标记最好说明含义。“在此密钥下签名通过”，远窄于“文档已批准、准确且适合所有用途”。
纸笔练习：四个看起来相似的批准
使用虚构标签“博物馆批准密钥”，不要使用真实密码学材料。假设博物馆只授权它批准内部清单。
情况A：正确签名消息批准第七版用于内部规划，文件也匹配该版本。
情况B：签名数学上有效，但消息批准公开发布。
情况C：消息表示内部批准，提供文件却是第八版。
情况D：签名在陌生发送者提供的另一个密钥下通过；发送者声称该密钥属于博物馆。
哪些检查满足？还存在什么问题？
参考答案
情况A符合指定授权与版本条件，前提是认可密钥和其他政策要求仍然有效。它仍不认证文档每项事实。
情况B通过签名检查，却超出角色权限。
情况C不支持对收到文件的批准。一个版本的有效签名，不应转移到另一个版本。
情况D缺少所提供密钥与博物馆之间的可信绑定。与未知密钥数学上一致，并不足够。
练习把一个简单“已签名”标记可能隐藏的四项问题拆开。
常见问题
公钥可以产生签名吗？
公开验证材料不用于提供私有签名权限。在方案假设下，知道它不应让任意签名伪造变得可行。
核验签名时，必须把私钥发给对方吗？
不需要。公钥验证的设计就是不透露签名秘密。不要为基本公开签名检查提供真实私钥或助记词。
数字签名就是手写签名图片吗？
不是。扫描手写标记是一张图；密码学数字签名是根据消息和验证密钥检查的方案定义值。应用可以展示图片，但图片不是密码学机制。
有效签名能解决所有争议吗？
不能。消息含义、身份、权限、密钥状态与外部事实仍可能有争议。本文解释技术证据，不作法律判定。
资料来源与范围
基础研究参考资料日期为2026年10月12日，时区为新加坡。一手标准与协议文档在准备过程中核查。练习中的人物、文件和密钥标签均为虚构，不使用真实签名凭证。
- NIST FIPS 186-5：数字签名标准，2023年2月3日；实现工作应查看列出的更新。
- W3C可验证凭证数据完整性1.0，2025年5月15日推荐标准：密码学检查周边的证明用途与验证关系。
- NIST SP 800-57第一部分第五次修订版：一般密钥管理生命周期。
- 以太坊交易与账户：一种授权与状态模型。
- 比特币交易：不同的交易和花费条件模型。
密钥、消息、用途和权限都清楚时，签名才最有意义。核验从数学开始，以谨慎而有边界的解释结束。