Bab 7 — Kriptografi: Otorisasi, Integritas, dan Bukti yang Dapat Diverifikasi

第七章　密码学：授权、完整性与可核验证据

共同创造需要可以依赖的承诺。参与者不仅需要知道一项决定写了什么，还需要能够检查正在阅读的内容是否被替换，提出行动要求的主体是否满足授权条件，以及一项已经作出的确认能否在日后接受核验。随着合作跨越组织和时间，这些要求不能完全依赖当事人的记忆或某个系统运营者的单方说明。

密码学为其中一部分要求提供了技术基础。哈希帮助检查记录是否与既定摘要对应，数字签名把特定消息与相应签名密钥联系起来，密钥管理则影响这种能力由谁掌握、在何种条件下使用和怎样延续。这些机制使某些判断能够通过计算重复核验，从而进入规则执行过程。

核验的力量来自判断对象的明确。密码学可以严格检查某种关系，却不会因此回答有关共同创造的全部问题。记录保持完整，仍然需要事实依据；签名通过验证，仍然需要理解签署内容和权限来源；组织能够操作账户，仍然需要说明对有关资产和权益负有什么责任。本章从这些衔接关系出发，解释密码学怎样成为制度技术的一部分。

一、哈希与记录完整性

一份制度文件在讨论、批准、传递和执行中，可能存在多个版本。参与者需要知道自己看到的文本，是否就是当时共同采用的文本。仅凭文件名、页数或一句“内容没有变化”，难以完成严格核验。哈希提供了一种对具体数据进行简洁标识和比对的方法。

本节所讨论的密码学哈希，是按照确定的算法，把输入数据映射为相应长度的摘要。同一种算法处理完全相同的数据，会得到相同结果；设计良好的密码学哈希使寻找特定类型的相同摘要关系在计算上十分困难。NIST的安全哈希标准将消息摘要的用途表述为检测消息自摘要生成以后是否发生变化。NIST FIPS 180-4：安全哈希标准〔1〕

可以用一个简短的表达理解核验过程：既定摘要为“哈希（原记录）”，收到材料后重新计算“哈希（待核记录）”，再比较结果。摘要不同，说明在采用相同算法的前提下，两份输入数据不同。摘要相同，则在算法安全性等条件成立时，为两份数据一致提供很强的技术依据。

这里需要保留“在安全条件下”的限定。摘要的取值范围有限，能够输入的数据远多于可能的摘要，因此不同数据得到同一摘要的情况在数学上存在。密码学追求的是使攻击者难以实际找到可以利用的碰撞，或为既定记录构造摘要相同的替代内容。把哈希称为绝对唯一的数字指纹，会掩盖它依赖算法及其安全条件的事实。

记录完整性也有明确的粒度。哈希处理的是实际输入的数据。相同的文字在编码、空格、附件或文件元信息不同的情况下，可能形成不同摘要；两份语义相近的文件，也不会因此具有相同摘要。系统应当明确核验的是原始文件、规范化文本，还是按约定字段组成的结构化记录。

这种输入范围的确定具有制度意义。如果只对正文计算摘要，附件中的权利限制就可能没有进入核验范围；如果只纳入金额而遗漏计量单位和适用期间，就可能无法绑定一项承诺的完整含义。因此，需要先说明参与者实际认可什么，再保证这些内容被准确纳入计算。字段定义和版本规则在这里成为制度与技术之间的接口。

哈希核验还需要一个可信的比较起点。如果攻击者能够同时替换文件和旁边显示的摘要，新的二者仍然能够相互匹配。摘要可以通过独立保存、签名确认或纳入共同账本等方式取得更可靠的参照位置，但保障取决于这些安排是否实际有效。哈希本身不会决定哪一个摘要才是各方应当采用的基准。

这也说明哈希不能独立证明记录的作者和时间。任何获得文件的人都可以计算摘要；一个由提交者自行填写的时间，也不会因为与摘要放在一起就变成可靠时间证据。若需要说明某项材料在特定时点已经存在，必须进一步检查时间来源、记录过程及其可信条件。链上记录也应当按照相应协议解释其顺序与时间含义。

多个记录可以通过哈希形成关联。后一项记录纳入前一项记录的摘要，能够使前后内容相互约束；修改前项后，如果不相应更新后续关联，就会出现不匹配。若攻击者能够重新计算全部关联并替换核验起点，仅有这种结构仍不足以阻止重写。历史难以被单方改动，还需要额外的确认和保存机制。

当需要核验大量记录时，可以把摘要按树形结构逐层组合，形成一个代表相应记录集合的根摘要。默克尔树利用这种方式，使核验者可以根据较少的关联数据，检查某条记录是否被包含在特定根摘要所对应的集合中。根摘要仍需要可靠来源，证明也需要按照明确的树形结构和编码规则核验。RFC 9162：默克尔树与包含性证明〔2〕

包含性证明的结论应当停留在它实际覆盖的范围。证明某条贡献申报进入了某个记录集合，不等于证明全部符合条件的申报都被纳入，也不等于证明这条申报已经通过事实审查。记录是否遗漏，需要结合提交凭据、受理规则和其他核对过程判断。数学上可以核验的包含关系，不能替代制度上应当完整覆盖的范围。

哈希同样不承担加密的功能。摘要通常不能作为还原原文件的工具，但对于候选内容很少、容易猜测的数据，外部观察者可能通过逐一计算候选摘要来比较。因而，只保存摘要不能被普遍理解为已经匿名化或充分保密。公开摘要之前，仍需判断原始信息的可猜测性和关联风险。

在利益相关者资本治理中，哈希适合帮助固定有关判断所依据的材料版本。贡献记录、评价口径、授权文件和批准结果，可以通过明确关联，使核验者知道某次决定究竟使用了哪些材料。形成这种关联的目的，是让后续审查能够回到当时的依据，并识别材料与规则的变化。

材料本身还需要能够取得。保存一份文件的摘要，并没有保存文件的完整内容；原件丢失后，摘要通常无法帮助重建它。组织需要同时安排原始材料的保管、必要披露和长期可读性。证据能被核验与证据能被找到，必须在实际运行中相互配合。

本书据此将哈希的制度作用理解为：为共同采用的具体记录建立可重复检查的对应关系。这种关系有助于约束材料替换和版本混用，却仍需与事实审查、有效批准和证据保存衔接。哈希使“是不是同一份记录”更容易回答，也促使制度设计者更准确地说明需要固定的究竟是什么。

二、数字签名与资产转移授权

记录完整之后，行动要求还需要找到适当来源。系统收到一项资产转移请求时，需要核验它是否满足相应的授权条件，并防止传递过程中关键内容被替换。数字签名为这种核验提供了基础机制。

在常见的公钥签名体系中，私钥用于产生签名，公钥用于验证签名与特定消息的关系。验证者不需要取得私钥，就可以按相应算法检查结果。数字签名也不宜被笼统解释为“用私钥加密、再用公钥解密”；签名算法具有自己的生成和验证过程，其主要用途与信息保密不同。

NIST的数字签名标准将检测未经授权的数据修改、支持签署者认证和提供有关签署行为的证据列为签名的用途。本书进一步强调，其中对现实签署者的识别，需要公钥与主体之间具有可靠的关联；单独的数学验证，首先确认的是消息、签名和公钥之间的关系。NIST FIPS 186-5：数字签名标准〔3〕

对于资产转移，协议需要把这种签名关系与当前状态中的控制条件联系起来。当前状态可以要求某一密钥的签名，也可以要求多个签名或其他验证条件。系统据此检查提出转移的请求，是否满足当前有效的技术授权规则。这里的授权，是协议对可接受行动所规定的条件；其法律意义还需要另行衔接。

资产并不因为签署交易而作为一份秘密文件从私钥中传出。私钥使有关主体能够满足某些状态转换条件；在转移被相应系统接受之后，旧状态所允许的支出被消耗或调整，新状态开始规定后续控制条件。比特币的交易文档以未花费交易输出及其支出条件说明了这一过程：请求引用已有输出，并提交满足其条件的数据，再形成新的输出。Bitcoin开发文档：交易〔4〕

签名需要绑定适当的行动内容。转移对象、数量、接收条件以及其他关键参数，如果没有进入签名实际覆盖的范围，就不能期待该签名阻止这些内容发生变化。不同协议和签名模式覆盖的字段可能不同，不能从“已经签名”推定整项业务的所有条件都受到相同保护。

授权的使用环境也需要被绑定。同一份签署内容，如果在不同系统、不同合约或不同版本中具有不同用途，就可能出现跨环境使用的问题。所谓签名域的区分，就是让签署内容明确联系到预定使用环境，使验证者能够拒绝不属于该环境的授权。

EIP-712对结构化数据签名和签名域作出了规范安排，允许将链标识、验证合约和版本等信息纳入相应结构。该规范同时明确，它本身不提供完整的重放保护。一次授权是否可以再次执行，仍然需要应用处理。EIP-712：结构化数据签名与重放保护边界〔5〕

重放问题揭示了签名与共同状态之间的重要关系。一个有效签名可以被复制，任何获得它的人也可能再次提交。若一项授权只允许使用一次，系统就需要记录它是否已经使用，并检查相应序号、唯一标识或其他防重复条件。签名能够约束消息内容，防止重复执行则需要消息与状态配合。

签名者也可以对相互冲突的请求分别生成有效签名。密码学不会因为某次签署已经发生，就阻止同一密钥再签另一条消息。当两个请求试图消耗同一资源时，需要账本的有效性规则和确认过程决定哪些请求可以进入共同状态。因此，签名是资产转移授权的重要组成部分，转移的排他性还依赖后续机制。

需要进一步区分签署、提交、接受和履行。签名生成后，请求可能尚未提交；提交后，可能因状态变化或条件不足被拒绝；链上接受后，现实中的交付义务也可能仍待履行。系统应当保留这些阶段，避免把一个签名成功提示当作资产和责任关系已经全部完成变动。

对于自动执行而言，签署者理解的内容与机器实际验证的内容应当一致。界面显示“确认参与”，实际消息却包含广泛的资产操作权限，就会使人类理解与技术后果发生严重错位。结构化显示可以改善可读性，但还需要保证显示来源、解析过程和实际签署数据可靠对应。

资本治理中的签名因此需要具有明确用途。确认贡献材料、批准权益分配、授权资源支出和同意规则变更，属于不同的行为。一项确认不能仅因采用了同一把密钥，就被扩张为对其他事项的概括同意。制度需要把签名角色、内容范围和后续效果分别定义，并由系统执行相应限制。

本书主张，将重要签署设计成可以理解的具体承诺表达：参与者能够知道自己以何种角色，对哪个版本的什么事项作出确认，授权适用多久，以及将触发哪些行动。签名把这种表达转化为可核验的数据关系；表达的清楚程度，决定密码学能够为制度保存多完整的依据。

三、密钥保管、恢复与组织控制

数字签名把一部分行动能力集中到密钥及其使用条件上。能够调用签名能力的人，可能无需修改账本规则，就能提出满足技术要求的请求。因此，密钥保管直接影响组织实际控制，必须纳入权责安排。

组织首先需要区分密钥、密钥使用者与权限主体。密钥是一种技术凭据；使用者可能是工作人员、托管机构或自动执行服务；权限主体则可能是组织本身或其他有权主体。三者可以关联，却不能直接合并。工作人员能够操作某个账户，不意味着账户中的资源因此成为其个人资产。

这种关联需要从密钥建立时开始。生成过程是否可靠，初始使用权限怎样授予，公钥通过什么方式与组织及角色对应，都影响后续核验。如果组织只是接收了一份由他人产生、可能仍被他人保留的私钥，就不能仅凭完成交接推定自己已经获得独立控制。

密钥管理还具有持续的生命周期。投入使用、权限调整、停止使用、泄露处置和历史核验，都需要相应安排。NIST的密钥管理建议将不同密钥的保护要求、管理功能和相关信息管理纳入整体框架。这个视角有助于理解：密钥是否安全，取决于它在整个使用期间怎样被产生、调用和维护。NIST SP 800-57 Part 1 Rev. 5：密钥管理建议〔6〕

保管方式需要结合密钥用途选择。日常低额度操作与重大资产处置可以采用不同的调用条件；频繁在线的服务与长期少用的控制权限，也不必承担完全相同的暴露范围。专用设备和受保护的运行环境能够支持相应限制，但组织仍需检查谁能够触发签名、改变设备策略或取得恢复材料。

多人共同管理可以减少对单一持有者的依赖，但需要明确技术形式。多重签名通常由多个独立密钥分别签署，再由账户或协议检查是否满足数量及组合条件。门限签名则可以通过分散的密钥份额协同完成签名运算，在相应安全假设下，无须把完整私钥集中重建后再签署。NIST：多方门限密码学〔7〕

两种方式都可以支持共同控制，但它们呈现的证据可能不同。有些门限方案对外只表现为一个公钥下的普通有效签名，核验者不能仅凭最终签名识别具体由哪些成员参与。若组织需要逐人追责，还应当保存适当的参与和批准记录。对外验证简洁与对内责任清晰，需要分别设计。

多人管理的效果还取决于实际独立性。多个密钥如果由同一人持有，或者多个份额始终受同一管理入口支配，名义上的人数并没有形成相应制衡。另一方面，要求所有成员随时到场，可能使人员变动和暂时失联阻断正常履行。共同控制需要在防止单方滥用与保持必要行动能力之间选择明确条件。

恢复机制尤其需要区分对象。恢复丢失设备中的密钥，可以依赖此前建立的适当恢复材料；在支持权限变更的账户中，也可能通过预先设置的恢复程序，把控制权限转交给新密钥。这两种机制不同，后一种并不要求找回原来的秘密。若密钥材料已经全部丢失，账户又没有可用的替代控制路径，通常无法仅凭真实身份从公钥反推出私钥。

恢复还不能被当作所有签名密钥一律复制备份的理由。备份是否适合，应当结合用途、归责要求和暴露后果判断。复制完整的签名秘密，会增加能够使用该身份生成签名的入口；采用分散保管或替代授权机制，也会引入新的参与者与依赖。组织应当明确所选择的路径及其责任。

因此，恢复权本身是一种重要控制权。能够替换签名者、降低签名门槛或重设账户规则的主体，可能绕过日常签署安排取得实际控制。即使正常操作要求多人批准，如果恢复入口由一个不受约束的管理者掌握，共同控制仍可能被架空。

本书主张，将组织的签署相关权限分别表达，并检查它们是否存在未经说明的相互替代。

这些权限可以由不同主体承担，也可以在明确范围内结合。但任何结合都应当能够解释，不能由一个技术默认设置悄然决定。紧急处理可能需要更快的行动路径，延迟生效可能为异议提供时间；选择何种安排，需要结合实际风险，而不能预设同一种机制适合所有组织。

人员更替时，组织应当更新技术权限，并保存权限交接的依据。收回设备不能证明旧秘密没有副本，内部撤职也不会自动使所有系统拒绝旧密钥。系统需要按其支持的机制移除旧授权、调整验证条件或迁移有关控制，并核对尚未执行的签名请求怎样处理。

如果发生泄露，技术处置与责任调查应当并行。限制后续调用、在可行范围内变更控制和保全有关记录，有助于减少进一步影响；某个请求是否确由有权人员作出，则仍需要检查设备、流程和其他证据。密钥后来失效，也不意味着此前所有签名自动失效，历史行为需要结合当时的权限和证据评价。

长期资本关系还可能超出某种算法和设备的适用期间。NIST于2024年发布的FIPS 204规定了面向后量子安全目标的ML-DSA签名算法，但一种算法标准的存在，并不意味着现有账本已经支持迁移，也不代表安全获得永久保证。NIST FIPS 204：基于模块格的数字签名标准〔8〕

对组织而言，需要保留的是可审查的更新能力：识别正在使用的算法和密钥，说明替换由谁批准，使新旧控制关系能够核对，并维护历史证据的可验证性。延续共同承诺，要求技术凭据可以在有依据的程序中更替，同时使既有权利和责任得到连续处理。

四、有效签名与合法授权的边界

数字签名能够提供重要证据，但证据需要进入具体关系才产生相应意义。本节所说的有效签名，首先指按照指定算法对特定消息验证通过；合法授权则涉及现实主体是否有权就该事项作出相应决定。两者之间需要身份、权限和程序等条件衔接。

可以从四个层次审查一项签署行为：签名是否通过密码学验证，消息是否满足系统当前的接受条件，签署是否具有适当的组织与法律依据，以及有关行为是否已经产生所声称的权利变动。前一层的核验结果可以支持后一层判断，但不能替代后一层所需的材料。

身份关联是第一项重要衔接。公钥可以通过登记、证书、合同安排或其他可靠过程与主体联系，但应当检查关联的来源、范围和有效状态。地址被标注为某个组织，只是提供了一个说明；说明是否准确，需要相应依据。一个主体也可能使用多把密钥，一把组织密钥也可能由多个受托者共同操作。

代表权限是另一项独立条件。工作人员可以具有技术操作资格，却只被允许在特定范围内行动。组织内部的批准、代理或委托关系，需要说明适用事项、期限和必要前置程序。超过内部权限的行为对不同当事人产生何种后果，还需结合适用法律和具体事实判断，不能由系统单一标签代替。

签署内容与意思表示之间同样需要证据联系。设备被盗用、界面误导、自动服务越过委托范围，以及实际签署内容与批准内容不一致，都可能使数学上通过验证的签名面临进一步审查。密码学验证不负责判断签署者是否理解、是否受到不当影响或是否具有相应行为资格。

这并不削弱数字签名的证据价值。它意味着签名证据应当与使用过程共同理解。签署前呈现了什么内容，采用何种身份确认，批准记录对应哪个版本，密钥当时由谁保管，以及异常何时被发现，都可能影响对行为的归责。“不可否认性”所表达的技术目标，不应被解释为任何情况下都不允许提出反证。

数字签名与法律上的电子签名也不完全同义。数字签名是一类密码学技术；电子签名制度可以采用更广的技术中立框架。联合国国际贸易法委员会2001年《电子签名示范法》以技术可靠性、技术中立和功能等同等原则，为各国立法提供参照。它是示范性文本，具体法律效果仍取决于适用法及相应条件，不能把某项密码学标准直接当作普遍生效的法律规则。UNCITRAL：电子签名示范法〔9〕

对于现实资产和组织权益，这些区别尤其重要。一个账户完成有效签署，可以改变链上凭证的控制状态；所映射的权利是否随之变动，还要看凭证表达、有效约定和适用程序。链上原生资产也不能仅凭协议接受某次交易，就对密钥盗用、受托操作或归属争议作出最终法律判断。

在利益相关者资本治理中，贡献确认、资本形成和权益授予应当分别保留依据。一名审核者签署贡献记录，可以证明其对特定材料作出了相应确认；这项确认是否足以产生收益请求权或治理权，需要回到已经有效采用的制度。审核者的签名能力不能把尚未取得的授予权限一并创造出来。

合法授权还具有时间边界。批准时具备的权限，在实际执行时可能已被调整；预先签署的请求，也可能在签署者不再具有相应角色后才被提交。制度需要确定哪些条件以签署时为准，哪些还需在执行时重新检查，并使撤回、到期和已发生效力的处理相互协调。技术能够执行的范围，应当与这些约定对应。

自动代理的参与会使这种时间与范围的区分更加重要。组织可以将一定操作能力交给软件或人工智能代理，但代理生成了有效签名，只能说明有关技术条件得到满足。它实际可以作出哪些承诺，应当来自有效委托，并受到金额、事项、期限及必要复核条件的约束。

本书提出一个面向未来的制度设计方向：将可核验授权从一次性的同意记录，扩展为能够表达委托来源、行动范围、有效期间和撤销状态的持续关系。技术可以帮助检查某次行动是否仍处于委托范围内，人类或组织仍需要对委托的设立、修改和责任承担提供依据。这是一项待检验的设计主张，其价值应当通过越权能否减少、履行能否持续和责任能否追溯来评价。

发生争议时，核验过程应当允许不同结论并存于各自层次：某个签名可以继续通过数学验证，而该行为是否具有适当授权仍待审查；链上状态可以已经改变，而有关责任和救济仍在处理。清楚表达这种状态，有助于各方知道哪些事实已经确定，哪些问题仍需有权程序判断。

由此，密码学为制度提供了一组可重复检查的基础关系：记录是否与既定摘要对应，消息是否满足签名验证，以及行动是否符合已经表达的技术权限。组织和法律制度则进一步说明这些关系涉及谁、依据什么以及产生何种后果。两者衔接得越清楚，技术执行越有可能准确承载共同承诺。

至此，本书已经说明如何固定具体记录、验证签名并安排签名能力的使用。但多个分别有效的请求，仍可能相互冲突；不同参与者也可能暂时看到不同状态。下一章将转向分布式账本，讨论这些请求如何进入共同记录，以及交易验证、顺序与最终性怎样支持可以共同采用的状态。

定稿补强：密码敏捷性、恢复权与法律授权

长期制度不能假定同一套密码算法、参数、密钥和验证软件永久有效。系统应维护密码资产清单，记录算法与参数版本、密钥用途、生成和轮换时间、签名对象、验证环境及退役条件。发生算法风险、密钥泄露或标准迁移时，应设置新旧算法的双轨验证期，保存历史验证所需的版本和时间证据，并明确哪些记录需要重新签署、重新锚定或仅保留原始证明。

多签与门限方案只有在控制要素真正独立时才形成多方约束。多个密钥若由同一人员、设备、云账户或恢复渠道控制，名义上的多方控制仍可能是单点。恢复机制需要写明保管域、阈值变更、替补人员、等待期、见证、异常通知和恢复后的旧权限撤销；恢复权本身不能成为不受监督的超级权限。

密码学上的签名有效，只证明某个密钥对特定数据产生了可验证动作。制度与法律还要分别检查身份、代表权、意思表示、签署范围、撤销状态、时间、保存方式和必要形式。高影响事项应把“签名验证通过”“组织授权有效”“法律形式满足”记录为三个结论，任何一个结论都不能代替另外两个。

本章注释

1. [SRC-006] 美国国家标准与技术研究院（NIST）：NIST FIPS 180-4：安全哈希标准。原文或官方页面

   • 本章引证：NIST FIPS 180-4：安全哈希标准。
   • 支持范围：用于确认标准或技术规范对数据结构、验证条件、协议流程及接口语义的明文规定，本书引用主题包括：NIST FIPS 180-4：安全哈希标准。
   • 使用边界：符合技术规范只说明相应格式或过程条件，不自动证明链下事实真实、权利合法或制度正当。
   • 证据等级：A（原始法律、正式标准、原始研究或正式规范）；链接状态：已完成可访问性核验，核验日：2026-10-08。

2. [SRC-069] RFC Editor：Certificate Transparency Version 2.0（RFC 9162）。原文或官方页面

   • 本章引证：RFC 9162：默克尔树与包含性证明。
   • 支持范围：用于确认标准或技术规范对数据结构、验证条件、协议流程及接口语义的明文规定，本书引用主题包括：RFC 9162：证书透明度协议，第1节、RFC 9162：默克尔树与包含性证明。
   • 使用边界：符合技术规范只说明相应格式或过程条件，不自动证明链下事实真实、权利合法或制度正当。
   • 证据等级：A（原始法律、正式标准、原始研究或正式规范）；链接状态：已完成可访问性核验，核验日：2026-10-08。

3. [SRC-007] 美国国家标准与技术研究院（NIST）：NIST FIPS 186-5：数字签名标准。原文或官方页面

   • 本章引证：NIST FIPS 186-5：数字签名标准。
   • 支持范围：用于确认标准或技术规范对数据结构、验证条件、协议流程及接口语义的明文规定，本书引用主题包括：NIST FIPS 186-5：数字签名标准。
   • 使用边界：符合技术规范只说明相应格式或过程条件，不自动证明链下事实真实、权利合法或制度正当。
   • 证据等级：A（原始法律、正式标准、原始研究或正式规范）；链接状态：已完成可访问性核验，核验日：2026-10-08。

4. [SRC-014] Bitcoin Project：Bitcoin开发文档：交易。原文或官方页面

   • 本章引证：Bitcoin开发文档：交易。
   • 支持范围：用于说明特定协议或项目在当前文档中的运行机制与工程约束，本书引用主题包括：比特币开发文档：交易、Bitcoin开发文档：交易。
   • 使用边界：项目文档描述特定系统，版本、参数与实现可能变化，不能直接外推为所有区块链的一般性质。
   • 证据等级：B（官方机构、协议项目或公共组织发布的说明与指南）；链接状态：已完成可访问性核验，核验日：2026-10-08。

5. [SRC-026] Ethereum Improvement Proposals：EIP-712：结构化数据签名与重放保护边界。原文或官方页面

   • 本章引证：EIP-712：结构化数据签名与重放保护边界。
   • 支持范围：用于确认标准或技术规范对数据结构、验证条件、协议流程及接口语义的明文规定，本书引用主题包括：EIP-712：结构化数据签名与重放保护边界。
   • 使用边界：符合技术规范只说明相应格式或过程条件，不自动证明链下事实真实、权利合法或制度正当。
   • 证据等级：A（原始法律、正式标准、原始研究或正式规范）；链接状态：已完成可访问性核验，核验日：2026-10-08。

6. [SRC-010] 美国国家标准与技术研究院（NIST）：NIST SP 800-57 Part 1 Rev. 5：密钥管理建议。原文或官方页面

   • 本章引证：NIST SP 800-57 Part 1 Rev. 5：密钥管理建议。
   • 支持范围：用于说明公共机构对风险、身份、评估或技术能力的框架性要求，本书引用主题包括：NIST SP 800-57 Part 1 Rev. 5：密钥管理建议。
   • 使用边界：框架提供分析与控制依据，不替代组织对具体事实、成本和责任的独立判断。
   • 证据等级：B（官方机构、协议项目或公共组织发布的说明与指南）；链接状态：已完成可访问性核验，核验日：2026-10-08。

7. [SRC-005] 美国国家标准与技术研究院（NIST）：多方门限密码学。原文或官方页面

   • 本章引证：NIST：多方门限密码学。
   • 支持范围：用于说明公共机构对风险、身份、评估或技术能力的框架性要求，本书引用主题包括：NIST：多方门限密码学。
   • 使用边界：框架提供分析与控制依据，不替代组织对具体事实、成本和责任的独立判断。
   • 证据等级：B（官方机构、协议项目或公共组织发布的说明与指南）；链接状态：已完成可访问性核验，核验日：2026-10-08。

8. [SRC-008] 美国国家标准与技术研究院（NIST）：NIST FIPS 204：基于模块格的数字签名标准。原文或官方页面

   • 本章引证：NIST FIPS 204：基于模块格的数字签名标准。
   • 支持范围：用于确认标准或技术规范对数据结构、验证条件、协议流程及接口语义的明文规定，本书引用主题包括：NIST FIPS 204：基于模块格的数字签名标准。
   • 使用边界：符合技术规范只说明相应格式或过程条件，不自动证明链下事实真实、权利合法或制度正当。
   • 证据等级：A（原始法律、正式标准、原始研究或正式规范）；链接状态：已完成可访问性核验，核验日：2026-10-08。

9. [SRC-071] 联合国国际贸易法委员会（UNCITRAL）：电子签名示范法。原文或官方页面

   • 本章引证：UNCITRAL：电子签名示范法。
   • 支持范围：用于确认有关法律文本、示范规则或数字资产私法原则对所引事项的正式表达，本书引用主题包括：UNCITRAL：电子签名示范法。
   • 使用边界：该文本的适用法域、效力层级和个案适用仍需专业法律判断；引用不构成法律意见。
   • 证据等级：A（原始法律、正式标准、原始研究或正式规范）；链接状态：已完成可访问性核验，核验日：2026-10-08。