ECC 椭圆曲线密码学完整指南

ECC（Elliptic Curve Cryptography）是基于椭圆曲线离散对数问题（Elliptic Curve Discrete Logarithm Problem, ECDLP）的公钥密码体制。它的核心数学对象是一条形如 y² = x³ + ax + b 的椭圆曲线，其上的点可以进行一种被称为「标量乘法」的运算：将一个点 P 与整数 k 反复「相加」，得到新点 Q = k·P。

这种运算的关键性质是：正向计算非常快（O(log k) 次运算），但反向计算不可行——已知 P 和 Q，想要反推 k 在数学上没有有效的多项式时间算法。这就是所谓的「离散对数问题」，也是椭圆曲线密码学安全性的根基。

与 RSA 依赖的「大整数分解」相比，ECDLP 目前没有任何已知的「量子之前」有效攻击。这意味着在同等安全强度下，ECC 的密钥长度可以非常短：256 位 ECC ≈ 3072 位 RSA ≈ 128 位对称密钥。这种短密钥带来的好处显而易见：更小的带宽占用、更快的运算速度、在移动设备和物联网芯片上更容易实现。

一个典型的 ECC 私钥只是一个 256 位的随机整数（32 字节），而公钥是曲线上的一个点（64 字节的 x|y 坐标）。与 RSA 动辄数百字节的密钥参数相比，ECC 在签名/证书/密钥协商协议中的字节体积往往只有 RSA 的 1/10 甚至更小。

椭圆曲线密码学并不只包含一条曲线——实际上，不同的曲线在安全性、性能、专利状况与生态支持方面差异很大。以下是目前工程实践中最常用的几条曲线：

• NIST P-256（secp256r1）：由 NIST 标准化，256 位素数域。它被 Web Crypto API 原生支持，是 TLS 1.2/1.3 握手、X.509 证书、JWT ES256 等最常见的选择。优点是生态成熟；缺点是曲线参数的来源缺乏公开证明（长期存在「后门」疑虑），实现时需谨慎处理侧信道。
• NIST P-384 / P-521：更高安全等级的 NIST 曲线，分别对应 192 位和 256 位的对称安全强度。P-521 因为使用了特殊的梅森素数，实现方式较为特殊，通常在国家级安全或 FIPS 合规场景下使用。
• secp256k1：比特币和以太坊使用的 256 位 Koblitz 曲线。它的参数是公开可验证的（完全透明），曲线结构简单且性能优秀。支持 ECDSA 签名和 ECIES 加密，但不直接适配 Web Crypto API；需要使用 libsecp256k1 或其 JavaScript 绑定。
• Ed25519（Edwards-curve Digital Signature Algorithm）：Daniel J. Bernstein 等人设计的专用签名曲线，基于 Twisted Edwards 形式。它以高速度（签名/验签都在微秒级）、固定时间实现（天然抗侧信道）和简单 API 著称。Ed25519 已被纳入 TLS 1.3、SSH、Signal、Git 签名等主流协议，是当前最被推荐的签名算法之一。
• Curve25519 / X25519：同属 Bernstein 团队设计，专门用于 ECDH 密钥协商。双方交换各自的公钥（32 字节），计算出同一个 32 字节的共享秘密，随后可与 AES-256 或 ChaCha20-Poly1305 配合使用。X25519 是 TLS 1.3 的默认密钥协商方案，几乎所有现代浏览器和服务器都已支持。

选择建议：在大多数系统集成场景下，优先选择 Ed25519 + X25519（签名 + 密钥协商）组合；若需要与 FIPS、Web Crypto 或旧系统兼容，可回退到 P-256；区块链/以太坊相关项目使用 secp256k1；更高安全级别再考虑 P-384/P-521。

ECDH（Elliptic-Curve Diffie–Hellman）是最经典的椭圆曲线应用之一：它允许两个从未交换过密钥的参与方在一条公开可监听的信道上，协商出一个只有他们双方知道的共享秘密。

过程可以简要描述为：

1. 双方各自生成自己的 ECC 密钥对：Alice (a, A=a·G)，Bob (b, B=b·G)；
2. Alice 将公钥 A 发给 Bob，Bob 将公钥 B 发给 Alice；
3. Alice 在本地计算：S = a · B；Bob 在本地计算：S = b · A；
4. 由椭圆曲线标量乘法的性质，两者的结果完全一致：a · (b·G) = b · (a·G) = (ab) · G。

这个共享点 S 的 x 坐标就是双方的共享秘密。在工程实践中，通常会对 S 的原始字节再做一次 SHA-256 或 HKDF 派生，得到一个标准化的会话密钥，然后用 AES-256 或 ChaCha20-Poly1305 对实际通信内容进行加密。

ECDH 的安全性依赖于一个被称为「计算 Diffie–Hellman 假设」（CDH）的难题：即使已知公开点 G、公钥 A、公钥 B，攻击者也无法在多项式时间内算出 ab·G。目前尚未有任何攻击可以有效解决此问题。

ECDH 的典型用途：TLS 握手时的 ECDHE（前向安全版 ECDH）、Signal/WhatsApp 的 Double Ratchet 协议、SSH 会话密钥协商、IPsec/IKEv2 等。Curve25519/X25519 是当前最常用的 ECDH 曲线。

ECC 领域存在两种主流的签名算法：EdDSA（Edwards-Curve Digital Signature Algorithm）与 ECDSA（Elliptic Curve Digital Signature Algorithm），它们在数学细节、实现复杂度、性能与抗侧信道能力上差异显著。

ECDSA（secp256k1 / P-256）：与经典 DSA 类似，但在椭圆曲线上实现。它的签名过程需要使用一个密码学安全的随机数 k——如果 k 被重复使用或可被预测，攻击者可以直接反推出私钥。这种「随机数灾难」在历史上发生过多次（例如 PlayStation 3 的签名漏洞）。实现者必须使用确定性方案（RFC 6979）以避免这个问题。

EdDSA（Ed25519）：基于 Edwards 曲线的设计，使用确定性方式生成 k（从私钥和消息的哈希派生），从根本上消除了随机数故障风险。由于 Twisted Edwards 曲线的特殊结构，EdDSA 的签名和验证可以以固定时间方式实现，几乎无需担心侧信道时间攻击。签名为 64 字节（R || S 两部分，各 32 字节），公钥 32 字节。

两者签名后的编码格式值得特别注意：

• DER 编码（ASN.1）：ECDSA 的常见输出格式。将两个整数 (r, s) 用 ASN.1 SEQUENCE 编码，长度是可变的（r、s 前面的 0x00 填充规则可能因实现而异）。这是 X.509 证书、JWT、TLS 等协议使用的默认编码。
• R || S 拼接（原始 / raw / compact）：直接把 r 和 s 按固定长度（各 32 字节）依次连接，总长度恒为 64 字节。Ed25519 和 libsecp256k1 的原始 API 使用这种格式；它更简单、长度固定，适合作为 API 参数或 JSON 中的字符串传递。

联调时务必确认接口文档中声明的是 DER 还是 R|S 格式，否则验签不会通过。我们的工具同时支持两种格式输出，方便你与不同系统进行对拍。

椭圆曲线本身并不能直接加密任意长度的数据——它擅长的是密钥协商和签名。ECIES（Elliptic Curve Integrated Encryption Scheme）是一种混合加密方案：先用 ECDH 协商出一个一次性的对称密钥，然后用对称加密（通常是 AES-256-GCM 或 ChaCha20-Poly1305）加密实际数据。

ECIES 的基本流程：

1. 发送方生成一个一次性的临时 ECC 密钥对 (r, R = r·G)；
2. 发送方使用接收方公钥 P_recv，计算 ECDH 共享点：S = r · P_recv；
3. 对 S 的 x 坐标使用 KDF（通常是 HKDF + SHA-256）派生出对称密钥和 IV / nonce；
4. 使用 AES-GCM 或 ChaCha20-Poly1305 对明文进行认证加密，得到密文 C 和认证标签 Tag；
5. 最终输出 = 临时公钥 R + 密文 C + 标签 Tag。

接收方的解密过程是反向操作：使用自己的私钥 d 与临时公钥 R 计算 S = d · R。相同的 KDF 派生出相同的对称密钥，随后对密文进行认证解密。

ECIES 与 RSA-OAEP 的最大区别是：ECIES 可以加密几乎任意长度的数据（因为它内部是对称加密），而 RSA-OAEP 的明文长度受到密钥大小和填充开销的严格限制（RSA-2048 最多可加密约 190 字节数据）。因此在需要直接加密较长内容（例如完整的 API 请求体、JSON 对象）时，ECIES 是更合适的选择。

常见的 ECIES 变体：secp256k1 + AES-256-GCM（区块链/加密钱包中常见）、X25519 + ChaCha20-Poly1305（面向移动端与现代协议）、P-256 + AES-128-GCM（面向 FIPS/合规场景）。不同库对 KDF 和 MAC 的约定存在差异，对接第三方系统时需要特别确认 KDF 输入、加密模式和认证标签的位置约定。

在过去十年中，ECC 已从学术研究走向主流生产环境。以下是 7 个最具代表性的真实应用场景：

1. TLS / HTTPS 握手：现代浏览器默认使用 X25519 进行 ECDHE 密钥协商，并使用 ECDSA P-256 或 Ed25519 签名验证服务器证书。这种组合相比 RSA 握手带来了显著的性能提升和更短的证书体积。
2. 比特币与以太坊：均使用 secp256k1 作为签名曲线。交易签名、钱包地址推导（从公钥到地址）、智能合约签名全部建立在 ECDSA over secp256k1 之上。
3. SSH 密钥：OpenSSH 从 6.5 版本开始支持 Ed25519 密钥。与传统的 RSA-4096 相比，Ed25519 私钥文件更小、签名速度更快、抗暴力破解能力更强，是目前 SSH 最推荐的密钥格式。
4. 移动 App 与 Web 签名：iOS 的 App Store 代码签名、Android 的 APK v2/v3 签名都使用 ECDSA。Ed25519 也被用于 Web 端的加密消息、端到端加密聊天（Signal、WhatsApp、Telegram）。
5. 物联网与低功耗设备：Nordic Semiconductor、Espressif ESP32 等物联网芯片在有限的算力下依然可以高效完成 ECC 运算，使得在 MCU 级别实现 DTLS、CoAP 安全通道成为可能。
6. JWT 与开放平台 API 签名：OAuth 2.0 / OpenID Connect 广泛使用 ES256（ECDSA over P-256）、ES384、EdDSA 作为 JWT 的签名算法。相比 RS256（RSA-SHA256），它的签名长度和验签成本都更优。
7. 数字证书与 CA 体系：Let's Encrypt 和其他主流 CA 正在向 ECC 证书迁移。ECC 证书更小、签名更快，是 TLS 1.3 环境下的默认选择。许多大型公司内部 CA 也已经切换到 P-256 或 Ed25519 根证书。

在实际工程中，ECC 的失败原因几乎都与「接口约定不匹配」或「密钥管理不当」有关。以下是高频排错点与可落地的安全建议：

1. 签名编码不匹配（DER vs R|S）：这是最常见的联调失败原因。一方按 ASN.1 DER 格式输出签名（变长，以 0x30 开头），另一方按固定 64 字节的 R|S 格式验签。请在接口文档中明确声明编码格式，并在联调前使用一个已知样本进行交叉校验。
2. 公钥/私钥的 Hex vs Base64 混淆：与签名编码类似，密钥本身也有 Hex 和 Base64 两种常见的文本表示方式。如果一方以 Base64 传输而另一方按 Hex 解析，密钥会完全不同。
3. 曲线不匹配：使用 P-256 的密钥却尝试在 secp256k1 上验签，结果必然失败。请在系统设计之初统一曲线选择，并在 API 字段名中包含曲线标识（如 `pubkey_p256_hex`）。
4. ECDSA 随机数质量：如果使用 ECDSA，必须使用确定性签名（RFC 6979）以避免重复 k 值带来的私钥泄露风险。Ed25519 从算法层面天然地消除了这个风险。
5. ECDH 共享密钥的派生：不要直接把共享点的 x 字节当作对称密钥使用，必须经过 HKDF（HMAC-based Key Derivation Function）进行密钥派生，并在派生时加入双方身份和上下文信息以防止密钥在不同场景中被重用。

在密钥管理方面的最佳实践：

• 私钥必须使用加密容器存储（HSM、AWS KMS、Google Cloud KMS、或至少是密码加密的 PKCS#8 文件），绝不要以明文形式提交到代码仓库或 Docker 镜像。
• 签名密钥与加密密钥分离开。虽然一条曲线在数学上既可以签名也可以加密，但在审计和职责分离角度，建议使用两个不同的密钥对。
• 定期轮换签名密钥。6–12 个月是合理的轮换周期，并在旧密钥失效前预留 1–2 周的交叉期。
• 公钥分发需可信路径。通过 X.509 证书、JWKS 端点或签名方亲自发布的公钥清单进行分发，避免中间人替换。
• 形成纵深防御：在 ECC 的基础上叠加 TLS 1.3、对称加密（AES-GCM / ChaCha20-Poly1305）、认证标签校验，确保每一层都有独立的安全保障。

最后请记住：ECC 的数学安全性与 RSA 相当或更高，但它的优势——短密钥——同时也意味着它对密钥管理流程的要求更高。一个泄露的 256 位私钥和一个泄露的 2048 位 RSA 密钥带来的后果是相同的：攻击者可以伪造签名、解密历史流量。再好的算法也需要严谨的工程实践来保护。