4.8 密码学与密钥管理

概述与动机

你构建的几乎每一个系统，已经在依赖密码学（cryptography）（）一门利用数学技术来保护信息、使得只有预期的各方才能读取或信任它的实践。你的 Web 流量走在加密的信道上，你的密码经过哈希处理，你的软件更新经过签名，你的客户数据在磁盘上以加密形式存放。对大多数工程师来说，好消息是没有人要求你去发明这些东西。真正困难的部分不是数学，而是正确地使用经过验证的构建模块，以及最重要的（）管理好这些构建模块所依赖的密钥。

本章是写给非密码学家的工程师看的，也就是我们几乎所有人。你需要足够的理解，才能做出合理的选择，知道每种工具能保证什么，并避免把强大的算法变成一种虚假安慰的那些错误。第 4.3 章（基础设施与云安全）顺带提到了加密和密钥管理；本章会更深入地讨论要加密什么、怎么加密，以及如何运行让这一切真正落地的密钥生命周期。

对大型企业而言，密码学散布在成千上万个服务、证书和密钥当中，一个过期的证书或一个丢失的密钥，就可能导致一个关键系统瘫痪，或者一个数据存储泄露。对政府而言，密码学往往是被强制要求、经过验证并被审计的，数据分类规则精确规定了哪些密钥保护哪些机密，以及谁可以持有这些密钥。在这两种场景下，反复出现的失败原因都是一样的：优秀的算法被松散的密钥管理拖垮。

关键原则

不要自己造密码算法。 使用经过验证、被广泛审查的库和标准算法。新颖的方案往往会以只有专家才能察觉的方式失败。
算法是容易的部分；密钥才是难的部分。 密钥的生命周期，正是大多数现实世界失败真正发生的地方。
了解每一种基本原语能保证什么。 机密性、完整性和真实性是不同的属性，需要不同的工具。
默认在传输中和静态存储时都加密。 让保护成为标准配置，而不是一个可选项。
把密钥托管和数据访问分开。 能够管理密钥的人，不应该自动就能读取该密钥所保护的数据。
为变化做好规划。 算法会变弱，密钥会泄露，标准会演进。从第一天起就为轮换和迁移做好设计。
在重要场合优先选择经过验证的实现。 对于受监管和政府相关的工作，要选择拥有公认验证资质的模块。

建议

不要自己造密码算法

这是黄金法则，值得放在最前面说明。永远不要自己设计加密算法、发明自己的协议，或者照着一篇论文手工实现一个基本原语。看起来能正常工作的密码学，往往隐藏着一些微妙的失败模式（时序旁路、填充预言、弱随机性），这些问题只有经过多年的专家审查才能被发现并存活下来。要使用成熟的库，比如你所用平台的标准密码学模块，或者一个口碑良好的库，并且要在可用的最高抽象层级上使用它们。要选用经过身份验证的加密模式，以及那些把安全选项设为默认值的“简易”接口，而不是自己拼装底层组件。

让基本原语与你所需要的保证相匹配

不同的工具提供不同的保证，混淆它们是一个常见且危险的错误。要了解三大主要类别。

对称密钥（symmetric-key）密码学 使用同一把共享的密钥来进行加密和解密。它速度快，能保护机密性，但通信双方必须事先已经共享这把密钥。AES 是这方面的标准主力。
公钥（public-key）密码学 使用一对在数学上相关联的密钥：任何人都可以持有的公钥，以及你自己保密的私钥。它解决了密钥分发的问题，并支持数字签名，用以证明真实性（谁发送的）和完整性（内容是否被篡改）。
密码学哈希函数（cryptographic hash function） 会为数据生成一个固定大小的指纹，用于完整性校验。哈希是单向的，它不是加密。存储密码时，要使用一种缓慢的、加盐的密码哈希函数，绝不要使用普通的快速哈希（参见第 4.2 章的应用安全内容）。

这里的实践要点是：加密会隐藏数据，但不能证明是谁发送的；哈希能检测篡改，但不会隐藏任何东西。大多数真实系统会把两者结合起来使用，这正是你应该依靠那些把这些正确捆绑在一起的库的原因。

用当前的 TLS 加密传输中的数据

要用传输层安全协议（Transport Layer Security，TLS）来保护每一次网络跳转，这是一种在数据于系统之间移动时保护它的协议。要求使用现代版本的 TLS，禁用过时的版本，选择强密码套件，并正确校验证书，而不是为了“让它先跑起来”就关掉校验。也要加密内部的服务间流量，而不仅仅是公网边界，因为零信任（zero-trust）的姿态要假设内部网络本身就是不可信的。要让证书的签发和续期实现自动化，使 TLS 在任何地方都成为毫不费力的默认选项。

用信封加密来保护静态数据

要默认加密存储的数据：数据库、对象存储、备份和日志。标准的模式是信封加密（envelope encryption）：由数据加密密钥（data encryption key，DEK）来加密实际的数据，再由一个存放在密钥管理服务中的密钥加密密钥（key encryption key，KEK）来加密这个 DEK。这样一来，你就可以轮换主密钥，而不必重新加密数量庞大的数据，并且能把那把威力强大的根密钥留在一个经过加固的边界之内。只在数据旁边存储被包裹起来的 DEK，并在使用时再去获取并解开它。

刻意地运行密钥生命周期

密钥的生命周期，是密码学中真正困难的部分，也是大多数入侵和故障的源头。要有意识地管理每一个阶段：

生成（Generation）： 用一个强随机源，以适当的强度来生成密钥。
分发（Distribution）： 把密钥送到需要它的系统手中，而不把它暴露在代码、配置文件或聊天记录当中。
轮换（Rotation）： 按计划替换密钥，并且要能够在怀疑密钥泄露时快速完成轮换。
吊销（Revocation）： 迅速使被攻陷的密钥或证书失效，并确保各系统会真正遵从这次吊销。
销毁（Destruction）： 安全地淘汰旧的密钥材料，使其无法被恢复。

要使用密钥管理服务（key management service，KMS）来集中管理这一切，并对你保障等级最高的密钥使用硬件安全模块（hardware security module，HSM）（）一种生成并守护密钥、使其永远不会以明文形式离开的防篡改设备。要把谁能管理密钥和谁能读取被保护的数据区分开来，让密钥托管本身来强制实现职责分离。这与第 4.5 章（隐私与数据保护）中的数据分类和托管规则直接相关。

区分机密管理与密钥管理

这两者有所重叠，但并不相同。密钥管理（key management） 管理的是密码学密钥及其生命周期，通常发生在一个替你执行密码学运算的 KMS 或 HSM 内部，原始密钥永远不会离开那里。机密管理（secrets management） 管理的是应用凭据（数据库密码、API 令牌、证书），这些服务需要以明文形式获取并使用，通常来自一个提供短期、可审计访问的机密库（secrets vault）。对密钥要使用 KMS，对凭据要使用机密管理器，永远不要把两者中的任何一个粘贴进源代码或者纳入版本控制的环境文件中。

让 PKI 和证书生命周期自动化

公钥基础设施（public key infrastructure，PKI） 是把公钥与身份绑定在一起的证书颁发机构、证书和信任链所构成的体系。在规模化的场景下，PKI 最主要的风险，是一张证书悄无声息地过期，导致某个服务瘫痪。要维护一份覆盖每一张证书的清单，监控证书的到期情况，并让签发和续期实现自动化，这样就不需要任何人去死记硬背。自动续期的短期证书，要比靠人工照看的长期证书更安全，因为自动化消除了人为的单点故障。这方面的标准协议还支持跨厂商的互操作性（参见第 3.8 章关于互操作性与开放标准的内容）。

为密码学敏捷性和后量子迁移做好准备

算法会随着时间推移而变弱，标准也在不断演进。密码学敏捷性（cryptographic agility） 指的是这样设计系统：让你能够替换算法和密钥长度，而不必经历一次痛苦的重写（）把密码学操作抽象在一个小小的接口背后，给你的加密数据打上版本标记以便知道是哪种算法生成的，并维护一份记录着你在哪里使用了什么算法的密码学清单。这一点在当下尤其重要，因为后量子密码学（post-quantum cryptography）（）一整套专门设计用来抵御未来量子计算机的新算法家族（）已经出现。攻击者今天就可以先收集加密数据，等到以后再去解密，所以长期存在的机密信息需要一份迁移计划。你不需要因此感到恐慌，但你应该清楚自己的资产清单，并在各平台推出经标准化的后量子算法后，随时准备采用它们。

在有要求的地方优先选择经过验证的实现

对于受监管和政府系统来说，仅仅使用一个强算法是不够的；其实现本身也必须经过验证。FIPS 140（Federal Information Processing Standard 140，联邦信息处理标准 140）是美国用于验证密码学模块的标准，许多合同都要求使用经过 FIPS 验证的密码学实现。政府相关工作也可能需要遵循国家层面的指导规范，比如用于涉密系统的 NSA 商用国家安全算法（Commercial National Security Algorithm，CNSA）套件。在开始构建之前，就要先确认适用的具体规范，因为事后再去补装经过验证的模块，成本会非常高昂。这与第 4.6 章中的合规证据和治理内容相关联。

权衡：利与弊

决策	利	弊
由供应商托管的 KMS	简便、集成度高、运维负担低	密钥托管权在供应商手中；直接控制力较弱
客户自管密钥 / HSM	完全掌握托管权，能满足严格的强制要求	运维开销大，存在丢失密钥的风险
自动化的短期证书	不会出现意外过期，能快速吊销	前期需要投入自动化建设
长期证书	简单，活动部件更少	由人工管理的到期时间容易引发故障
信封加密	密钥轮换成本低，能保护主密钥	需要理解更多的活动部件
提前具备密码学敏捷性	未来的迁移成本低	当下需要额外的抽象和设计工作
提早采用后量子算法	保护长期存在的机密信息	工具链尚不成熟，密钥更大，存在一定风险

核心张力在于控制力与运维负担之间的权衡。在 HSM 中自行持有密钥能给你最大程度的托管权，满足最严格的强制要求，但这需要专业能力，还会带来一种全新的灾难性风险：一旦丢失密钥，你就会不可挽回地丢失数据。由供应商托管的服务消除了这种负担，但把托管权交给了供应商。解决办法是分层处理：对大多数系统使用带有合理默认配置的托管服务，而把客户自管密钥和 HSM 留给那些额外的控制力值得付出成本和风险的最高密级数据。

与团队讨论的问题

你们是否拥有一份完整的密钥、证书以及所依赖算法的清单？ 你无法轮换、迁移或审计你看不见的东西，而大多数组织都会发现，散落在各个服务中的密码学材料，远比任何人所追踪到的要多。清单是之后每一个决策的前提条件：证书到期监控、密钥轮换、FIPS 范围界定和后量子规划都依赖于它。拿出你们当前的证书清单和到期日期，问问每一张证书由谁负责，以及一旦它失效会导致什么故障。对于一个规模庞大的资产群来说，诚实的答案通常是根本不存在单一的可信来源，而建立一份这样的清单，正是杠杆最高的第一步。如果你们今天连自己的密码学资产都数不清，那么敏捷性和轮换就只是愿望，而不是真正具备的能力。
你们能否快速轮换或吊销一个被攻陷的密钥，你们真的演练过吗？ 轮换和吊销是密钥生命周期中只有在压力之下才真正重要的部分，团队经常是在事件发生时才发现，某个密钥被硬编码在十几个地方，或者吊销操作根本没有真正传播下去。要确定你们轮换密钥和吊销证书的目标时限，然后在真正需要之前就演练一遍。拿出你们上一次凭据泄露的经历，逐步复盘一下实际操作中轮换需要哪些步骤。对企业和政府系统来说，一次从未演练过的轮换，很可能意味着你不得不在长时间的暴露和一场自己造成的故障之间做选择。如果轮换从未被测试过，就应该假设它其实并不管用。
密钥托管权归属在哪里，它是否强制实现了职责分离？ 能够管理一把密钥的人，和能够读取该密钥所保护的数据的人，不应该是同一个人，因为把这两种权力合并在一起，会悄悄消解静态加密本来的意义。这个选择也决定了你们会使用供应商托管密钥、客户自管密钥，还是 HSM，三者各有不同的控制力和不同的运维风险。拿出你们当前的密钥策略，检查一下是否有任何一个身份能够同时管理某把密钥、又能访问它背后的明文数据，这是一个常见的隐性漏洞。对于受监管和涉密的数据，托管规则可能由数据分类（第 4.5 章）和强制要求来规定。如果托管权和访问权没有被分开，你的加密所提供的保护，就比仪表盘上显示的要弱。
如果保护你信封加密的主密钥丢失或被销毁，你们要如何恢复？ 客户自管密钥和 HSM 赋予你托管权，但也带来了一种新的灾难性故障模式：一旦丢失密钥加密密钥，它所包裹的每一把数据加密密钥都会永久性地变得不可读，连同它们背后的数据一起。要把这一点，与另一个相反的风险（）一份过度宽泛的备份，会悄悄地重新制造出你本想解决的那个托管问题（）放在一起权衡。拿出你们当前的密钥备份和托管安排、每一把主密钥的影响范围，以及证明恢复操作曾经被真正执行过、而不仅仅是被写在文档里的证据。对企业和政府的资产群来说，要把这与你们的数据分类规则关联起来：最敏感的密钥通常禁止随意复制，所以恢复必须经过刻意的设计、按计划测试，并与任何要求证明退役密钥材料已被销毁的监管要求相协调。
你们的系统对后量子迁移准备得如何，哪些长期存在的机密信息会被优先迁移？ 攻击者今天就可以收集加密流量和存档，等到量子计算机成熟之后再解密它们，所以任何必须保持数年机密性的信息，其实已经暴露在一个你看不见的未来面前。与此相对的压力是，后量子工具链仍然年轻，密钥更大，而过早行动则有押注在一个尚未稳定就会变化的算法上的风险。拿出你们的密码学资产清单、一份按需要保持机密的时长排序的机密信息列表，以及对你们的架构能否在不重写的情况下替换算法的诚实评估。对于政府和受监管的工作，那些具有数十年机密性要求的记录，会让这个问题变得切实具体，而不是纸上谈兵，采购流程可能很快就会要求提供一份有文档记录的迁移计划，并支持经标准化的后量子算法。
当法规要求使用经过验证的密码学实现时，你们是否清楚具体哪些模块在范围之内、它们是否真正符合资质？ 使用一个强算法，和使用一个经过验证的实现，并不是一回事，团队经常是到很晚才发现，某个库、某种语言运行时，或者某个云服务，并不在合同所要求的 FIPS 140 边界之内。这里的张力在于，经过验证的模块在功能和速度上，可能会落后于最新的库，所以选择它们会在工程层面对你们的技术栈造成实际的约束。拿出每个受监管系统实际调用的密码学模块清单、覆盖它们的验证证书，以及适用的具体强制要求（FIPS 140、CNSA，或某个行业规则）。对企业和政府项目来说，要在构建之前就做出这个决定，因为事后再去补装经过验证的模块、重新为一个系统授权，成本高、速度慢，而且往往会迫使你重新设计那些你原以为已经完成的组件。

行业视角

初创企业。 要完全依靠你所用平台经过验证的默认配置，不要在自定义密码学上花费任何工程时间。开启托管的静态加密，用自动续期的证书来终结 TLS，用一个标准的缓慢函数来哈希密码，并把机密信息保存在平台的机密管理器中，而不是代码仓库里。你唯一要做的设计决策，是在应用中围绕那少数几个需要加密的字段建立一层薄薄的接口，这样将来即便要脱离供应商托管的密钥，也不需要重写。

小型企业。 你没有密码学专家，也没有太大意愿去运维一个 HSM，所以要选择购买托管服务，而不是自己搭建：使用云服务或 SaaS 工具自带的、由供应商托管的 KMS 和机密管理器。把这项工作定位为基础卫生工作，也就是说，代码里没有密钥、加密在各处默认开启、证书到期受到监控，不会出现意外失效。只在合同或监管机构确实要求的极少数数据上，才保留客户自管密钥。

企业。 问题在于要在成千上万个服务、证书和密钥之间实现规模化和一致性。要运行一个带信封加密的集中式 KMS，让整个证书生命周期自动化，使得没有任何一次到期是靠人工照看的，并维护一份单一的密码学清单，为轮换、FIPS 范围界定和后量子规划提供输入。要把密钥托管和数据访问的分离作为一项组织级别的控制措施，让加密成为每个团队都能直接继承的平台能力，而不是每个团队各自重新发明的任务。

政府。 采购、验证和审计塑造着每一个选择。要使用经 FIPS 140 验证的模块，对于涉密系统要遵循 CNSA 等国家层面的指导规范，把密钥托管与数据分类挂钩，使最敏感的密钥掌握在受过安全审查的人员手中，并在严格的职责分离下运作，同时持续生成经验证密码学实现的证据，以支持持续性的授权。要为那些必须保持数十年机密性的记录制定后量子迁移计划文档，并要求供应商在你们做出承诺之前，披露哪些模块已经通过验证。

示例

初创企业。 一支开发健康追踪应用的小团队，完全依靠经过验证的默认配置。他们用自动续期的证书来终结 TLS，用供应商的 KMS 在其托管数据库和对象存储上启用静态加密，并使用标准库中一个缓慢的、加盐的函数来哈希密码。他们没有自己编写任何密码学代码，而是对应用中那一个必须加密的字段，使用了一个高层级的、带身份验证的加密调用。机密信息保存在平台的机密管理器中，从不出现在代码仓库里。这只花费了几个下午的时间，却消除了整整一类灾难性错误。

企业。 一家全球性银行运行着一个集中式 KMS 和一批 HSM，并维护着一份密码学清单，追踪着成千上万个服务中的每一把密钥和每一张证书。信封加密保护着客户数据，数据密钥由按计划轮换的主密钥包裹，而数据本身则原地不动。在一次面向公众的故障事件让他们体会到一张过期证书的代价之后，证书的签发和续期实现了完全自动化。密钥管理员是一个独立于应用工程师的团队，所以托管权强制实现了职责分离，一层密码学敏捷层还让他们能够开始为长期存档试点后量子算法。

政府。 一个负责处理涉密记录的国家机构，只使用经 FIPS 140 验证的密码学模块，并针对其最高密级的系统遵循 NSA 的 CNSA 指导规范。密钥在从不释放明文密钥材料的 HSM 中生成和持有，托管权与数据分类挂钩，使得最敏感的密钥掌握在受过安全审查的人员手中，并处于严格的职责分离之下。证书运行在一个带自动化生命周期的托管内部 PKI 上，经验证密码学实现的持续证据，为该机构的持续性授权提供支撑。一份有文档记录的后量子迁移计划，保护着那些必须保持数十年机密性的记录。

商业论证：动机、投资回报率与总拥有成本

密码学是另一个“适度投入即可防止灾难性、登上头条级别损失”的领域。总拥有成本包括一个 KMS 或 HSM、机密和证书管理工具，以及用于设计生命周期并保持清单最新的工程时间。这些成本是真实存在的，但也是有边界的。而跳过这些工作的代价，则是未加密数据遭到泄露、因证书过期而导致的数小时级故障，或者因密钥处理不当而造成的不可挽回的数据丢失，每一种都伴随着监管罚款、通知成本以及持久的声誉损害。

最强的投资回报来自自动化和复用。自动化的证书生命周期消除了最常见的那种自己造成的故障。带合理默认配置的集中式密钥管理，意味着每一个新服务都能无须任何团队级别的额外努力，就继承传输中和静态数据的加密能力，从而把密码学从一项反复出现的税负，变成一种平台能力。对受监管和政府相关的工作来说，经过验证的模块和自动化的证据，也会降低审计和授权的成本。向领导层说明这一点时，要讲得直白：算法是免费的、久经验证的，风险存在于密钥管理和证书运维之中，而在那里进行一笔小额的自动化投入，就能防止代价高昂的失败。

反模式与陷阱

自己造密码算法。 自定义算法或手工搭建的协议，会以只有专家才能察觉的微妙方式失败。
硬编码的密钥和机密信息。 凭据被粘贴进源代码、配置文件或聊天记录中，在那里既会泄露，又无法被轮换。
加密了却没有密钥纪律。 开启了加密，却让密钥访问权限大开，或者从不进行轮换。
把哈希和加密混为一谈。 把哈希当作可逆的操作，或者用一个快速哈希、而不是缓慢加盐的哈希来存储密码。
证书轮盘赌。 没有清单，没有到期监控，某张证书失效时会周期性地带来意外故障。
密钥托管与数据访问合二为一。 同一个身份既能管理密钥，又能读取该密钥所保护的数据。
没有轮换计划。 从未被轮换过、在压力之下也无法快速轮换的密钥。
缺乏敏捷性的密码学。 算法被嵌入得如此之深，以至于替换它需要一次重写，从而阻碍未来任何一次迁移。
忽视验证方面的强制要求。 在需要 FIPS 或类似验证的场合，却在未经验证的模块中使用强算法。

成熟度模型

第 1 级，启动： 加密应用不一致，往往是缺失的，只有在有人注意到缺口时才被动补上。密钥和机密信息被硬编码，或者通过聊天记录和配置文件非正式地共享。没有清单，没有轮换，证书会意外过期，团队偶尔还会自己编写密码学代码。
第 2 级，发展： 主要系统已经开启了 TLS 和静态加密，也存在一个 KMS 或机密管理器，但采用情况参差不齐，因团队而异。部分证书受到监控，其余则没有，轮换是手动且罕见的，也没有一份完整的密码学清单把这一切串联起来。
第 3 级，标准化： 传输中和静态数据的加密是全组织统一执行的书面默认配置。密钥存放在带计划轮换和信封加密的 KMS 中，密钥托管与数据访问相分离，证书生命周期已实现自动化，维护着一份密码学清单，并在监管有要求的地方一律使用经过验证的模块。
第 4 级，管理： 密码学资产群被以数据的方式衡量并与基线进行对比控制。你们追踪证书到期的提前预警时间、按计划轮换的密钥比例、吊销一把被攻陷密钥的平均耗时、每个周期内检测到的代码内机密信息数量，以及清单覆盖率，并将这些指标与目标进行对照审查。轮换和吊销会按固定节奏演练并记录用时，偏差会触发纠正措施，而不是被悄悄忽略。
第 5 级，协同优化： 密码学是每个服务都默认继承的平台能力，并在整个组织内持续改进和整合。轮换和吊销既快速又被常态化地演练，HSM 保护着保障等级最高的密钥，密码学敏捷性加上一份正在推进的后量子迁移计划，让这一资产群能够随算法和强制要求的变化而持续适应。合规证据被自动生成，并为持续性的授权提供支撑。

讨论话题

考虑到运维成本和灾难性损失的风险，你们资产群中的哪些系统真正值得使用客户自管密钥或 HSM？
你们要如何为自己拥有的每一把密钥和每一张证书，构建并维护一份单一的可信来源？
你们今天轮换一把被攻陷密钥的现实所需时间是多少，是什么让它变慢的？
在你们的架构中，哪些地方让替换一种密码学算法变得困难，在被迫迁移之前，你们要如何修复这一点？
在你们那些长期存在的机密信息中，如果对手现在就把它们收集起来、几年后再解密，哪些会真正造成影响？
机密信息和密钥有没有可能最终出现在代码、配置或日志当中，你们又要如何知道这一点？

关键要点

不要自己造密码算法。 要在最高的安全抽象层级上使用经过验证的库和标准算法。
算法是容易的；密钥管理才是难的。 密钥的生命周期（生成、分发、轮换、吊销、销毁）正是真实故障发生的地方。
了解你所获得的保证： 对称加密和公钥加密保护机密性，签名证明真实性和完整性，而哈希能检测篡改，但它不是加密。
用当前的 TLS 加密传输中的数据，用信封加密加密静态数据，将其作为每个系统的默认配置。
把密钥托管和数据访问分开，对密钥使用 KMS，对凭据使用机密管理器，两者都绝不能硬编码。
让证书生命周期自动化，以消灭意外过期导致的故障，并维护一份密码学清单。
为密码学敏捷性做好设计，并为长期存在的机密信息启动一份后量子迁移计划。
在监管或涉密要求存在的地方，优先选择经过验证的实现（FIPS 140 及适用的国家层面指导规范）。

参考文献与延伸阅读

National Institute of Standards and Technology，FIPS 140-3: Security Requirements for Cryptographic Modules。
National Institute of Standards and Technology，SP 800-57: Recommendation for Key Management。
National Institute of Standards and Technology，SP 800-131A: Transitioning the Use of Cryptographic Algorithms and Key Lengths。
National Institute of Standards and Technology，后量子密码学标准（FIPS 203、204 和 205）。
Niels Ferguson、Bruce Schneier 和 Tadayoshi Kohno，Cryptography Engineering。
Jean-Philippe Aumasson，Serious Cryptography。
David Wong，Real-World Cryptography。
Internet Engineering Task Force，RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3。
Open Web Application Security Project，Cryptographic Storage Cheat Sheet 与 Transport Layer Protection Cheat Sheet。
National Security Agency，Commercial National Security Algorithm (CNSA) Suite 指导规范。