参考资料

术语表

收录数字签名、证书、令牌、协议和后量子密码领域的 302 个术语，每个术语都用几句话给出定义，并关联到规定它的标准。

显示 302 项中的 302 项

按字母顺序

安

安全级别（安全位数）: 衡量密码强度的指标：s 位表示已知最佳攻击约需 2ˢ 次运算，用于在 AES-128、P-256 和 RSA-3072 等不同算法之间比较密钥长度。

比

比特币地址: 比特币输出脚本的人类可读编码：传统的 P2PKH（1…）和 P2SH（3…）使用 Base58Check，SegWit v0（bc1q…）使用 bech32，Taproot（bc1p…）使用 bech32m。

侧

侧信道攻击: 一种攻击：不从计算的输入和输出入手，而是从计算在物理或时间上的表现——耗时、缓存访问、功耗、电磁辐射或对注入故障的反应——获取秘密信息。

代

代码签名: 用 X.509 证书、平台密钥、OpenPGP 或 Sigstore 对可执行文件、软件包、脚本或固件签名，使操作系统、应用商店和用户能够验证发布者并发现篡改。

点

点压缩: 只用 x 坐标再加上 y 的一位（而不是两个坐标）来编码椭圆曲线点，可使公钥大小减少约一半，代价是解码时需要计算一次平方根。

短

短期证书: 有效期短到可以直接任其过期、不必依赖吊销检查的证书；对于自2026年3月15日起签发的公共 TLS 证书，“短期”指有效期不超过 7 天。

对

对冲签名: 一种签名方式：每次签名的 nonce 由私钥和消息连同全新的随机性一起派生，因此即使随机数生成器或确定性派生过程之一受到攻击，方案仍然安全。

访

访问令牌: OAuth 客户端代表用户或自身调用 API 时向资源服务器出示的凭证，可以是通过内省检查的不透明字符串，也可以是自包含的 JWT。

分

分离签名: 与所签名的数据分开存放的签名，例如 OpenPGP 的 .sig 或 .asc 文件、SSHSIG 文件，或不含封装内容的 CMS 签名，这样原始文件可以保持不变。

复

复合签名: 在同一个密钥和同一个算法标识符下组合后量子算法与经典算法的签名（例如 ML-DSA-65 搭配 ECDSA P-256），只有两个组成部分都验证通过，签名才验证通过。

根

根 CA（根证书）: 自签名的 CA 证书，因内置于验证者的根证书库而被直接信任，是每条证书路径最终都必须到达的信任锚。
根证书库（信任库）: 操作系统、浏览器或运行时在证书路径验证中作为信任锚加以信任的一组根 CA 证书，由制定了自身策略的根证书计划维护。

公

公钥: 非对称密钥对中可以自由分享的那一半，用于验证签名、向对应私钥的持有者加密数据，或与其协商密钥。

构

构建来源证明: 关于制品如何产生的、经过签名且可验证的记录——包括源代码仓库和提交、构建平台、工作流及输入——使用方可据此检查某个包是否来自预期的源代码和流水线。

规

规范化: 在计算哈希或签名之前，把数据转换为约定的唯一字节表示，使语义相同的输入（空白、键的顺序、命名空间前缀或头部折行不同）得到相同的签名输入。

后

后量子密码（PQC）: 为抵御大型量子计算机而设计的公钥算法，例如 ML-KEM、ML-DSA 和 SLH-DSA（FIPS 203～205，2024年），用于取代 RSA、Diffie–Hellman 和椭圆曲线方案。

混

混合密钥交换: 把 X25519 等经典算法与 ML-KEM 等后量子 KEM 结合起来的密钥交换，只要其中任一组件仍未被攻破，会话就能保持机密。

基

基本约束: X.509 扩展（OID 2.5.29.19），其中的 cA 标志表明证书是否属于有权签发其他证书的 CA，可选的 pathLenConstraint 则限制其下最多还能有几级 CA。
基线要求（BR）: CA/Browser Forum 制定的规则，用于规范公开受信任的 TLS 服务器证书的签发和管理，涵盖验证方法、证书配置文件、有效期、吊销和 CA 运营。
基于格的密码学: 建立在高维格困难问题之上的密码学，这类问题包括带误差学习（LWE）问题和短整数解（SIS）问题；它是 ML-KEM、ML-DSA 和 FN-DSA 的基础。
基于哈希的签名: 安全性只依赖哈希函数性质的一类签名方案，由一次性签名和 Merkle 树构建：包括有状态的 LMS 和 XMSS（SP 800-208）以及无状态的 SLH-DSA（FIPS 205）。

降

降级防护: 防止攻击者把同时支持强协议版本或强算法的双方强行降到较弱选项的机制，例如 TLS 1.3 在 ServerHello.random 中设置的哨兵值。

抗

抗钓鱼能力: 身份验证方式的一种特性：仿冒网站无法截获并重放凭证。只要认证器在密码学上把响应绑定到真实的源就能做到这一点，WebAuthn 和客户端证书 TLS 正是如此。

可

可发现凭证（驻留密钥）: 一种 WebAuthn 凭证，其私钥和用户句柄由认证器保存，因此无需服务器先发送凭证 ID 就能找到它，从而实现无需输入用户名的通行密钥登录。
可分辨名称（DN）: X.500 层级名称，用于表示证书的主体和颁发者，由 CN、O、OU、L、ST、C 等属性–值对组成。
可信发布: 在 CI 中用基于 OIDC 的短期凭证代替长期有效的 API 令牌，把包发布到注册表；该机制由 PyPI 于2023年4月推出，npm（2025年7月正式可用）、RubyGems、crates.io 等也已提供。
可信时间戳（RFC 3161）: 从时间戳机构（TSA）获取经过签名的令牌，该令牌把数据的哈希与可信时间绑定，从而可以证明某个签名产生于证书过期或被吊销之前。
可验证凭证: 关于某个主体的一组可检测篡改的声明，由颁发者签名，由主体保存在钱包中，验证者无需联系颁发者即可检查；已有多种标准化格式（W3C VC、SD-JWT VC、mdoc）。

扩

扩展密钥用法（EKU）: X.509 扩展（OID 2.5.29.37），列出证书密钥可用于的应用用途，例如 id-kp-serverAuth、id-kp-clientAuth、id-kp-codeSigning 或 id-kp-emailProtection。
扩展验证（EV）: 最严格的 TLS 证书验证级别，由 CA/Browser Forum 的《EV 指南》定义：CA 要核实组织在法律、实体和运营上的真实存在，并把注册详情写入证书。

盲

盲签: 批准签名设备无法显示其含义的交易或消息（通常只显示哈希或原始 calldata），签名者因此只能信任准备该交易或消息的电脑，而这台电脑可能已被入侵。

门

门限签名: 一类签名方案：私钥分散在 n 个参与方手中，任意 t 个参与方即可共同生成一个与普通签名无异的签名，而人数更少的任何组合都无法得到关于该私钥的任何信息。

密

密码: 由用户记住、由服务器检查的秘密字符串，是最常见也最容易被钓鱼的认证器；NIST SP 800-63B-4 通过长度、黑名单和存储规则而不是复杂度要求来规范它。
密码哈希: 用一种刻意放慢、加盐、最好是内存困难型的函数（例如 Argon2id、scrypt、bcrypt 或 PBKDF2）的输出来存储密码，使被盗的数据库能够抵御离线猜测。
密码敏捷性: 系统无需重新设计即可更换密码算法、密钥长度和参数的能力，依靠协商、配置和密码资产清单来实现；向后量子密码的过渡使它从最佳实践变成了必需。
密码套件: TLS 连接所用密码算法的命名组合；在 TLS 1.3 中，套件名只指定 AEAD 和握手哈希（例如 TLS_AES_128_GCM_SHA256），而 TLS 1.2 的套件名还固定了密钥交换和身份验证方式。
密码学哈希函数: 把任意长度的输入映射为固定长度摘要的函数，要找到原像、第二原像或任何碰撞，在计算上都不可行。
密钥绑定（持有者绑定）: 证明出示凭证的一方掌握凭证中指定的私钥，使复制来的凭证无法被他人重放；SD-JWT 通过密钥绑定 JWT 实现，mdoc 通过设备认证实现。
密钥对: 为某一种非对称算法一起生成、在数学上相互关联的一对私钥和公钥，理想情况下只用于一种用途，例如签名或密钥协商。
密钥或证书指纹: 公钥或证书的简短哈希，用于人工核对或在配置中识别和比较密钥或证书，例如 SSH 密钥的 SHA256:… 或证书 DER 字节的 SHA-256。
密钥交换（密钥建立）: 协议中的一个步骤：双方在不安全的信道上，通过 Diffie–Hellman 密钥协商或密钥封装获得共享密钥，再由它派生出会话密钥。
密钥轮换: 按计划或在发生安全事件后用新密钥替换现有密钥，并在切换期间保证验证照常进行，通常的做法是同时发布新旧密钥。
密钥用法扩展: X.509 扩展（OID 2.5.29.15），用若干位限制证书中的密钥可以执行的操作：digitalSignature、contentCommitment、keyEncipherment、keyAgreement、keyCertSign、cRLSign 等。

名

名称约束: 仅允许出现在 CA 证书中的 X.509 扩展（OID 2.5.29.30），通过由 DNS 名称、IP 地址范围、电子邮件域名和目录名称构成的允许子树与排除子树，限制下级证书可以包含的名称。

批

批量发件人要求（Gmail、Yahoo、Microsoft）: Gmail 和 Yahoo（自2024年2月起）以及 Microsoft（自2025年5月起）对每天发送超过约 5,000 封邮件的发件人强制执行的规则：SPF、DKIM、对齐的 DMARC 记录和一键退订。

签

签名延展性: 签名方案或其编码的一种性质：任何人无需知道私钥，就能把一个有效签名变成同一消息、同一密钥下另一个不同的有效签名。
签名验证: 一种基于公钥的检查：确认签名正是由与给定公钥对应的私钥针对这条消息本身生成的，所用算法由验证者事先选定。

前

前向保密: 一种安全属性：长期密钥（例如服务器证书的密钥）泄露后，过去的会话不会因此暴露；实现方式是用临时密钥交换值派生每个会话的密钥，用完即丢弃这些值。

认

认证器（FIDO/WebAuthn）: 保存 WebAuthn 凭证并生成签名的组件——可以是设备内置的平台认证器、漫游安全密钥，也可以是同步通行密钥的凭证管理器。
认证器数据: 每个 WebAuthn 响应都携带的二进制结构：RP ID 的 32 字节 SHA-256 哈希、一个标志字节、4 字节签名计数器，以及可选的已证明凭证数据和 CBOR 扩展输出。

弱

弱密钥: 实际上比其名义密钥长度所表明的更容易被破解的密钥，原因可能是生成器存在缺陷、熵不足、结构性缺陷（例如 ROCA 的特殊素数结构），或同一密钥在多台设备间重复使用。

数

数字签名: 用私钥根据消息计算出的值，任何持有对应公钥的人都能验证它，从而证明消息未被改动，并且由密钥持有者签名。

私

私钥: 非对称密钥对中保密的那一半，用于签名、解密或密钥协商；任何持有它的人都能以其所有者的身份行事，因此它绝不能在未受保护的情况下离开其信任边界。

算

算法混淆（密钥混淆）: 一种验证缺陷：库让令牌的 alg 头部来选择算法，导致本应用于某种算法的密钥被用于另一种算法，典型例子是把 RSA 公钥当作 HS256 密钥使用。

通

通配符证书: 主题备用名称形如 *.example.com 的证书，可匹配该位置上的任意单个标签，例如 www.example.com，但不匹配 example.com 或 a.b.example.com。
通行密钥（passkey）: 一种 FIDO2/WebAuthn 可发现凭证：绑定到单个网站或应用的密钥对，用设备的生物识别、PIN 或密码解锁，以抗钓鱼的签名取代密码。

椭

椭圆曲线: 有限域上满足 y² = x³ + ax + b 等三次方程的点的集合，配合点加法则构成 ECDSA、EdDSA 和 ECDH 所使用的群。

无

无密钥签名: Sigstore 的签名模型：签名者用 OIDC 身份完成身份验证，为临时密钥获取一张只在几分钟内有效的证书，并依靠透明日志，而无需保护长期有效的私钥。
无效曲线攻击: 一种攻击：对端发送不在约定曲线上的点，跳过点校验的实现就会在一条更弱的曲线上计算，从而一点一点地泄露自己的私钥。

信

信任网: OpenPGP 的去中心化信任模型：用户相互认证对方的密钥，并由每个用户自行决定对认证者的信任程度，而不依赖证书颁发机构。

以

以太坊地址: 20 字节的账户标识符：对于外部账户，它取自 secp256k1 未压缩公钥（64 字节，不含 0x04 前缀）的 Keccak-256 哈希的最后 20 字节，写作 0x 加 40 个十六进制数字。

隐

隐藏数问题: 一种格问题：从大量含噪线性关系中恢复秘密值，每个关系只透露其中少数几位；它能把 ECDSA 和 DSA nonce 中的微小偏差或泄露转化为完整的私钥恢复。

硬

硬件钱包: 一种专用设备：把钱包密钥存放在安全元件或隔离的微控制器中，在自带的屏幕上显示交易详情，并且只在物理确认后才签名。

用

用户验证（UV）: 认证器在本地完成的检查：通过生物识别、PIN 或设备密码，确认获得授权的用户本人在场且身份已识别，结果由 WebAuthn 认证器数据中的 UV 标志表示。

余

余因子: 椭圆曲线上的点数与密码学所用子群的素数阶 n 之比 h = #E / n：NIST P 系列曲线和 secp256k1 为 1，Curve25519 为 8，Curve448 为 4。

预

预哈希签名（HashEdDSA、HashML-DSA）: 对消息的摘要而不是消息本身签名，要么隐式进行（ECDSA、RSA），要么通过 Ed25519ph、HashML-DSA 等显式独立、带域分隔的变体实现。

域

域名验证（DV）: 一种证书验证级别：CA 通过 DNS、HTTP 或 TLS-ALPN 挑战，只验证申请者是否控制证书中的域名，不核实任何组织信息。

原

原始 r‖s 签名格式（IEEE P1363）: ECDSA 或 DSA 签名的定长编码：把 r 和 s 拼接起来，每个值都在左侧填充到群阶的字节长度；JOSE、COSE、WebCrypto 和许多 HSM API 都使用这种格式。

摘

摘要（消息摘要）: 密码学哈希函数对数据计算得到的固定长度输出，用作该数据紧凑且抗碰撞的标识，也是大多数签名方案实际签名的输入。

长

长度扩展攻击: 一种针对 MD5、SHA-1、SHA-256、SHA-512 等 Merkle–Damgård 哈希的攻击：无需知道密钥，仅凭 H(密钥 ‖ m) 和“密钥 ‖ m”的长度，就能算出 H(密钥 ‖ m ‖ 填充 ‖ m′)。

证

证明（WebAuthn）: 认证器在注册时用其证明密钥签名的一份声明，告诉依赖方是哪种认证器创建了凭证，使依赖方能够执行设备策略。
证书（公钥证书）: 颁发者签名的声明，证明某个公钥属于指定的主体，仅在有限时间内、针对规定用途有效，最常见的是 X.509 格式。
证书或公钥固定: 在常规证书链验证之外，通过匹配 CA 密钥、中间证书或服务器自身密钥的哈希，把客户端对某个主机接受的证书或公钥限定在一个固定集合内。
证书链: 从终端实体证书（叶子证书）开始，经过一个或多个中间 CA 证书，直到受信任根证书的有序证书序列，其中每张证书都由下一张签名。
证书路径验证: RFC 5280 §6 定义的算法，用于判断从信任锚到终端实体证书的链是否有效，检查签名、有效期、名称、约束、策略和吊销状态。
证书透明度（CT）: 由公开、只能追加的 Merkle 树日志（RFC 6962）组成的体系，CA 把每张公开受信任的 TLS 证书提交到这些日志中，使域名所有者和监控服务能够发现错误签发的证书。
证书序列号: 在 CRL、OCSP 请求和事件报告中用于标识证书的正整数，在同一颁发者内唯一，长度不超过 20 个八位组。
证书有效期: 证书从 notBefore 到 notAfter 的时间跨度（含首尾两端）；自2026年3月15日起，公开受信任 TLS 证书的最长有效期为 200 天，2027年降至 100 天，2029年降至 47 天。

中

中间 CA: 由根证书或另一个中间 CA 签名的 CA 证书，其密钥负责签发终端实体证书，使根密钥可以保持离线。

主

主题备用名称（SAN）: X.509 扩展（OID 2.5.29.17），列出证书适用的 DNS 名称、IP 地址、电子邮件地址或 URI，也是浏览器匹配服务器主机名时唯一使用的字段。
主体公钥信息（SPKI）: RFC 5280 定义的 ASN.1 结构，把算法标识符与公钥位串组合在一起；每张 X.509 证书内部都使用它，它也是标准的公钥文件格式（-----BEGIN PUBLIC KEY-----）。

自

自签名证书: 颁发者与主体相同且用自身私钥签名的证书，因此只有在被安装为信任锚的地方才受信任。

组

组织验证（OV）: 一种证书验证级别：除域名控制权外，CA 还要核实申请组织的合法存续、名称和地址，并把这些信息写入证书主体。

A

AAGUID（认证器证明 GUID）: WebAuthn 已证明凭证数据中的 16 字节标识符，标明认证器的型号（例如某款安全密钥或某个密码管理器），用于查找元数据和图标。
ACME 续期信息（ARI）: RFC 9773（2025年6月）定义的 ACME 扩展：CA 通过它告诉客户端每张证书应在哪个时间窗口内续期，从而分散负载，并在大规模吊销之前要求提前续期。
ACME dns-01 挑战: ACME 的一种域名验证方法：客户端在 _acme-challenge.domain 发布一条 TXT 记录，其值为 base64url(SHA-256(密钥授权))；这是唯一能验证通配符域名的 ACME 方法。
ACME http-01 挑战: ACME 的一种域名验证方法：客户端在 80 端口的 http://domain/.well-known/acme-challenge/token 上提供密钥授权，CA 从多个网络视角获取它。
ACME（自动证书管理环境）: RFC 8555 定义的协议，最初为 Let's Encrypt 设计：客户端通过挑战证明自己控制相应的标识符，无需人工参与即可从 CA 获取证书。
AEAD（带关联数据的认证加密）: 一种对称加密模式，一次操作即可同时提供机密性和完整性，还能认证未加密的关联数据（例如头部）；RFC 5116 给出了它的通用定义。
AES-GCM: 采用伽罗瓦/计数器模式的 AES（NIST SP 800-38D），是部署最广泛的 AEAD：计数器模式加密，再加上基于 GHASH 的认证，通常使用 96 位 nonce 和 128 位标签。
age（文件加密）: Filippo Valsorda 开发的小巧而现代的文件加密工具和格式（age-encryption.org/v1），可以加密给 X25519、SSH 或后量子混合接收者，也可以用密码短语加密，不含签名，也无需配置。
alg none（未受保护的 JWS）: JWS 算法值 none（RFC 7518 §3.6），表示签名部分为空的未签名令牌；除非验证方明确预期接收未受保护的内容，否则绝不能接受这种令牌。
alg（JOSE 算法头部参数）: JOSE 头部参数，指明 JWS 的签名或 MAC 算法（例如 ES256）或 JWE 的密钥管理算法（例如 RSA-OAEP-256），由 RFC 7518 及后续 RFC 注册。
ALPN（应用层协议协商）: RFC 7301 定义的 TLS 扩展：客户端提供 h2、http/1.1 等应用层协议，服务器在握手中从中选择一个，从而省去一次额外的往返。
APK 签名方案（v1～v4）: Android 的应用签名格式：v1 为 JAR 签名；v2（Android 7.0）和 v3（Android 9，支持密钥轮换）是存放在 APK 签名分块中的全文件签名；v3.1（Android 13）支持定向轮换；v4（Android 11）用于增量安装。
Apple 公证: Apple 对使用 Developer ID 签名的 Mac 软件进行的自动恶意软件扫描：开发者用 notarytool 上传构建产物，Apple 返回一张由 Gatekeeper 检查的票据，该票据可以装订（staple）到应用或安装包上。
ARC（经过身份验证的接收链）: RFC 8617（2019年）定义的实验性协议：处理邮件的每个中间方都记录自己看到的身份验证结果并加上封印，使最终接收方能够信任那些后来因转发或邮件列表而被破坏的结果。
ASCII 装甲: OpenPGP 的一种文本编码：把二进制数据包编码为 base64，置于 -----BEGIN PGP PUBLIC KEY BLOCK----- 和 -----END PGP PUBLIC KEY BLOCK----- 这样的行之间（RFC 9580 §6.2）。
ASN.1（抽象语法记法一）: ITU-T X.680 定义的一种语言，用于独立于编码方式描述数据结构，X.509 证书、CMS、PKCS #8 密钥、OCSP、LDAP 和电信协议都用它来定义。
aud（受众声明）: JWT 的注册声明（RFC 7519 §4.1.3），以字符串或字符串数组的形式指明令牌的目标接收方；每个接收方都必须检查其中包含自己的标识符。
Authenticode: Microsoft 用于 Windows 可执行文件、驱动程序、安装程序和脚本的代码签名格式：对文件哈希签名的 PKCS #7 SignedData，嵌入 PE 证书表中，通常带有时间戳。

B

Base64url: RFC 4648 §5 定义的 URL 和文件名安全的 base64 字母表，用 - 和 _ 替换 + 和 /，在 JOSE 中还会省略 = 填充；JWT 的每个部分都经过 base64url 编码。
Bearer 令牌: 向任何出示者授予访问权限的访问令牌，无需提供任何密钥的持有证明（RFC 6750），通常以 Authorization: Bearer 后接令牌的形式发送。
BIMI（用于消息识别的品牌标识）: 基于 DNS 记录和证书的方案，目前仍是 IETF 互联网草案：已启用强制 DMARC 策略的域名可借此让自己的徽标显示在邮件旁，适用于 Gmail、Yahoo、Apple Mail 等支持该方案的邮箱。
BIP-32（分层确定性钱包）: 比特币标准，用 HMAC-SHA512 和链码从同一个种子派生出一棵密钥树，因此一份备份即可覆盖所有地址，扩展公钥也能在没有私钥的情况下派生收款地址。
BIP-39（助记词）: 一项标准：把钱包的熵编码为取自 2,048 词词表的 12～24 个单词，再用 PBKDF2-HMAC-SHA512（2,048 次迭代）把助记词拉伸为 BIP-32 使用的 64 字节种子。
BIP-137（签名消息格式）: 比特币的消息签名格式，使用 65 字节的可恢复 ECDSA 签名，其头部字节同时编码恢复 ID 和地址类型：27～30 为未压缩公钥的 P2PKH，31～34 为压缩公钥的 P2PKH，35～38 为 P2SH-P2WPKH，39～42 为 P2WPKH。
BIP-322（通用签名消息格式）: 比特币消息签名标准，通过对一笔花费该地址资金的虚拟交易签名，证明对任意类型地址（包括 SegWit、Taproot 和多签）的控制权。
BIP-340（secp256k1 上的 Schnorr 签名）: 比特币规范，定义基于 secp256k1 的 64 字节 Schnorr 签名，采用 32 字节的仅 x 坐标公钥和标签哈希，用于 Taproot 和 Nostr。
BLAKE2: 一族快速哈希函数（BLAKE2b 面向 64 位平台，摘要最长 64 字节；BLAKE2s 面向 32 位平台，摘要最长 32 字节），由 RFC 7693 定义，用于 Argon2、WireGuard、PASETO 和 libsodium。
BLS 签名: 基于配对的签名（Boneh、Lynn 和 Shacham，2001年），签名短小、具有确定性，并原生支持聚合；最主要的应用是以太坊在 BLS12-381 曲线上的权益证明共识。
Brainpool 曲线: 一族参数以可验证方式伪随机生成的椭圆曲线（RFC 5639，2010年），德国及其他欧洲国家的政府规范常用它们来替代 NIST 曲线。

C

C2PA（内容凭证）: 内容来源与真实性联盟制定的标准：在图片、视频、音频和文档中嵌入已签名的来源证明清单，记录内容由谁创建或编辑、使用了哪些工具，包括 AI 生成。
CA（证书颁发机构）: 负责签发证书并对其签名的组织或服务，签发前会核实申请者确实控制证书所要声明的名称或身份。
CA/Browser Forum（CA/浏览器论坛）: 由证书颁发机构以及浏览器和操作系统厂商自愿组成的组织，负责为公开受信任的 TLS、S/MIME 和代码签名证书制定《基线要求》及其他规则。
CAA（证书颁发机构授权）: 一种 DNS 记录类型（RFC 8659），域名所有者用它列出允许为其名称签发证书的 CA；每个公共 CA 在签发前都必须检查该记录。
CBOM（密码物料清单）: 系统中密码资产的机器可读清单，列出算法、密钥、证书、协议和库及其参数，用于规划和跟踪迁移，例如向后量子密码的迁移。
ChaCha20-Poly1305: 把 ChaCha20 流密码与 Poly1305 认证器结合起来的 AEAD（RFC 8439）：256 位密钥、96 位 nonce 和 128 位标签，在没有 AES 硬件支持的环境中用软件实现也很快。
ClientHello: TLS 握手的第一条消息，以明文发送，客户端在其中列出支持的版本、密码套件、组、签名算法、密钥共享以及服务器名称等扩展。
CMS（加密消息语法）: IETF 制定的 PKCS #7 后继标准（RFC 5652），用于已签名数据、数字信封数据和已认证数据，被 S/MIME、Authenticode、PDF 签名、RFC 3161 时间戳以及许多固件格式采用。
CNSA 2.0: NSA 发布的商用国家安全算法套件 2.0（2022年9月），要求美国国家安全系统在2030年至2035年前采用 ML-KEM-1024、ML-DSA-87、LMS 或 XMSS、AES-256 以及 SHA-384 或 SHA-512。
COSE（CBOR 对象签名与加密）: 基于 CBOR、与 JOSE 相对应的标准（RFC 9052 和 RFC 9053），用于签名、MAC、加密和密钥，被 WebAuthn、mdoc 电子驾驶证、CWT 和 C2PA 采用。
cosign: Sigstore 的命令行工具，用于签名和验证容器镜像、blob 和证明：既可以使用密钥，也可以借助 OIDC 身份和短期证书以无密钥方式完成。
CRL（证书吊销列表）: 由 CA 签名并定期发布的已吊销证书序列号列表（RFC 5280 §5），验证者下载后即可检查吊销状态，无需针对每张证书向 CA 查询。
CRLite: Firefox 的吊销机制：把所有记录在证书透明度日志中的证书的吊销状态压缩成紧凑的过滤器，下载到浏览器并在本地查询。
CSPRNG（密码学安全的随机数生成器）: 一种随机数生成器，即使攻击者看到过此前的输出，也无法预测其输出，或将其与真随机性区分开；密钥、nonce、盐和令牌都需要用它生成。
CSR（证书签名请求）: 一种 PKCS #10 消息（RFC 2986），包含主体名称、公钥和所请求的属性，并用对应的私钥签名以证明持有该私钥；CA 据此签发证书。
CTAP（客户端到认证器协议）: FIDO 联盟制定的协议，用于客户端（浏览器或操作系统）与外部认证器之间通过 USB HID、NFC、蓝牙或手机混合传输通信，命令采用 CBOR 编码，例如 authenticatorMakeCredential。
Curve25519: Daniel J. Bernstein 于2005年提出的 Montgomery 曲线 y² = x³ + 486662x² + x，定义在素数 2²⁵⁵ − 19 上，是 X25519 密钥交换的基础，其 Edwards 形式则是 Ed25519 签名的基础。
CWT（CBOR Web 令牌）: JWT 的 CBOR 对应格式（RFC 8392）：声明集被编码为以整数作为声明键的 CBOR 映射，并通过 COSE 签名、MAC 或加密加以保护。

D

DANE（基于 DNS 的命名实体身份验证）: 使用经 DNSSEC 签名的 TLSA 记录（RFC 6698、RFC 7671）声明 TLS 服务必须出示哪张证书或哪个公钥，可以与公共 CA 并用，也可以替代公共 CA。
DER（可分辨编码规则）: ITU-T X.690 中定义的 ASN.1 规范二进制编码，使每个值都只有唯一一种字节表示，因此证书、CSR、CRL、密钥和许多签名都采用 DER 编码。
DID（去中心化标识符）: 形如 did:method:identifier 的 URI（W3C DID Core 1.0，2022年），可解析为列出公钥和服务端点的 DID 文档，由其主体控制，而不是由中心化的注册中心控制。
DKIM 规范化: simple 和 relaxed 两种算法（RFC 6376 §3.4），用于在计算 DKIM 哈希之前规范化邮件的头部和正文；头部和正文可通过 c= 标签分别选择算法。
DKIM 重放: 把一封经过合法 DKIM 签名的邮件原样重新发送给大量新收件人，使其借用签名域名的信誉；DKIM 无法阻止这种做法，因为签名不覆盖 SMTP 信封。
DKIM-Signature 头: 以“标签=值”对的形式承载 DKIM 签名的头部字段（RFC 6376 §3.5），包括 v、a、c、d、s、h、bh、b 以及可选的 i、l、t、x 标签。
DKIM（域名密钥识别邮件）: RFC 6376 定义的邮件身份验证标准：发送方域名对邮件中选定的头部和正文签名，并在 DNS 中发布公钥，使接收方能够验证邮件确实来自该域名且未被篡改。
DMARC: 基于域名的消息身份验证、报告和一致性（RFC 9989，2026年5月）：一种 DNS 策略，要求 SPF 或 DKIM 在与可见的 From 域对齐的前提下通过，并告诉接收方如何处理未通过的邮件。
DMARC 标识符对齐: DMARC 的一项要求：通过 SPF（信封发件人）或 DKIM（d= 域名）身份验证的域名必须与 From 头部中的域名一致，可以完全相同（严格模式），也可以属于同一个组织域（宽松模式）。
DNSSEC: DNS 安全扩展（RFC 4033–4035）：对 DNS 记录集签名，使执行验证的解析器能够检查应答确实来自区域所有者且未被修改，信任链从根区域的密钥开始。
DoH（基于 HTTPS 的 DNS）: RFC 8484 定义的协议：通过 HTTPS 请求承载 DNS 查询和响应（媒体类型 application/dns-message），使通信路径上的观察者无法看到这些内容，并让 Web 应用能够直接解析域名。
DPoP（出示持有证明）: RFC 9449 定义的 OAuth 机制：把访问令牌和刷新令牌绑定到客户端持有的密钥，每个请求都携带一个新签名的 DPoP 证明 JWT，因此仅窃得令牌毫无用处。
DSA（数字签名算法）: FIPS 186（1994年）定义的基于有限域离散对数的签名算法；FIPS 186-5 于2023年停止将其用于生成新签名，只保留用于验证已有签名。

E

ECDH-ES（JWE 密钥协商）: RFC 7518 §4.6 定义的一类 JWE 密钥管理算法：发送方生成临时 EC 密钥，与接收方的静态密钥协商出秘密值，再用 Concat KDF 派生内容密钥。
ECDH（椭圆曲线 Diffie–Hellman）: 一种密钥协商方法：双方各自用自己的椭圆曲线私钥与对方的公钥计算出相同的共享密钥，即 d_A·d_B·G 的 x 坐标。
ECDHE（临时椭圆曲线 Diffie–Hellman）: 每次握手都使用全新密钥对的椭圆曲线 Diffie–Hellman，是为 TLS 提供前向保密的密钥交换方式；在 TLS 1.3 中，它运行在 x25519、secp256r1 等组上。
ECDLP（椭圆曲线离散对数问题）: 已知椭圆曲线上的点 G 和 Q = d·G，求标量 d 的问题；它的困难性是 ECDSA、EdDSA、ECDH 和 Schnorr 签名的安全假设。
ECDSA 公钥恢复: 根据 ECDSA 签名和消息哈希计算出签名者的公钥（SEC 1 §4.1.6）；以太坊和比特币的消息签名用这种方法代替传输公钥。
ECDSA（椭圆曲线数字签名算法）: DSA 的椭圆曲线形式，由 FIPS 186-5 和 SEC 1 规定；其签名是用私有标量和全新的秘密 nonce 计算出的一对整数 (r, s)。
ECH（加密 ClientHello）: RFC 9849 定义的 TLS 1.3 扩展，用发布在 DNS 中的密钥加密真实的 ClientHello（包括服务器名称），网络上只能看到一个共享的公共名称。
ecrecover: 以太坊中位于地址 0x01 的预编译合约（以及 Solidity 的 ecrecover 函数），根据 32 字节哈希和 secp256k1 上的 ECDSA 签名 (v, r, s) 恢复出签名者的地址。
Ed448: 基于“Goldilocks”曲线 Edwards448、使用 SHAKE256 的 EdDSA（RFC 8032 §5.2），安全强度约为 224 位，公钥为 57 字节，签名为 114 字节。
Ed25519: 基于 Curve25519 的 Edwards 形式并使用 SHA-512 的 EdDSA（RFC 8032 §5.1），公钥为 32 字节，确定性签名为 64 字节，安全强度约为 128 位。
EdDSA（Edwards 曲线数字签名算法）: 基于扭曲 Edwards 曲线的 Schnorr 类签名方案，由 RFC 8032 定义并获 FIPS 186-5 批准，两个标准实例是 Ed25519 和 Ed448。
eIDAS: 欧盟关于电子身份识别和信任服务的法规（第 910/2014 号，经 2024/1183 修订），根据该法规，合格电子签名具有与手写签名同等的法律效力。
EIP-155（重放保护）: 以太坊在2016年引入的变更（Spurious Dragon，区块 2,675,000），把链 ID 纳入交易签名哈希和 v 值（v = chainId × 2 + 35 或 36），使为一条链签名的交易在其他链上无效。
EIP-191（签名数据标准）: 以太坊的一项约定：被签名的消息以字节 0x19 和一个版本字节开头，因此永远不可能是有效的交易；版本 0x45 是大多数钱包使用的 personal_sign 格式。
EIP-712（类型化结构化数据签名）: 以太坊中借助域分隔符对类型化结构化数据计算哈希并签名的标准，使钱包能向用户逐个显示字段，签名也无法在不同合约或链之间重放。
EIP-7702（为 EOA 设置代码）: 以太坊的一项升级，自2025年5月7日 Pectra 硬分叉起生效，允许外部账户（EOA）通过类型为 0x04 的交易中的签名授权，把自身代码委托给某个合约。
ERC-1271（合约签名验证）: 智能合约账户验证签名所依据的以太坊标准：验证者调用 isValidSignature(bytes32 hash, bytes signature)，并把返回值 0x1626ba7e 视为有效。
ES256: JWS 中基于 P-256 曲线和 SHA-256 的 ECDSA 算法（RFC 7518 §3.4），签名恰为 64 字节的原始 r‖s 而非 DER，也是 COSE 算法 −7。
EUDI 钱包（欧洲数字身份钱包）: 每个欧盟成员国都必须依据第 2024/1183 号法规（eIDAS 2）向公民提供的身份钱包，以 SD-JWT VC 和 mdoc 格式存放个人身份识别数据和证明。
exp（过期时间声明）: JWT 注册声明（RFC 7519 §4.1.4），以自 Unix 纪元起的秒数表示一个时间点：到达该时间点及之后，不得再接受该令牌。

F

Falcon（FN-DSA）: 基于 NTRU 格的紧凑型格签名方案，于2022年被 NIST 选中，正以 FN-DSA 之名在 FIPS 206 中标准化；截至2026年10月，FIPS 206 仍是草案。
FIDO 元数据服务（MDS）: FIDO 联盟发布的、经过签名的元数据声明源，涵盖已获认证的认证器的 AAGUID、证明根证书、功能和认证状态，用于验证证明。
FIDO2: FIDO 联盟对无密码公钥身份验证方案的总称，由 W3C WebAuthn API 和 FIDO 客户端到认证器协议（CTAP 2.x）组成。
FIPS 140-3: 美国和加拿大的密码模块标准（2019年发布，与 ISO/IEC 19790 保持一致），CMVP 依据它在安全级别 1～4 上验证硬件和软件模块。

G

Git 提交签名: 用 OpenPGP、SSH（自 Git 2.34 起）或 X.509 密钥对 Git 提交和标签签名，使托管平台和代码审查者能够验证它们由谁创建；通过 gpg.format 和 user.signingkey 配置。
Grover 算法: Lov Grover 于1996年提出的量子搜索算法，能在约 √N 步内从 N 个元素中找到被标记的一个，因此最多使对称密钥和哈希原像的有效安全位数减半。

H

HKDF: RFC 5869 定义的基于 HMAC 的“提取-扩展”密钥派生函数，可把 ECDH 输出等共享密钥转换为一个或多个绑定到上下文字符串的均匀随机密钥。
HMAC: RFC 2104 和 FIPS 198-1 定义的带密钥哈希消息认证码，计算方式为 H((K ⊕ opad) ‖ H((K ⊕ ipad) ‖ m))，可向共享该密钥的任何一方证明数据的完整性和来源。
HQC（汉明准循环）: 一种基于编码的密钥封装机制，NIST 于2025年3月11日选定它作为 ML-KEM 的备用方案，计划以 FIPS 207 发布；截至2026年10月，其标准草案尚未发布。
HS256: JWS 算法之一，即使用 SHA-256 的 HMAC（RFC 7518 §3.2）：颁发者与验证者共享同一个至少 256 位的密钥，因此能验证令牌的一方也能签发令牌。
HSM（硬件安全模块）: 一种防篡改的设备或云服务，在自身边界内生成和存储密钥并执行密码运算，因此私钥无法以明文导出。
HSTS（HTTP 严格传输安全）: RFC 6797 定义的 HTTP 响应头：告知浏览器在设定时间内只通过 HTTPS 访问某个主机，出现证书错误时不允许用户点击继续访问，并自动把所有 http:// 链接升级为 HTTPS。
HTTP 消息签名: IETF 标准（RFC 9421，2024年2月发布），用于对 HTTP 请求或响应中选定的组件签名，签名放在 Signature-Input 和 Signature 头部字段中。

I

ID 令牌: OpenID Connect 提供方签发给客户端的 JWT，用于断言用户已通过身份验证，至少包含 iss、sub、aud、exp 和 iat 声明，并由提供方签名。
in-toto: 已从 CNCF 毕业的框架，用于对供应链声明签名；其证明格式是把制品摘要绑定到类型化谓词的 Statement，用于承载 SLSA 来源证明和 SBOM 证明。
iss（颁发者声明）: JWT 的注册声明（RFC 7519 §4.1.1），标识令牌由谁颁发；验证者必须把它与验证签名所用密钥所属的颁发者精确比较。

J

JA4（TLS 客户端指纹）: FoxIO 于2023年提出的 TLS 客户端指纹方法，依据 ClientHello 中的协议、版本、SNI，以及密码套件和扩展的数量与排序后的哈希生成，设计上能在浏览器随机化扩展顺序时保持稳定。
JOSE（JSON 对象签名与加密）: IETF 制定的一系列基于 JSON 的格式，用于签名、加密和表示密钥——JWS、JWE、JWK、JWA 和 JWT（RFC 7515～7519）——也指维护这些格式的工作组。
JWA（JSON Web 算法）: RFC 7518：定义 JWS、JWE 和 JWK 使用的算法标识符和参数，例如 HS256、RS256、ES256、PS256、RSA-OAEP、ECDH-ES 和 A256GCM。
JWE（JSON Web 加密）: RFC 7516 定义的 JOSE 加密内容格式，其紧凑形式由五部分组成——头部、加密密钥、IV、密文和认证标签——并把密钥管理（alg）与内容加密（enc）分开。
JWK 指纹: 以 JSON 规范形式对 JWK 的必需成员计算的哈希（RFC 7638），通常为 base64url 编码的 SHA-256，用作稳定的密钥标识符，出现在 kid 值、DPoP 绑定和 ACME 中。
JWK（JSON Web 密钥）: RFC 7517 定义的密码学密钥 JSON 表示形式：公钥使用 kty、crv、x、y、n、e 等成员，私钥部分则是 d。
JWKS（JSON Web 密钥集）: JSON 对象，其 keys 数组存放公钥 JWK；通常发布在颁发者的 jwks_uri 上，供依赖方验证令牌并跟进密钥轮换。
JWS（JSON Web 签名）: RFC 7515 定义的 JOSE 格式，用于以 JSON 描述参数、经签名或 MAC 保护的内容，可紧凑序列化为 header.payload.signature，也可序列化为包含多个签名的 JSON。
JWT（JSON Web 令牌）: 紧凑且 URL 安全的令牌（RFC 7519），携带由声明组成的 JSON 对象，以 JWS 形式签名或以 JWE 形式加密，用于 ID 令牌、访问令牌和许多 API 会话。

K

Keccak-256: 原始的 Keccak 哈希函数，输出 256 位，采用标准化之前的填充规则，以太坊用它计算地址、函数选择器和待签名哈希；它与 FIPS 202 中的 SHA3-256 不是同一个函数。
KEM（密钥封装机制）: 一种公钥原语：Encaps 根据公钥生成一个随机的共享密钥和一段密文，Decaps 用私钥从中恢复出该共享密钥；在后量子密钥交换中，它取代了 Diffie–Hellman。
key_share 扩展: TLS 1.3 的一个扩展（编号 51），携带客户端针对一个或多个组的临时公开值以及服务器的单个回复，使密钥交换在第一次往返中完成。
kid（密钥 ID）: JOSE 头部参数和 JWK 成员，标明令牌由哪个密钥签名或加密，使验证者在密钥轮换期间能从 JWKS 中选出匹配的密钥。
Kyber（CRYSTALS-Kyber）: ML-KEM 所源自的 NIST 第 3 轮候选方案，早期曾部署在混合 TLS（X25519Kyber768Draft00）中，与标准化后的 ML-KEM 无法互操作。

L

LibrePGP: 由 GnuPG 作者维护的 OpenPGP 规范（draft-koch-librepgp），延续 RFC 4880bis 路线，采用 v5 密钥和自有的 Kyber 复合加密，与 RFC 9580 的 v6 密钥不兼容。
LMS 与 HSS（Leighton–Micali 签名）: RFC 8554 和 NIST SP 800-208 规定的有状态哈希签名方案：由 Winternitz 一次性密钥构成的 Merkle 树可以签名固定数量的消息，HSS 则把多棵树叠加起来，以签名更多消息。
low-S 规范化: 要求 ECDSA 签名的 s 值位于取值范围下半部分（s ≤ n/2）的规则，比特币和以太坊采用它来消除 ECDSA 固有的签名延展性。

M

MD5: Ron Rivest 于1991年设计的 128 位哈希函数（RFC 1321），自2004年起已能找到碰撞，自2007年起已能构造选择前缀碰撞；凡是攻击者能够影响输入的安全用途，它都不安全。
mDL（移动驾驶证）: 以 ISO/IEC 18013-5 mdoc 形式保存在手机上的驾驶证或州身份证件，可通过 NFC 或蓝牙现场出示，也可在线出示；每个数据元素都可单独披露，并由签发机关签名。
mdoc（ISO/IEC 18013-5 移动文档）: ISO/IEC 18013-5 定义的基于 CBOR 的凭证格式，最初为移动驾驶证设计：颁发者在移动安全对象中对每个数据元素的摘要签名，设备则用自己的密钥证明持有该凭证。
Merkle 树（默克尔树）: 一种二叉哈希树：每个内部节点是对其两个子节点计算的哈希，因此一个根哈希就能承诺全部叶子，成员关系或只追加增长都能用对数级大小的证明来证实。
Merkle 树证书（MTC）: 一种正在 IETF 标准化的证书设计：CA 把每次签发都记录到 Merkle 树中，客户端验证简短的包含证明，而不是体积庞大的后量子签名。
ML-DSA（FIPS 204）: FIPS 204（2024年8月）规定的基于模格的数字签名算法，源自 CRYSTALS-Dilithium，是 NIST 主要的后量子签名算法，参数集为 ML-DSA-44、ML-DSA-65 和 ML-DSA-87。
ML-KEM（FIPS 203）: FIPS 203（2024年8月）规定的基于模格的密钥封装机制，源自 CRYSTALS-Kyber，是标准的后量子密钥交换方案，参数集为 ML-KEM-512、ML-KEM-768 和 ML-KEM-1024。
mlkem768x25519-sha256: SSH 的混合密钥交换方法，将 ML-KEM-768 与 X25519 和 SHA-256 组合在一起，由 RFC 10042 标准化，并自 10.0 版（2025年4月）起成为 OpenSSH 的默认方法。
MTA-STS（SMTP MTA 严格传输安全）: RFC 8461 定义的机制：邮件域名通过 HTTPS 发布策略，要求发送方只通过使用有效证书的 TLS 向列出的 MX 主机投递邮件。
mTLS（双向 TLS）: 一种 TLS 用法：客户端也用证书和 CertificateVerify 签名进行身份验证，因此通信双方都要证明自己持有私钥；常用于服务间通信、设备以及 OAuth 发送方约束令牌。
MuSig2: BIP-327 定义的两轮多重签名方案：n 个签名者共同生成一个 BIP-340 Schnorr 签名，该签名在单个聚合公钥下有效，在链上与单个签名者的花费无法区分。

N

NIST 后量子安全类别: NIST 以攻破 AES 或 SHA-2/SHA-3 的难度为参照，为后量子参数集定义的五个强度等级之一：类别 1 ≈ AES-128 密钥搜索，3 ≈ AES-192，5 ≈ AES-256，类别 2 和 4 则以 SHA-256 和 SHA3-384 的碰撞为基准。
NIST IR 8547: NIST 的《向后量子密码标准过渡》（Transition to Post-Quantum Cryptography Standards），是2024年11月发布的首个公开草案，提议在2030年后弃用 112 位安全强度、易受量子攻击的算法，并在2035年后禁用全部此类算法。
nonce（ECDSA 中的 k）: 只使用一次的数；在 ECDSA、DSA 和 Schnorr 签名中，它是每次签名各自的秘密值 k，还必须不可预测且均匀分布。k 一旦泄露或被重复使用，私钥就能被算出。
Nostr: 一种去中心化的社交与消息协议：用户就是 secp256k1 密钥对，每个事件都是一个 JSON 对象，以自身的 SHA-256 哈希作为标识，并用 BIP-340 Schnorr 签名签署。
npm 来源证明: 经过签名的 SLSA 来源证明，附加在从受支持的 CI 发布的 npm 包上（自2023年9月26日起正式可用），把每个包版本关联到它的源代码仓库、提交和构建工作流。

O

OAuth 2.0: RFC 6749（2012年）定义的授权框架：授权服务器向客户端颁发访问令牌，使客户端能够凭借委托的、限定范围的权限调用 API，而无需使用用户密码。
OCSP Stapling: 一项 TLS 功能：服务器为自己的证书获取最新的 OCSP 响应，并在握手中发送给客户端，使客户端无需向 CA 发起会泄露隐私的查询。
OCSP（在线证书状态协议）: RFC 6960 定义的协议：客户端向 CA 的响应器询问某张证书是否已被吊销，并收到一个经过签名、带有效期窗口的答复：正常、已吊销或未知。
OID（对象标识符）: 全球唯一的点分整数序列（例如 1.2.840.10045.2.1），通过逐级委托的注册树分配，在 ASN.1 中用于命名算法、曲线、扩展和策略。
OIDC（OpenID Connect）: 构建在 OAuth 2.0 之上的身份层（OpenID Connect Core 1.0，2014年），客户端借助已签名的 ID 令牌验证用户是谁，并从 UserInfo 端点获取个人资料声明。
OpenID4VP（面向可验证出示的 OpenID）: OpenID 基金会制定的协议（1.0 正式版，2025年7月），验证者通过它向钱包请求凭证并收到出示数据；该协议构建在 OAuth 2.0 之上，已被欧盟数字身份钱包采用。
OpenPGP: IETF 制定的公钥加密与签名标准（RFC 9580，2024年7月），用于消息和文件，密钥由用户自行管理，GnuPG、Sequoia、OpenPGP.js 等都实现了它。
OpenPGP v6 密钥: RFC 9580 引入的密钥格式，采用 32 字节的 SHA-256 指纹、原生 Ed25519/X25519/Ed448/X448 算法和加盐的 v6 签名，取代 RFC 4880 中基于 SHA-1 的 v4 密钥。
OpenSSH 私钥格式: 自 OpenSSH 7.8（2018年）起 ssh-keygen 默认写出的 openssh-key-v1 容器，以 -----BEGIN OPENSSH PRIVATE KEY----- 形式存储，设置密码短语时用基于 bcrypt 的 KDF 加密。

P

P-256（secp256r1）: NIST 定义在 256 位素域上的椭圆曲线，又名 secp256r1 和 prime256v1，安全强度约为 128 位，是 ECDSA 和 ECDH 中部署最广泛的曲线。
P-384（secp384r1）: NIST 的素域椭圆曲线，阶为 384 位，安全强度约为 192 位，是 NSA 的 CNSA 1.0 套件要求使用的曲线，在政府系统和 CA 层级结构中很常见。
P-521（secp521r1）: 最大的 NIST 素域曲线，定义在梅森素数 2⁵²¹ − 1 上，安全强度约为 256 位；JOSE 的 ES512 指 P-521 上搭配 SHA-512 的 ECDSA，而不是 512 位曲线。
PAdES: ETSI 制定的 PDF 签名规范（EN 319 142），用于 eIDAS 下的高级电子签名，基线级别包括 B-B、B-T（带时间戳）、B-LT（嵌入验证数据）和 B-LTA（归档时间戳）。
PASETO（平台无关的安全令牌）: 一种令牌格式，旨在成为比 JOSE 更简单的替代方案，用版本化协议取代可协商的算法：v4.public 令牌使用 Ed25519 签名，v4.local 令牌使用 XChaCha20 加密并以带密钥的 BLAKE2b 认证。
PDF 签名: 嵌入 PDF 文件（ISO 32000-2）的数字签名，其 /ByteRange 覆盖除签名值以外的全部内容，通常是带证书链和时间戳的分离式 CMS 或 CAdES 签名。
PEM: 把 DER 数据编码为 base64、置于 -----BEGIN 标签----- 与 -----END 标签----- 两行之间的文本封装形式；RFC 7468 为 PKIX 对象规定了这一格式，大多数工具都用它存储证书和密钥。
permit（EIP-2612 与 Permit2）: 基于签名的代币授权：用链下 EIP-712 签名授权被授权方转移代币，取代链上的 approve 交易；既可以由每个代币自行实现（EIP-2612），也可以通过 Uniswap 的共享 Permit2 合约实现。
personal_sign: 以太坊的 JSON-RPC 钱包方法，用 EIP-191 版本 0x45 前缀对消息签名，返回 65 字节的 r‖s‖v 签名；是登录和简单消息签名的默认方式。
PIV（个人身份验证）: 美国联邦智能卡标准（FIPS 201-3，2022年）及其卡接口规范（SP 800-73），其中密钥插槽 9A、9C、9D 和 9E 分别存放身份验证、签名、密钥管理和卡身份验证密钥；YubiKey 等硬件令牌都实现了它。
PKCE（代码交换证明密钥）: RFC 7636 定义的 OAuth 扩展：客户端在授权请求中发送随机 code_verifier 的哈希，在令牌请求中发送 code_verifier 本身，因此被截获的授权码毫无用处。
PKCS #1 密钥格式: RFC 8017 附录 A 中仅适用于 RSA 的 ASN.1 结构 RSAPublicKey 和 RSAPrivateKey，在 PEM 中分别存储为 -----BEGIN RSA PUBLIC KEY----- 和 -----BEGIN RSA PRIVATE KEY-----。
PKCS #8: 与算法无关的私钥容器（PrivateKeyInfo，RFC 5208；OneAsymmetricKey，RFC 5958），在 PEM 中存储为 -----BEGIN PRIVATE KEY-----，受密码保护时则为 -----BEGIN ENCRYPTED PRIVATE KEY-----。
PKCS #12（PFX）: RFC 7292 定义的受密码保护的归档格式，通常保存为 .p12 或 .pfx 文件，把私钥与其证书链打包在一起，以便导入浏览器、Windows、macOS、Java 和 Android。
PS256: JWS 算法 RSASSA-PSS，配合 SHA-256 和 MGF1-SHA-256（RFC 7518 §3.5），使用与 RS256 相同的 RSA 密钥，但采用随机化、可证明安全的 PSS 填充。
PSBT（部分签名的比特币交易）: BIP-174（版本 0）和 BIP-370（版本 2）定义的交换格式，包含一笔未签名的交易以及签名者所需的全部数据，使钱包、硬件设备和协调器能够分步骤签名。

Q

QUIC: RFC 9000 定义的基于 UDP 的传输协议，集成了 TLS 1.3 握手（RFC 9001），对几乎所有传输层元数据加密，并承载 HTTP/3。

R

RFC 6979（确定性 ECDSA）: Thomas Pornin 于2013年发布的规范，用 HMAC-DRBG 从私钥和消息哈希派生 DSA 或 ECDSA 的 nonce k，因此签名时不需要随机数生成器。
RS256: JWS 算法 RSASSA-PKCS1-v1_5 配合 SHA-256（RFC 7518 §3.3），历来是 OpenID Connect 提供商的默认算法，签名长度等于 RSA 模数长度（2048 位密钥为 256 字节）。
RSA: Rivest、Shamir 和 Adleman 于1977年提出的公钥密码体制，其安全性基于分解大模数 n = p·q 的困难性，用于签名，历史上也用于密钥传输。
RSA-OAEP: 采用最优非对称加密填充（OAEP）的 RSA 加密（RFC 8017 §7.1），在 JWE 中以 RSA-OAEP（SHA-1）和 RSA-OAEP-256（SHA-256）的形式封装内容密钥，取代了可被攻击的 PKCS #1 v1.5 加密。
RSASSA-PKCS1-v1_5: PKCS #1 v1.5 中确定性的 RSA 签名填充方案（RFC 8017 §8.2），把哈希封装进 ASN.1 DigestInfo 并用 0xFF 字节填充；JWT 的 RS256 即采用它，它也是 X.509 中最常见的 RSA 签名。
RSASSA-PSS: PKCS #1 v2.1 及后续版本中的随机化 RSA 签名方案（RFC 8017 §8.1），用随机盐和 MGF1 掩码函数编码哈希，具有 PKCS #1 v1.5 所缺少的紧致安全性证明。

S

S/MIME: 使用 X.509 证书和 CMS 对电子邮件签名和加密的标准（RFC 8551，S/MIME 4.0），内置于 Outlook、Apple Mail 和 Thunderbird；公共证书受 CA/Browser Forum 的《S/MIME 基线要求》约束。
Safe 多签钱包（Safe 智能账户）: 使用最广泛的以太坊智能合约钱包，只有在达到阈值数量的所有者对交易的 EIP-712 SafeTx 哈希签名后，才会执行该交易；签名可以是 ECDSA 签名、合约签名（ERC-1271）或链上批准。
SAML 2.0: OASIS 制定的 XML 标准（2005年3月），用于在身份提供商与服务提供商之间交换经过签名的身份验证断言和属性断言，至今仍是企业单点登录的支柱。
SBOM（软件物料清单）: 软件中组件、版本、许可证和依赖关系的机器可读清单，主要以 SPDX 或 CycloneDX 格式表示，用于漏洞管理和合规。
Schnorr 签名: 基于离散对数的签名方案（Claus Schnorr，1989年），其响应值 s = r + e·x 关于密钥是线性的，因而安全性证明简洁，并支持批量验证和原生多重签名。
SCT（签名证书时间戳）: CT 日志作出的签名承诺，保证把某张证书或预证书收录进其公开日志；它可以嵌入证书，也可以放在 TLS 扩展或 OCSP Stapling 提供的 OCSP 响应中交付给客户端。
SD-JWT VC: IETF 互联网草案，规定 SD-JWT 在可验证数字凭证中的用法：typ 为 dc+sd-jwt，用 vct 声明表示凭证类型，并定义状态和颁发者密钥发现；是欧盟钱包的两种凭证格式之一。
SD-JWT（选择性披露 JWT）: RFC 9901（2025年11月）规定的格式：颁发者对声明的加盐摘要签名，持有者发送对应的披露项，只披露自己选择的声明，还可以附带密钥绑定 JWT。
SEC 1 ECPrivateKey: SEC 1 和 RFC 5915 定义的椭圆曲线私钥结构，OpenSSL 将其写为 -----BEGIN EC PRIVATE KEY-----，其中存储私钥标量，以及可选的曲线参数和公钥点。
secp256k1: SEC 2 定义的 256 位 Koblitz 椭圆曲线 y² = x³ + 7，由比特币选定，以太坊和 Nostr 也采用它，安全强度约为 128 位。
Secure Enclave（安全隔区）: Apple 在 iPhone、iPad、Mac 和 Apple Watch 芯片中集成的隔离安全协处理器，它生成不可导出的密钥，并在芯片内部完成签名或解密，还可设置为须经 Face ID、Touch ID 或设备密码验证才能使用。
security.txt: 放在 /.well-known/security.txt 路径下的文本文件（RFC 9116），告诉安全研究人员如何向网站所有者报告漏洞。
SHA-1: FIPS 180-1（1995年）定义的 160 位哈希函数，其抗碰撞性已在实践中被攻破，NIST 正逐步淘汰它，到2030年12月31日将在所有密码保护用途中停用。
SHA-2: FIPS 180-4 中的哈希函数族，包括 SHA-224、SHA-256、SHA-384、SHA-512、SHA-512/224 和 SHA-512/256，由 NSA 设计，于2001年发布，如今几乎在所有场合都是默认的哈希算法。
SHA-3: FIPS 202（2015年）标准化的基于 Keccak 的哈希函数族，包括 SHA3-224、SHA3-256、SHA3-384、SHA3-512 以及 SHAKE128 和 SHAKE256 两个可扩展输出函数，采用海绵结构而非 Merkle–Damgård 结构。
SHA-256: SHA-2 家族（FIPS 180-4）中输出 256 位的成员，是 TLS、JWT、X.509、比特币以及大多数文件完整性工具的默认哈希，抗碰撞强度为 128 位，抗原像强度为 256 位。
SHAKE128 和 SHAKE256: FIPS 202 定义的可扩展输出函数（XOF），可以从 Keccak 海绵结构中产生任意所需长度的输出；输出足够长时，安全强度分别为 128 位和 256 位。
Shamir 秘密共享: Adi Shamir 于1979年提出的方案，用随机多项式把秘密拆分为 n 个份额，其中任意 k 个份额即可重建秘密，而任意 k − 1 个份额不会泄露任何信息。
Shor 算法: Peter Shor 于1994年提出的量子算法，能在多项式时间内分解整数并计算离散对数；在大型容错量子计算机上运行时，它将攻破 RSA、Diffie–Hellman、ECDSA、EdDSA 和 ECDH。
SIGHASH 标志: 附加在比特币签名末尾的字节，用于选择签名覆盖交易的哪些部分：ALL（0x01）、NONE（0x02）、SINGLE（0x03），可与 ANYONECANPAY（0x80）组合，另外还有 Taproot 的默认值 0x00。
signature_algorithms 扩展: 一种 TLS 扩展（编号 13）：客户端或服务器在其中列出自己接受的签名方案，例如 ecdsa_secp256r1_sha256、rsa_pss_rsae_sha256 和 ed25519；证书签名则由 signature_algorithms_cert（编号 50）单独涵盖。
Sigstore: 一项开源签名服务：为绑定 OIDC 身份的临时密钥签发证书（Fulcio），并公开记录签名（Rekor），从而无需长期密钥即可对制品签名和验证。
SIWE（以太坊登录）: ERC-4361 定义的以太坊账户登录消息格式：一段人类可读的文本，包含域名、地址、URI、版本、链 ID、nonce 和签发时间，用 personal_sign 签名。
SLH-DSA（FIPS 205）: FIPS 205（2024年8月）中的无状态基于哈希的数字签名算法，源自 SPHINCS+，安全性只依赖哈希函数，代价是签名达到 7.8～50 KB，而且签名速度慢。
SLSA（软件制品供应链等级）: OpenSSF 制定的框架，为构建和源代码完整性定义逐级递进的等级——例如 Build L3 表示来源证明由经过加固的隔离构建平台生成——当前规范为 v1.2（2025年11月）。
SNI（服务器名称指示）: 一种 TLS 扩展（RFC 6066 §3，扩展 0），客户端在其中指明要访问的主机，使一个 IP 地址可以提供多张证书；除非使用加密 ClientHello，否则它以明文发送。
sntrup761x25519-sha512: 将 Streamlined NTRU Prime sntrup761 与 X25519 组合、并用 SHA-512 做哈希的 SSH 密钥交换方法；从 9.0 版（2022年）起是 OpenSSH 的默认方法，直到在 10.0 版中被 mlkem768x25519-sha256 取代。
SPF 10 次查询限制: RFC 7208 的规则：评估一条 SPF 记录时，最多只能触发 10 个会发起 DNS 查询的机制和修饰符（include、a、mx、ptr、exists、redirect），超出则结果为 permerror。
SPF（发件人策略框架）: RFC 7208 定义、发布在 DNS 中的策略，列出哪些主机可以在 SMTP 信封（MAIL FROM 或 HELO）中使用某个域名发送邮件；接收方会对照发起连接的 IP 地址检查。
SSH 证书: OpenSSH 专有的签名声明（不是 X.509），由证书颁发机构（CA）密钥把用户或主机的公钥绑定到主体（principal）、有效期和选项上，从而无需逐个分发密钥。
SSH 主机密钥: SSH 服务器对每次密钥交换签名所用的长期密钥对，用来向客户端证明服务器身份；这些客户端已在 known_hosts 中记录了其公钥，或者信任为其签发证书的 CA。
SSH（安全外壳协议）: RFC 4251～4254 定义的协议，用于经过身份验证的加密远程登录、命令执行、文件传输和端口转发；服务器用主机密钥证明自己的身份，用户则用密钥、证书或密码完成身份验证。
SSHSIG（SSH 签名）: OpenSSH 用 SSH 密钥对任意数据签名的格式（ssh-keygen -Y sign），为每个签名绑定一个命名空间，是 SSH 签名的 Git 提交和 allowed-signers 验证的基础。
STARTTLS: 在 SMTP（RFC 3207）、IMAP、POP3、LDAP 和 XMPP 中把已有的明文连接升级为 TLS 的协议命令；除非有策略强制要求 TLS，否则它可能遭到降级。

T

Taproot: 比特币的一次软分叉，由 BIP-340、BIP-341 和 BIP-342 组成，于2021年11月14日在区块高度 709,632 激活，引入了 Schnorr 签名和 P2TR 输出；P2TR 输出承诺一个密钥以及一棵可选的脚本树。
TLS 1.2: 2008年发布的 TLS 版本（RFC 5246），至今仍被广泛支持；它引入了 AEAD 密码套件和 SHA-256，但需要两次往返，并允许使用 TLS 1.3 已移除的弱选项。
TLS 1.3: TLS 的当前版本，2018年以 RFC 8446 发布，2026年修订为 RFC 9846；握手只需一次往返，强制前向保密，只使用 AEAD 密码套件，握手过程也经过加密。
TLS 会话恢复: 利用之前某次连接的秘密值重新建立 TLS 会话，可以跳过基于证书的身份验证、节省计算量，在 TLS 1.3 中还能携带 0-RTT 数据。
TLS 握手: TLS 连接开始时的消息交换：客户端和服务器在其中协商参数、执行密钥交换、完成身份验证（通常是服务器用证书证明身份），并派生流量密钥。
TLS 证书压缩: RFC 8879 定义的 TLS 1.3 扩展（compress_certificate，27），允许服务器用 zlib、brotli 或 zstd 压缩证书链，通常可以缩小三分之一或更多。
TLS（传输层安全协议）: IETF 制定的协议，用于完成服务器（以及可选的客户端）的身份验证，并加密双方之间的字节流；HTTPS、邮件、API 和大多数其他互联网协议都使用它，当前版本为 1.3。
TUF（更新框架）: 一种安全的软件更新规范，2019年从 CNCF 毕业，把签名职责拆分为 root、targets、snapshot 和 timestamp 四种角色，并为其设定门限和过期时间，使系统在密钥泄露后仍能保持安全。
typ（JOSE 类型头部参数）: 声明整个令牌媒体类型的 JOSE 头部参数，例如 JWT、at+jwt、dpop+jwt 或 kb+jwt，用于显式类型标注，防止有人拿一种令牌冒充另一种令牌。

V

VMC（已验证标志证书）: 用于 BIMI 的 X.509 证书，把域名绑定到已注册商标的徽标，在商标核验和身份核验通过后签发，并在徽标（logotype）扩展中携带 SVG 徽标。

W

Web Bot Auth（Web 机器人身份验证）: IETF 正在推进的一项工作，基于 HTTP 消息签名：爬虫、AI 智能体等自动化客户端用公开发布的密钥对请求签名，使网站能够可靠地识别它们，而不必信任 User-Agent 字符串或 IP 地址段。
WebAuthn（Web 身份验证）: W3C 制定的浏览器 API（带 publicKey 选项的 navigator.credentials.create 和 get），网站通过它在认证器上注册和使用公钥凭证；Level 3 于2026年8月25日成为 W3C 推荐标准。
WKD（Web 密钥目录）: 一种在自己域名的 /.well-known/openpgpkey/ 下发布 OpenPGP 密钥的方式，邮件客户端可以借此通过 HTTPS 获取某个电子邮件地址的密钥（draft-koch-openpgp-webkey-service）。

X

X.509: ITU-T 制定的证书格式，RFC 5280 定义了它在互联网上的配置文件；证书由颁发它的证书颁发机构签名，从而把公钥与主体名称和扩展绑定在一起。
x5c（X.509 证书链头部）: JOSE 头部和 JWK 中的成员，以 base64 编码（不是 base64url）的 DER 证书数组携带 X.509 证书链，第一张证书对应签名密钥。
X25519: RFC 7748 定义的基于 Curve25519 的 Diffie–Hellman 函数，密钥和共享密钥均为 32 字节，用于 TLS 1.3、SSH、WireGuard、Signal 和 age 中的密钥交换。
X25519MLKEM768: TLS 1.3 的混合密钥交换组 0x11EC（RFC 10024），把后量子的 ML-KEM-768 与经典的 X25519 结合在一起，是当前浏览器、OpenSSL 和 Go 默认采用的后量子密钥交换方案。
XAdES: ETSI 制定的 XML 高级电子签名格式（EN 319 132），它在 XML-DSig 的基础上增加了签名时间、证书摘要等已签名属性，以及 B-T、B-LT 和 B-LTA 三个长期级别。
XML 签名（XML-DSig）: W3C 制定的 XML 签名标准（XML Signature Syntax and Processing 1.1，2013年）：ds:Signature 元素通过 URI 引用被签名的数据并将其规范化，再对由各项摘要组成的 SignedInfo 块签名。
XML 签名包装（XSW）: 针对 XML 签名消息的一类攻击：攻击者移动已签名的元素并插入伪造的元素，使签名仍然针对原始元素验证通过，而应用处理的却是伪造内容。
XMSS 与 XMSS^MT: RFC 8391 和 NIST SP 800-208 规定的扩展 Merkle 签名方案（eXtended Merkle Signature Scheme），是一种基于 WOTS+ 一次性密钥构建的有状态哈希签名，另有多树变体，以提供更大的签名容量。
xpub（扩展公钥）: BIP-32 扩展公钥——公钥加链码——可以派生其下所有非强化的子公钥和地址，供观察钱包和支付服务器使用。

#

“先收集后解密”攻击: 一种策略：现在就记录加密流量，等量子计算机能够破解其密钥交换后再解密；这也是在量子计算机出现之前就部署后量子密钥交换的原因。
0-RTT（TLS 早期数据）: TLS 1.3 的一项特性：恢复会话的客户端可以在首轮消息中就发送应用数据，这些数据用之前会话的密钥加密，代价是它们失去重放保护和前向保密。

按字母顺序

安

比

侧

代

点

短

对

访

分

复

根

公

构

规

后

混

基

降

抗

可

扩

盲

门

密

名

批

签

前

认

弱

数

私

算

通

椭

无

信

以

隐

硬

用

余

预

域

原

摘

长

证

中

主

自

组

A

B

C

D

E

F

G

H

I

J

K

L

M

N

O

P

Q

R

S

T

V

W

X

#

按主题

签名 · 52 个术语

JOSE 与 JWT · 39 个术语