ECC，三个字母，在三种不同的圈子里聊起来会得到三种完全不同的答案。做服务器运维的同事脱口而出“纠错码内存”，做ERP实施的顾问马上想到SAP ECC，而做安全或研发的人会条件反射地补一句：椭圆曲线密码学。我这些年在这三个领域都实际接触过，说实话，这个缩写最容易让刚入门朋友产生交叉误会，但最值得花时间搞清楚的，是加密领域的那个 ECC，也就是 Elliptic Curve Cryptography。
这篇文章我不会从RSA的历史讲起，也不会复制教科书式的数学证明。我想从一个工程人员的角度，把ECC为什么省密钥、怎么用OpenSSL生成和签发证书、ECDH和ECDSA在TLS里怎么落地，以及我在多个项目里踩过的兼容性坑都过一遍。无论你是后端研发、运维、安全工程师，还是第一次接触密码学的新手，读完都能知道：什么时候该用P-256，什么时候被要求P-384，以及怎么让一台服务器真正跑起ECC证书。
1. 三个字母ECC，三种截然不同的世界
1.1 内存纠错与企业ERP都不是这篇文章的主角
如果你买过服务器，一定在内存规格里见过“ECC”这个标签。这里的ECC是Error Correcting Code，纠错码内存，常见于DDR4 Registered ECC，多了一颗校验颗粒，能纠正单比特错误、检测双比特错误，对长时间稳定运行的服务而言相当重要。
如果你在制造业或大型企业做过IT，那“ECC”多半指SAP ERP Central Component，也就是SAP的ERP核心组件，旧称R/3。很多公司的财务、物料、销售模块都跑在上面，那些被反复提起的LSMW操作、ABAP程序、IDoc报文配置，都在这个系统里转。LSMW全称Legacy System Migration Workbench，是SAP里做历史数据迁移的标配工具。
这两种ECC都很值钱，但它们和这篇文章无关。当你看到“ECC”出现在证书申请、TLS配置、Nginx参数、代码签名或区块链签名里，那说的就是椭圆曲线密码学。这也是我接下来要展开的方向。
1.2 为什么椭圆曲线加密是当下最值得掌握的公钥技术
一句话：同样的安全强度，ECC用的密钥比RSA短得多。RSA-2048目前还在大量使用，但TLS握手时要承担更重的CPU负载；而椭圆曲线用256位密钥就能达到约128比特的安全强度，对应到RSA至少要3072位。密钥短，意味着证书体积小、握手包小、计算量小、功耗低。
这对三类场景特别重要：
- HTTPS公网服务：高并发网关上做ECDHE握手，CPU占用明显低于RSA；
- IoT和移动端：芯片弱、内存小，ECC让它跑得动加密；
- 区块链和智能卡：签名数据短、验证快，链上每笔交易都能省出真金白银的空间。
我从2018年开始把系统的TLS证书从RSA-2048逐步迁到ECDSA P-256，最直观的感受是：握手时服务端CPU曲线变平了，证书体积从1KB多降到500字节上下，浏览器地址栏看不出区别，但监控不会骗人。
1.3 这篇博文会给你什么
我不会只讲概念，也不会一股脑丢公式。读完并动手做完这几步，你会具备这些能力：
- 用OpenSSL生成EC私钥、CSR和自签名证书；
- 理解ECDH密钥交换和ECDSA数字签名的基本流程，能看懂TLS抓包里的曲线协商；
- 知道Nginx里
ssl_ecdh_curve怎么配，为什么P-256、P-384、X25519这些词总混在一起出现； - 面对“必须用P-384证书”的合规需求时不慌，知道签发的证书长什么样、要交给谁；
- 避免我在生产环境踩过的那些兼容性大坑。
2. 椭圆曲线的数学直觉：曲线、群和那道难题
2.1 从一杯咖啡理解椭圆曲线的几何运算
椭圆曲线不是椭圆，是一条形如 y² = x³ + ax + b 的光滑曲线，画出来像一根微微倾斜的波浪线。之所以叫椭圆曲线，是因为计算椭圆周长的积分最后会用到这类曲线方程，名字是历史遗留，和视觉上的“椭圆”没什么关系。
密码学用到的不是整条连续曲线，而是曲线上的一系列点。这套体系的灵魂是“点加法”。规定一种几何操作：取曲线上两个点 P 和 Q，画一条直线穿过它们，这条直线还会和曲线交于第三个点 R'；把 R' 关于 x 轴镜像，得到的点 R 就定义为 P + Q。
如果 P 和 Q 是同一个点，就把“过该点的切线”当作那条直线，切线与曲线交于另一个点，再镜像，得到 2P。这个操作叫倍点。反复做下去，3P、4P、5P……都能算出来。
你可以把点加法想象成咖啡杯上的加法：两颗豆子“相加”不是简单堆在一起，而是经过一条固定的几何规则得到一颗新豆子。曲线上所有点加上这个加法规则，构成一个群，再补上一个特殊的无穷远点 O 当作“零元素”，整个结构就完整了。
2.2 有限域上的“整数世界”：所有运算都在模p空间
几何直觉只在实数平面上成立，但密码学需要的是计算机能精确计算的离散结构，所以工程里的椭圆曲线定义在有限域上。最常用的是大素数 p 的模域 F_p，也就是集合 {0, 1, 2, ..., p-1}，所有点坐标和运算结果都对这个 p 取余。
一旦进入模 p 世界，连续光滑的曲线就“碎”成了一张点云。几何上不再有“切线反射”那种直观图像，但代数公式依然成立。
设 P = (x1, y1)，Q = (x2, y2)，P ≠ Q 时，点加法的计算规则是：
λ = (y2 - y1) * (x2 - x1)^(-1) mod p x3 = λ² - x1 - x2 mod p y3 = λ * (x1 - x3) - y1 mod pP = Q 时（倍点），把斜率换成：
λ = (3 * x1² + a) * (2 * y1)^(-1) mod p这里的 (x2 - x1)^(-1) 和 (2 * y1)^(-1) 是模 p 下的逆元，也就是说，乘上一个数能让结果在模 p 下等于1的那个数。求模逆元用扩展欧几里得算法。如果你想自己在脚本里实现一遍点运算，最容易写错的就是这个模逆元，负数取模和零逆元都是经典翻车点。
2.3 ECDLP：让私钥无法逆向的护城河
有了点加法和倍点，就能定义最关键的一对操作：
- 正向容易：给定私钥 k 和基点 G，反复做倍点和点加，算出公钥 Q = kG，这个“标量乘法”可以用加倍算法把复杂度从O(k)降到O(log k)，毫秒级完成；
- 反向极难：给一条曲线和两个点 G、Q，求满足 Q = kG 的整数 k，这就是椭圆曲线离散对数问题（ECDLP）。目前公认最好的通用算法，复杂度也是指数级的。
所以私钥 k 只能自己留着，公钥 Q = aG 随便公开。很多新人刚接触时总担心“公钥公开了会不会泄露信息”，其实ECDLP这道数学墙护住的就是从公钥反推私钥这条路。
类比一下：公钥是一把锁，私钥是配钥匙的模具。锁可以满大街分发，但看到锁的构造，不等于能配出钥匙。
2.4 两条曲线撑起整个现代加密世界
工程上不能随便选一条椭圆曲线就用。曲线能不能用，取决于一组公开参数：有限域大小 p、方程系数 a 和 b、基点 G 的坐标、基点阶 n、余因子 h。这些参数由标准组织统一发布，NIST、RFC、国密标准都有。
不同曲线完全不互通。你用P-256生成公钥，对面用P-384做验证，结果就是签名校验直接失败。主流曲线大致这样：
| 曲线名 | 位宽（bit） | 安全级别（bit） | 主要用途 | 典型出处 |
|---|---|---|---|---|
| P-256 / secp256r1 | 256 | 128 | TLS证书、代码签名、通用场景 | NIST、RFC 8422 |
| P-384 / secp384r1 | 384 | 192 | 高合规场景、CA根证书 | NIST |
| P-521 / secp521r1 | 521 | 256 | 更高安全需求、小众场景 | NIST |
| secp256k1 | 256 | 128 | 区块链地址与交易签名 | 比特币、以太坊 |
| X25519 | 256 | 128 | TLS密钥交换（ECDHE） | RFC 7748 |
| Ed25519 | 256 | 128 | SSH签名、软件包签名 | RFC 8032 |
| SM2 | 256 | 128 | 国密合规场景 | GM/T 0003 |
P-256和P-384占了互联网TLS的大半江山，X25519则是现代握手临时密钥的宠儿，secp256k1被区块链生态完全锁死。工程上选哪条，不看谁的数学更漂亮，而是看对手方支持什么。
3. ECC密钥怎么生成：从OpenSSL命令行到P-384证书
3.1 为什么P-384证书总在合规场景里出现
如果你去CA机构申请证书，或注意到一些大厂的根证书名称，常会看到“ECC P384”字样。比如Trustwave旗下的“TrustwaveGlobal ECC P384 Certification Authority”，就是一张用P-384曲线自签的CA根证书，专门用来签发同为P-384的中间证书和终端实体证书。
这背后是合规驱动的选择。政府和金融、以及对欧美监管有敏感诉求的企业，在做代码签名、文档签名、HTTPS时，常常被要求“不能用太弱的RSA-2048，也不能随便用一张来历不明曲线的证书”。P-384的安全级别是192比特，NIST评估它高于AES-128、略低于AES-256，正好是很多合规标准里的“折中值”。再加上P-384曲线有公开、被广泛审计的曲线参数，CA机构拿它做根是最稳妥的。
实际项目里的典型画面是：客户发来一封邮件，附件里写着“必须使用P-384证书进行双向TLS认证，证书链签名算法需为SHA384WithECDSA”。这时候你在OpenSSL里指定曲线名secp384r1就对了。
3.2 自己动手签发一张ECC P-384证书
用OpenSSL 1.1.1或更高版本，三条命令就能生成私钥、CSR和自签名证书。
# 生成 P-384 私钥 openssl ecparam -name secp384r1 -genkey -noout -out ecc_key.pem # 生成证书签名请求 CSR openssl req -new -key ecc_key.pem -sha384 \ -subj "/CN=ecc-demo.example.com" \ -out ecc_csr.pem # 自签名证书（生产场景应发给CA签发） openssl x509 -req -in ecc_csr.pem -signkey ecc_key.pem \ -sha384 -days 365 -out ecc_cert.pem如果想用更规范的方式生成私钥，也可以用genpkey：
openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-384 \ -out ecc_key.pem两种方式生成的私钥都能用。区别在于ecparam是老牌命令，传统格式居多；genpkey是OpenSSL 1.1.x之后推荐的通用生成命令，输出更规范，建议新环境用后者。
生成后用-text看一眼证书，你会看到关键字段：
openssl x509 -in ecc_cert.pem -text -noout输出里会出现：
Public Key Algorithm: id-ecPublicKey Public-Key: (384 bit) Private-Key: (384 bit) curve: SECG secp384r1 Signature Algorithm: ecdsa-with-SHA384这就说明证书确实用了P-384曲线和SHA384签名，完全符合“ECC P-384证书”的预期。
3.3 Nginx与TLS配置：把ECC证书真正用起来
拿到证书，下一步是让Nginx跑起来。核心配置长这样：
server { listen 443 ssl; server_name ecc-demo.example.com; ssl_certificate /etc/ssl/certs/ecc_cert.pem; ssl_certificate_key /etc/ssl/private/ecc_key.pem; ssl_protocols TLSv1.2 TLSv1.3; ssl_ecdh_curve secp384r1:prime256v1:x25519; }这里的知识点在ssl_ecdh_curve。它的作用不是指定证书曲线，而是指定TLS握手时做ECDHE密钥交换的临时曲线列表，冒号分隔，排在前面的优先。默认值是auto，由OpenSSL自己选，大多数情况下没问题；但如果你要响应合规“务必优选P-384”，就把secp384r1放在最前面。
配置完成后，用浏览器打开，在开发者工具里找到“安全”面板，你会看到类似ECDHE_P384或TLS_AES_256_GCM_SHA384的字段。命令行验证更直接：
curl --verbose https://ecc-demo.example.com输出里能看到TLS版本和握手套件，也能看到证书链是否合法。
性能上坦白讲，P-384握手比P-256重一点，但比RSA-3072轻很多。如果公网没有合规约束，我一般默认P-256证书 + X25519/P-256做握手临时曲线，CPU省得明显。
3.4 证书验证、私钥匹配与常见报错
自己签发的自签名证书，可以用OpenSSL自己验证自己：
openssl verify -CAfile ecc_cert.pem ecc_cert.pem输出OK就表示证书链完整。真实生产里证书由CA签发，需要把CA根证书和中间证书加入信任库，再执行openssl verify -CApath /etc/ssl/certs your_cert.pem。
最常踩的报错是Nginx启动时这种：
cannot load certificate ... expecting: any private key通常是把RSA私钥配给了EC证书，或私钥和证书不是同一对。RSA时代我们习惯用openssl x509 -noout -modulus配合对比模数，但ECC证书没有模数，应该对比公钥：
openssl x509 -in ecc_cert.pem -noout -pubkey openssl pkey -in ecc_key.pem -pubout两条命令输出的公钥要完全一致。实践里我还会顺手检查证书签名算法，如果看到sha1WithECDSA，直接重签，SHA-1在当下已经是不可接受的安全风险。
4. ECDH与ECDSA：密钥交换和签名到底怎么工作
4.1 ECDH：两个人怎么在不安全信道上算出同一个秘密
假设Alice和Bob想在不安全信道上建立共享密钥，中间可能有人偷听。ECDH的做法是：
- 双方约定同一条曲线和基点 G。
- Alice随机选私钥 a，计算公钥 A = aG，发给Bob。
- Bob随机选私钥 b，计算公钥 B = bG，发给Alice。
- Alice拿到B后计算 S = aB = abG。
- Bob拿到A后计算 S = bA = baG。
因为椭圆曲线点加法的性质，aB和bA是同一个点，S就同时落入双方手里。偷听者Eve只能看到A和B，没有a和b，要求出S，被普遍认为和求解ECDLP一样困难。这就是计算Diffie-Hellman（CDH）难题。
这里要说清楚一个工程概念：ECDH本身不防中间人。如果Eve不仅偷听，还能篡改消息，她可以同时扮演Alice对Bob、扮演Bob对Alice，建立起两个中间桥。所以TLS里用的是ECDHE，E是Ephemeral，临时密钥，每次握手随机生成，用完即弃；同时协议里再用签名算法（比如ECDSA）验证对方的身份，防止中间人偷梁换柱。
4.2 ECDSA：签名验证的实现细节
ECDSA是用ECC私钥对消息做数字签名的标准算法。流程不复杂，但关键点一个都不能错。
签名方（持有私钥 d）：
- 对消息 m 计算哈希 e = hash(m)；
- 随机生成临时数 k，计算 R = kG，取 r = R.x mod n，若 r = 0 则重来；
- 计算 s = k^(-1) * (e + r*d) mod n；
- 签名结果为 (r, s)。
验证方（持有公钥 Q）：
- 计算 w = s^(-1) mod n；
- 计算 u1 = e * w mod n，u2 = r * w mod n；
- 计算 X = u1G + u2Q；
- 若 X 的 x 坐标模 n 等于 r，签名有效。
可以看出，验证过程根本不需要“解密”任何东西，就是重复一遍点运算并比对坐标。
工程上最严重的坑是 k 被重用或可预测。如果两个签名的 k 相同，任何人都能从两个签名 (r, s1) 和 (r, s2) 中解出私钥 d。当年索尼PS3就是因为随机数种子固定导致k可预测，直接被人提走私钥。现代加密库已经用RFC 6979的确定性随机数或在硬件里生成k来规避这个问题，所以你在生产环境千万别自己拼一个“随机数”写ECDSA代码。
4.3 TLS 1.3握手里的曲线协商
TLS 1.2时代，曲线选择和签名算法会一起打包在cipher suite里，比如TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256，名字里带ECDHE和RSA，很容易让人混淆：ECDHE管密钥交换，RSA管证书签名，二者是两码事。
TLS 1.3把结构改了，握手扩展里分开列出signature_algorithms和supported_groups。客户端在握手时告诉服务端自己支持哪些曲线，服务端从中选一条做ECDHE临时密钥。证书的签名算法则由signature_algorithms独立协商。
所以会出现我经常跟人强调的组合：证书用ECDSA P-384签名，但实际TLS握手用的临时曲线是X25519。两者并行，不冲突。这也是为什么有人在排查时盯着P-384证书看半天，发现握手还是X25519，其实根本不是bug。
观察握手最简单的方式：
openssl s_client -connect ecc-demo.example.com:443 -groups或者在Wireshark里过滤TLSv1.3，看ClientHello里的Supported Groups扩展。Chrome普遍把 X25519 和 secp256r1 排在前面，这也是公网服务器默认把X25519和P-256放在曲线列表前面的原因。
4.4 用Python cryptography库快速复现
用官方加密库实现一次真实流程，会比纯数学更有体感。Pythoncryptography库是一个很好的实验场：
from cryptography.hazmat.primitives import hashes, serialization from cryptography.hazmat.primitives.asymmetric import ec # 生成 P-384 密钥对 private_key = ec.generate_private_key(ec.SECP384R1()) public_key = private_key.public_key() # 导出 PEM pem = private_key.private_bytes( encoding=serialization.Encoding.PEM, format=serialization.PrivateFormat.PKCS8, encryption_algorithm=serialization.NoEncryption(), ) # 签名与验证 message = b"hello ecc" signature = private_key.sign(message, ec.ECDSA(hashes.SHA384())) public_key.verify(signature, message, ec.ECDSA(hashes.SHA384())) print("signature verified OK")ECDH共享密钥也一样简单：
peer_private_key = ec.generate_private_key(ec.SECP384R1()) shared_1 = private_key.exchange(ec.ECDH(), peer_private_key.public_key()) shared_2 = peer_private_key.exchange(ec.ECDH(), public_key) assert shared_1 == shared_2 print("shared secret OK")GitHub上能找到大量 “ECC” 主题的学习仓库，从零实现点运算、签名、密钥交换的都有。我的建议是：读它们的代码来理解曲线参数、模逆元、点加法和标量乘法，但生产环境永远用经过审计的加密库，而不是自己维护一套点运算代码。
5. 真正的坑不是数学，是工程兼容性
5.1 P-521曲线在真实客户端里的兼容性事故
我曾在内部系统签发过一张P-521自签证书，Chrome访问一切正常，但一台老Windows上跑的Java 8应用，在TLS握手阶段直接失败。服务端日志只有一行unsupported curve，客户端日志则是SSLHandshakeException: no cipher suite in common。
排查链路是这样的：
- 先在服务端用
openssl s_client -groups确认服务端曲线列表； - 再看Java进程的JCE Provider，发现老版本SunEC默认只支持NIST P-256/P-384，对P-521要么不支持、要么默认没启用；
- 最后把所有证书全部改成P-256，问题消失。
P-521是目前Web场景里比较尴尬的曲线。它安全等级很高，但浏览器和旧版中间件支持不齐。如果没有明文合规要求，我不会在生产环境选P-521。
5.2 ssl_ecdh_curve偏好顺序与性能取舍
很多运维把证书换了ECC，但ssl_ecdh_curve还是默认值，这不算错。但如果明确要控制客户端优先选择的曲线，就按性能和合规权重排：
ssl_ecdh_curve x25519:prime256v1:secp384r1:secp521r1;把X25519放最前，是性能最优解；把P-384放最前，是合规优先解。Nginx会按客户端支持列表把第一个双方都有的曲线挑出来，所以顺序就是你的态度。
实测数据我这边大致是：X25519点运算最快，P-256其次，P-384慢约30%~50%，P-521更慢。公网高并发场景下这个差距是能省下来的CPU时间，所以非合规项目我坚持X25519或P-256。
5.3 侧信道、实现安全与“曲线审查”争议
NIST曲线有个绕不开的历史争议：生成参数时的随机种子，最初并未公开说明来历，虽然至今没有实证后门，但一些组织选择彻底不信任它，改用Bernstein设计的X25519和Ed25519。
X25519用的是蒙哥马利曲线，结构上天然支持更简单、常数时间的实现，比一般Weierstrass曲线更容易避免侧信道泄漏。所谓侧信道，就是攻击者通过测量运算时间、功耗来猜私钥；常数时间实现能保证不同输入的执行时间基本一致，降低这类攻击面。
我个人的态度是：不否定NIST曲线，但新项目默认选X25519和Ed25519，为了少背锅。需要和PKI生态对接时再回退到P-256/P-384，这在工程上既不激进也不保守。
5.4 量子计算来了，ECC会被淘汰吗
在被问过一百遍“量子计算会不会让加密崩溃”之后，我的回答是：会，但那是明天的事，不是今天。
Shor算法理论上一旦有大规模容错量子计算机，ECDLP和RSA的因数分解都会崩。但眼下还没有足够规模的量子比特能真正攻破256位曲线。标准组织已经在主推后量子算法，NIST已经选出ML-KEM、ML-DSA、ML-SLH-DSA作为标准草案，未来几年我们会看到“RSA/ECC加后量子混合”的过渡态。
对普通工程人员的实质建议是：现在不要盲目切后量子，但要把“算法可替换”的抽象层做进设计里。别把曲线ID硬编码成魔法字符串，别在签发系统里绑定死某一条曲线。等客户要求或者标准落地时，改配置而不是改架构。
5.5 选型建议：P-256、P-384、X25519还是SM2
我做技术选型时常用这张表，直接抄作业：
| 场景 | 推荐方案 | 核心原因 |
|---|---|---|
| 公网HTTPS，面向浏览器 | ECDSA P-256证书 + X25519/P-256握手 | 兼容性最好，性能最优 |
| 政企、金融等合规项目 | P-384证书，必要时SM2 | 客户标准和合规要求决定 |
| 内部服务mTLS | X25519密钥交换 + Ed25519证书 | 现代栈首选，安全与性能平衡 |
| 区块链地址与交易签名 | 跟随链生态（secp256k1等） | 生态锁定，没有自由选择 |
| SSH登录密钥 | Ed25519 | 密钥短、生成快、验证快 |
最后再强调一次：证书的签名曲线和TLS握手的临时曲线是两套东西。你可以用P-384证书应对合规，同时让握手跑X25519，这两件事完全可以并存。
6. 回到起点：怎么用一个月彻底吃透ECC
6.1 三步递进的学习路径
如果你完全从零开始，我建议按这个顺序走，别一上来就啃椭圆曲线教材：
第一步，用Python或Go在小参数域上自己实现一遍点加法和标量乘法。不用选P-256那种大数域，选个小素数、简单曲线，能跑通几个公开测试向量就够了。这一步会让你对“模逆元”“倍点”“基点阶”有肌肉记忆。
第二步，用OpenSSL把生成私钥、生成CSR、自签证书、验证证书这四件事各做十遍，做到不翻文档也能跑通。理解证书链、根CA和中间CA的关系，远比背命令重要。
第三步，搭一个真实的TLS环境，分别用Nginx和Python各起一个HTTPS端点，再用openssl s_client、curl、Wireshark三个工具反复看握手中的曲线协商过程。处理一次真实的“客户端不支持某曲线”报错，顶上读十篇原理文章。
GitHub上有不少ECC学习仓库，有些作者会把每条曲线的测试向量列成表格，你用脚本对拍一遍，数学直觉基本就固化下来了。可以参考，但别迷信任何未审计的“自研实现”。
6.2 我踩过的三个具体坑
第一个是概念混淆。我早期做完P-384证书后，看到TLS握手还是X25519，以为证书没生效，排查了大半天才发现证书签名算法和握手临时曲线本来就是两个维度。从那以后我奉行一句话：遇到TLS问题，先分清“证书链”“签名算法”“密钥交换曲线”三件事，再动手。
第二个是密钥存储不当。一段时间里我把私钥放在服务器磁盘上，虽然chmod 600，但安全审计一查就要求整改。后来把私钥都迁到HSM或云KMS，证书到期前在外部完成签名流程，服务器不再触碰私钥。合规不是看你会不会配Nginx，而是看私钥生命周期管理是否可审计。
第三个是证书到期后忘了同步更新双方信任链。内部系统做mTLS时，服务端换了新证书，但客户端的CA拉黑名单或缓存还是旧的，结果线上全部握手失败。现在我的习惯是，证书到期前一个月就列好“服务端更新、客户端信任、监控告警”三张清单，缺一不可。
6.3 最后的一点忠告
密码学是买保险，不是买彩票。你不需要懂得每条曲线的数学证明，但你必须知道手里的系统在用什么曲线、签什么哈希、密钥存在哪。花一个周末亲手把上面三步走完，当你跑出ECDH共享密钥一致、看到证书链验证OK、抓包里出现熟悉的ecdhe_p384时，你对TLS报错的那点恐惧会就此消失。
如果真的被问到“ECC和RSA哪个好”，不妨老老实实反问回去：你的场景是公网HTTPS、政企合规、内部mTLS，还是区块链签名？这四个场景的答案完全不同。能给出这种区分，你已经比大部分只会背“ECC密钥更短”的人，强得多了。
