TLSv1.2密钥交换算法安全性及性能比较(RSA, DHE, ECDHE)

最新推荐文章于 2025-07-19 10:01:01 发布
原创 最新推荐文章于 2025-07-19 10:01:01 发布 · 8k 阅读 · 9 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

本文对比了TLSv1.2中三种密钥交换算法——RSA、DHE和ECDHE的安全性和性能。DHE耗时约23秒，ECDHE耗时约28秒，而RSA耗时仅为0.1秒。DHE和ECDHE通过大数运算和椭圆曲线乘法生成密钥，而RSA依赖服务器已有私钥进行解密操作。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

文章目录


想当初, 某次将服务器容器jetty升级之后, 公司的小霸王服务器直接就跪了, 当时还不知道 DHE, ECDHE是什么鬼. 只是通过分析jvm stack发现, 大量线程卡在这两个相关算法中. 于是果断地配置jetty, 这两个算法剔除掉了.
不过. ECDHE是趋势, 苹果公司指定要用这种算法, 等迫不得已的时候再开吧.
今天测试了一下 RSA, DHE, ECDHE这三种方式的性能.

先上总结

TLSv1.2密钥交换算法 安全性 本次测试耗时(秒)
RSA 低, 如果RSA私钥泄露或被破解, 全完蛋 0.1
DHE 较高, 即使RSA私钥泄露, 也没事. 即使某个人的连接被破解, 其他人也不受影响
算法难度等同于
解方程: 2e % p = q, 已知p和q , 求e等于多少?		 23
ECDHE 很高. 同上.
算法难度等同于:
已知有限域椭圆曲线方程E, 曲线上两点g和Q, k * g = Q, 求k为多少?		 28

测试DHE

分析:

  1. DH每次需要随机生成一个大素数p, 大指数e, 基数为固定值g=2
  2. 执行一次大数模幂运算 g e m o d   p g^e mod\ p
最低0.47元/天 解锁文章

200万优质内容无限畅学
物联网安全系列 - 非对称加密算法 ECDH
物联网布道师
07-13 1万+
   之前的章节讲到了对称加密算法AES，发送方和接收方需要使用相同的密钥进行通讯，但是发送方怎么将密钥安全的发送给接收方？这是一个问题。   对称加密算法中，为了将密钥安全的发送给对端，通常有以下四种方法：事先共享密钥    事先双方约定好密钥的数值，或者使用其他安全的手段例如派特工押送等，将密钥安全的送到对端，这种方式虽然简单，但是局限性很大，另外通讯量增大以后，密钥个数也会相应增加，这在高数量级的设备通讯上并不现实。密钥分配中心    为了解决事先共享密钥的密钥增多的问题，也可以使用密钥分配中心来解决
密钥交换和密文交换_具有Web服务安全性的密钥交换模式
danpu0978的博客
05-09 361
密钥交换和密文交换 当我们通过Web服务获得消息级别的安全性时，我们如何通过密钥来实现完整性和机密性。 密钥用于对从rqeuestor传递到接收者的消息进行签名和加密，或者从客户端到服务，反之亦然。 在此博客文章中，我们将讨论不同的密钥交换模式及其相关用例。 1.直接密钥转移 如果一方拥有令牌和密钥并希望与另一方共享，则可以直接转让密钥。 WS-Secure对话就是一个很好...
TLS 1.2（Transport Layer Security version 1.2）详解 && TLS 1.2 密码套件
csdn_tom_168的博客
07-03 1099
TLS 1.2作为互联网安全传输的基石，解决了早期协议（如SSLv3）的缺陷，但其复杂的握手流程、可选安全性和历史遗留漏洞（POODLE等）促使TLS 1.3全面革新。新系统部署：应优先采用TLS 1.3，享受安全与性能优势。旧系统维护：需严格配置TLS 1.2（禁用CBC、强制PFS），并通过自动化扫描工具（如Qualys SSL Labs）持续监控安全状态。
SSL/TLS密钥协商算法的演变——RSA算法、DH算法、DHE算法、ECDHE算法
u014644574的博客
07-22 3348
SSL/TLS密钥协商算法的演变——RSA算法、DH算法、DHE算法、ECDHE算法
DH算法、DHE算法、ECDHE算法演进
WangYouJin321的博客
08-01 1384
ECDHE 算法解决了 RSA 算法不具备前向安全的性质 和 DH 算法效率低下的问题。ECDHE 算法具有前向安全。所以被广泛使用。
椭圆曲线密码系统的实现及安全性分析
06-20
椭圆曲线密码系统的实现及安全性分析,内容不错希望能对大家有所帮助
17、nginx https的默认密钥交换算法由tls决定还是由nginx决定？
最新发布
xuebo1129927648的博客
07-19 557
TLS 协议（如 TLS 1.2、TLS 1.3）定义了合法的密钥交换算法类型，但不强制要求具体使用哪一种。TLS 1.2支持的密钥交换算法包括：RSA、DHE（Diffie-Hellman Ephemeral）、ECDHE（Elliptic Curve Diffie-Hellman Ephemeral）等。TLS 1.3为增强安全性，仅支持ECDHE（移除了 RSA、DHE 等不支持前向 secrecy 的算法）。
11、rsa-目标主机支持RSA密钥交换【原理扫描】的漏洞
xuebo1129927648的博客
07-18 2759
通过将 etcd 的 TLS 密钥交换算法从 RSA 升级为 ECDHE，可实现前向保密，彻底消除 “私钥泄露导致历史流量解密” 的风险。核心步骤是通过强制启用含ECDHE的套件，并禁用 RSA 密钥交换套件，同时建议升级到 TLS 1.2+ 并优化证书类型（优先 ECDSA）。这一配置符合云原生安全最佳实践，也是 Kubernetes 等依赖 etcd 的系统推荐的安全标准。生成临时密钥的具体步骤是什么？如何验证etcd是否已成功更新为ECDH密钥交换算法？配置临时密钥交换算法可能带来哪些性能影响。
TLSv1.2抓包解密分析过程之ECDHE_RSA_WITH_AES_128_CBC_SHA256
wzj_whut的专栏
01-26 1万+
TLSv1.2 ECDHE加密 解密
TLSv1.2抓包解密分析过程之DHE_RSA_WITH_AES_128_CBC_SHA256
wzj_whut的专栏
01-25 5609
DHE_RSA_WITH_AES_128_CBC_SHA256模式下, RSA只用于身份验证, 不用于加密. 加密密钥是通过DH算法交换的. 因此需要DH相关的参数才能解密. 本文的demo样本使用了特殊方法来获取这些参数. 准备工作 已经准备好的抓包数据 https://github.com/wzjwhut/tlsv12-demo/blob/master/src/main/resources/T...
DH、DHE、ECDHE加密算法
迷雾总会解
09-12 5064
于是，DH 交换密钥时就只有客户端的公钥是变化，而服务端公钥是不变的，那么随着时间延长，黑客就会截获海量的密钥协商过程的数据，因为密钥协商的过程有些数据是公开的，黑客就可以依据这些数据暴力破解出服务器的私钥，然后就可以计算出会话密钥了，于是之前截获的加密数据会被破解，所以 static DH 算法不具备前向安全性。但反过来，知道真数却很难推算出对数。static DH 算法里有一方的私钥是静态的，也就说每次密钥协商的时候有一方的私钥都是一样的，一般是服务器方固定，即 a 不变，客户端的私钥则是随机生成的。
[020]VC++串口通信总结.zip上位机开发VC串口学习资料源码下载
05-04
[020]VC++串口通信总结.zip上位机开发VC串口学习资料源码下载[020]VC++串口通信总结.zip上位机开发VC串口学习资料源码下载[020]VC++串口通信总结.zip上位机开发VC串口学习资料源码下载[020]VC++串口通信总结.zip上位机开发VC串口学习资料源码下载 1.合个人学习技术做项目参考合个人学习技术做项目参考 2.适合学生做毕业设计项目参考适合学生做毕业设计项目技术参考 3.适合小团队开发项目技术参考适合小团队开发项目技术参考
TLS/SSL 协议详解 (30) SSL中的RSA、DHE、ECDHE、ECDH流程与区别
热门推荐
Network/Storage/Linux Kernel
09-19 6万+
我的TLS实现：https://github.com/mrpre/atls/大家可以参考，代码里面的逻辑较清晰。 我的SSL专栏见：https://blog.csdn.net/mrpre/article/category/9270159描述了TLS的各方面。 本文是对前面系列章节关于非对称算法在SSL中运用的总结和细化，但也可以作为详解SSL中RSA、ECDHE非对...
嵌入式JETTY启动HTTPS（jetty8）
weixin_34214500的博客
03-04 277
为什么80%的码农都做不了架构师？>>> ...
密码学入门
fm18771120556的博客
04-29 3017
原创：打码日记（微信公众号ID：codelogs），欢迎分享，转载请保留出处。 简介 在信息安全领域，一般会遇到"窃听"、“篡改”、“伪装”、"否认"这些威胁，而密码学家们提供了相应的密码学算法来解决这些问题，如下： 窃听：攻击者可以在网络上安置了一个路由器，侦听所有经过的数据包，这样数据就被泄密了，密码学提供了对称密码与公钥密码算法对数据加密，保证机密性。 篡改：攻击者对经过的数据包进行修改，使得接收方获取到错误的信息，密码学提供了单向散列函数生成“数据指纹”，保证数据完整性。 伪装：攻击者伪装成.
SKF工具包 UKEY加解密 JAVA接口调用UKEY DLL/SO驱动
qq_35477525的博客
11-01 2387
最近公司需要开发基于UKEY方式的国密加解密，在网上找了一圈只找到唯一的龙脉科技的UEKY接口，也只有寥寥几个。经过一段时间的摸索终于写完测试通过。（使用了海泰方圆厂商提供的ukey,不管是哪个厂商，都是按照gj密码局要求的接口规范开发的，完全可以借鉴）实现了SM4加解密和SM2加解密以及疏通了UKEY提供的所有JAVA接口。源码有需要的请v lalawangzi1986, 有偿指导。
openssl + ECDH + linux+开发详解（C++）
N阶二进制的博客
11-27 2714
ECDH（Elliptic Curve Diffie-Hellman）是一种基于椭圆曲线密码学的密钥交换协议，用于在通信双方之间安全地协商共享密钥。ECDH是Diffie-Hellman密钥交换协议的一种变体，它利用椭圆曲线上的离散对数问题，提供了一种安全、高效的密钥协商方法。每个通信方都有一对密钥，包括一个公钥和一个私钥。公钥可以公开分享，而私钥则必须保密。通信双方通过互相交换各自的公钥，并使用对方的公钥和自己的私钥生成一个共享的对称密钥。
TLV1.2 RSA密钥协商和ECDHE密钥协商两种方式的连接建立流程
qq_47529104的博客
02-26 2255
作者：叨陪鲤 链接：https://www.zhihu.com/question/37640500/answer/2186960203 3.2 基于RSA的TLS握手流程 基于RSA进行密钥配送的TLS握手报文如下： TLS四次握手的报文及其主要内容如下： 3.2.1 TLS第一次握手 TLS握手首先以客户端发送的：Client Hello报文作为协商的开始。 报文内最容主要包含：TLS版本号，随机数（Client Random），密码套件列表，以及sessionID。 TLS版.
tlsv1.2协议加解密流程
12-28
### TLSv1.2 加解密流程解释 #### 客户端和服务端握手阶段 在TLSv1.2协议中，为了建立安全通信通道，在实际数据传输之前会经历一系列复杂的握手过程。此过程中涉及到了多种密码学技术的应用。 当客户端尝试连接到服务器时，它发送Client Hello消息给服务端，其中包含了支持的最高版本号、随机数以及所支持的加密套件列表等信息[^1]。随后，服务器回应Server Hello消息，选定双方都认可的一个加密方案，并提供自身的公钥证书用于验证其身份合法性；同时也会返回一个随机数值作为后续运算的一部分输入材料之一[^2]。 接着进入密钥协商环节，依据选用的具体算法不同而有所差异： - 如果采用RSA方式，则客户机会利用接收到的服务商公开密钥对预主秘钥(pre-master secret)实施保护后再传回； - 对于DHE/ECDHE这类基于Diffie-Hellman原理的方法来说，两端各自生成一对临时性的私钥与对应的公共参数并互相分享后者，最终共同推导得出一致的秘密值即所谓的master secret。 上述操作完成后，双方均能独立计算得到相同的master secret，进而派生出会话所需的读写MAC密钥(read/write MAC key)，客户端及服务器编码工作秘密(client/server write working secret)。 ```python import hashlib from cryptography.hazmat.primitives.asymmetric import rsa, padding from cryptography.hazmat.backends import default_backend from cryptography.hazmat.primitives import hashes def generate_master_secret(premaster_secret, client_random, server_random): seed = b"master secret" + client_random + server_random master_secret = hashlib.sha256(premaster_secret + seed).digest() return master_secret ``` #### 数据传输阶段 一旦完成了前面提到的一系列初始化活动之后，就可以正式开启受保护的信息交流了。此时所有的应用层负载都会先经过特定处理再发出——具体而言就是按照先前确立好的规则进行分割打包成记录(record)，然后运用共享出来的对称型密钥完成内容混淆(Confidentiality)，再加上哈希函数产生的验证码(MAC)确保完整性(Integrity)。 每当一方准备向另一方传递某些东西的时候，就会创建一条新的SSL/TLS Record Protocol单元，里面封装着真实有效载荷加上额外附加的安全特性描述字段。这些被精心包装过的实体将以流的形式沿着TCP/IP栈向下流动直至抵达目的地为止。 接收者拿到这样的包裹以后，首先要做的便是剥离外层防护措施恢复原始面貌，这期间涉及到解开由AES/GCM之类的分组变换所提供的屏障，同时也需检验附带的消息鉴别码是否匹配预期结果以证明未遭篡改破坏。如果一切正常无误的话，那么就能顺利解析出内部真正携带的内容片段供应用程序进一步消费使用了。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值