精华内容
下载资源
问答
  • ecdhe-cpp C ++中的ECDHE实现
  • ECDHE cipher support

    2020-12-30 03:29:50
    ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-AES256-SHA384 ECDHE-RSA-AES256-SHA ECDHE-RSA-DES-CBC3-SHA ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-SHA256 ECDHE-RSA-AES128-SHA ECDHE-RSA-RC4-SHA AES256-SHA256...
  • 我的TLS实现:https://github.com/mrpre/atls/大家可以参考,代码里面的逻辑较清晰。 ... 本文是对前面系列章节关于非对称算法在SSL中运用的总结和细化,但也可以作为详解SSL中RSA、ECDHE非对...

        我的TLS实现:https://github.com/mrpre/atls/ 大家可以参考,代码里面的逻辑较清晰。

        我的SSL专栏见:https://blog.csdn.net/mrpre/article/category/9270159 描述了TLS的各方面。

        本文是对前面系列章节关于非对称算法在SSL中运用的总结和细化,但也可以作为详解SSL中RSA、ECDHE非对称加密算法来看。

        在不安全信道上构建安全信道,这是SSL的核心,所谓安全包括身份认证、数据完整性、数据加密性。而非对称算法在SSL中的运用就是为了协商一个密钥,密钥的目的就是为了后续数据能够被加密,而加密密钥有且只有通信双方知道。

     

        通常网络上传输的数据一般都被认为是可见的。端对端传输的数据,不仅经过交换机、路由器,还经过各种DPI、IPS、WAF等审计安全设备,甚至可能经过负载均衡等反向代理设备,只要在任何一个环节抓包,都可以轻松获取网络上传输的数据。所以如果A和B需要加密通信,即通信的内容需要使用有且只有A和B知道的“密钥”加密,那么必然需要传输这个“密钥”,也就是说“密钥”本身需要在不安全传输的信道传输,如果简单的传输“密钥”,那么这个“密钥”就不再保密,任何第三方都能获取“密钥”,即任何第三方都能解密A和B发出来的密文数据。

     

        非对称算法就是为了解决“密钥”传输(A和B共享)的问题。

     

     

    1:RSA密钥交换算法

    详细原理请参考我的这篇博客http://blog.csdn.net/mrpre/article/details/52609087

    本篇不讲解具体原理,而是讲解交互过程。

     

    RSA的核心涉及公钥私钥的概念

    (1):使用公钥加密的数据只有私钥能解密

    (2):使用私钥加密的数据只有公钥能解密

     

    我们构建这么一种场景,服务器配置有公钥+私钥,客户端是离散的。

     

    RSA算法流程文字描述如下:

    (1):任意客户端对服务器发起请求,服务器首先发回复自己的公钥到客户端(公钥明文传输)。

    (2):客户端使用随机数算法,生成一个密钥S,使用收到的公钥进行 加密,生成C,把C发送到服务器。

    (3):服务器收到C,使用公钥对应的私钥进行解密,得到S。

    (4):上述交换步骤后,客户端和服务器都得到了S,S为密钥(预主密钥)。

     

        我们来看看上述过程中,为何第三方无法得到S。首先第一步后,客户端有公钥,服务器有公钥和私钥。由于公钥是明文传输的,所以可以假设第三方也有公钥。

    第二步后,客户端发送C,服务器能够使用自己的私钥进行解密,而第三方只有公钥,无法解密。即第三方无法计算得到S。

     

     

     

     

     

    上述中,服务器发送的公钥在SSL中是通过certificate报文发送的,certificate中的包含了公钥。C是通过Client key exchange报文发送的。

    其实,在实际SSL实际设计中,S其实并没有直接被当成密钥加密,这里为了描述原理,省去了对S后续进行KDF等操作,并不影响实际理解RSA。

     

    RSA有一个问题,就是如果私钥泄漏,即私钥被第三方知道,那么第三方就能从C中解密得到S,即只要保存所有的A和B的报文,等到私钥被泄漏的那一天,或者有办法快从C中计算S的方法出现(量子计算机分解大素数),那么A和B就没有什么私密性可言了。

    这就是所谓的前向不安全,私钥参与了密钥交换,安全性取决于私钥是否安全保存。

    有网友问了这么一个问题:为何客户端不也安装一个公钥私钥,然后客户端和服务器交互的时候,各自传送给对方公钥,然后各自拿对方的公钥加密数据发送给对方,然后各自拿私钥解密收到的数据?

    先不说性能,我们看RSA加解密算法,若要加密m,那么需要计算

    m^e mod n

    如果m > n,我们记作m = n + k

    那么原式子 (n + k)^e mod n

    多项式展开,除了最后一项k^e ,其余的每一项都有n,故mod n后,

    k^e mod n

    换句话说,如果m大于n,那么其加密的结果和k的结果时一样的,这就有二义性了,所以RSA本身就不允许m>n的情况出现。所以拿来直接加密数据时不可取的。

     

     

    2:DHE密钥交换算法

    详细原理请参考我的这篇博客http://blog.csdn.net/mrpre/article/details/52608867

    本篇不讲解具体原理,而是讲解交互过程。

     

    DHE算法流程文字描述如下:

    (1):客户端计算一个随机值Xa,使用Xa作为指数,即计算Pa = q^Xa mod p,其中q和p是全世界公认的一对值。客户端把Pa发送至服务器,Xa作为自己私钥,仅且自己知道。

    (2):服务器和客户端计算流程一样,生成一个随机值Xb,使用Xb作为指数,计算

       Pb = q^Xb mod p,将结果Pb发送至客户端,Xb仅自己保存。

    (3):客户端收到Pb后计算Sa = Pb ^Xa mod p;服务器收到Pa后计算Sb = Pa^Xb mod p

    (4):算法保证了Sa = Sb = S,故密钥交换成功,S为密钥(预主密钥)。

     

    DHE密钥交换握手流程图

     

     

     

     

        上述途中,Sa和Sb得到的结果是相同的,即记为S。

     

        上述密钥交换流程中,和RSA密钥交换有较大不同,DHE密钥交换时,服务器私钥没有参与进来。也就是说,私钥即使泄漏,也不会导致会话加密密钥S被第三方解密。

    实际使用过程中,私钥的功能被削弱到用来身份认证(上图中没有画出)。

        上图中DHE参数和Pb都是通过server key exchange发送给客户端,Pa通过client key exchange发送给服务器。server key exchange的结尾处需要使用服务器私钥对该报文本身进行签名,以表明自己拥有私钥(图中为了表明私钥没有参与密钥计算,没有画出,但不影响理解DHE算法)。

     

    3:ECDHE密钥交换算法

    详细原理请参考我的这几片篇博客

    http://blog.csdn.net/mrpre/article/details/72850486

    http://blog.csdn.net/mrpre/article/details/72850598

    http://blog.csdn.net/mrpre/article/details/72850644

     

    本篇不讲解具体原理,而是讲解交互过程。

     

        只要理解DHE密钥交换原理,那么理解ECDHE密钥交换原理其实并不难(如果不想深究的话)。

    ECDHE的运算是把DHE中模幂运算替换成了点乘运算,速度更快,可逆更难。

     

    ECDHE算法流程文字描述如下:

    (1):客户端随机生成随机值Ra,计算Pa(x, y) = Ra * Q(x, y),Q(x, y)为全世界公认的某个椭圆曲线算法的基点。将Pa(x, y)发送至服务器。

    (2):服务器随机生成随机值Rb,计算Pb(x,y) - Rb * Q(x, y)。将Pb(x, y)发送至客户端。

    (3):客户端计算Sa(x, y) = Ra * Pb(x, y);服务器计算Sb(x, y) = Rb *Pa(x, y)

    (4):算法保证了Sa = Sb = S,提取其中的S的x向量作为密钥(预主密钥)。

    ECDHE密钥交换握手流程图

     

     

     

     

      SSL协议中,上图中椭圆曲线名和Pb通过server key exchange报文发送;Pa通过client key exchange报文发送。

     

     

    4:ECDHE与ECDH算法的区别

     

        字面少了一个E,E代表了“临时”,即在握手流程中,作为服务器端,ECDH少了一步计算Pb的过程,Pb用证书中的公钥代替,而证书对应的私钥就是Xb。由此可见,使用ECDH密钥交换算法,服务器必须采用ECC证书;服务器不发送server key exchange报文,因为发送certificate报文时,证书本身就包含了Pb信息。

     

    5:ECDHE与RSA的区别

        ECDHE(DHE)算法属于DH类密钥交换算法, 私钥不参与密钥的协商,故即使私钥泄漏,客户端和服务器之间加密的报文都无法被解密,这叫 前向安全(forward secrity)。由于ECDHE每条会话都重新计算一个密钥(Ra、Rb),故一条会话被解密后,其他会话仍旧安全。

        然而,ECDH算法服务器端的私钥是固定的,即证书的私钥作为Rb,故ECDH不被认为前向安全,因为私钥泄漏相当于Rb泄漏,Rb泄漏,导致会话密钥可被第三方计算。ECDH交换算法已经被OpenSSL废弃:https://github.com/openssl/openssl/commit/ce0c1f2bb2fd296f10a2847844205df0ed95fb8e#diff-d615181712e5a3ed0a51d3222d96e1d4  

     

     

    如果觉得有用,请打赏N元:http://39.98.242.44

     

    展开全文
  • 关于 ECDSA ECDH ECDHE

    2021-07-20 03:39:39
    ECDSA与ECDH ECDSA 指利用椭圆曲线算法进行数字签名 ECDH 指利用椭圆曲线算法进行密钥协商 ...ECDHE是ECDH的延伸, 它也是密钥协商, 只是它每次进行TLS握手时都进行密钥商(E=Ephemeral), 它比ECDH..

    ECDSA与ECDH

    ECDSA 指利用椭圆曲线算法进行数字签名

    ECDH   指利用椭圆曲线算法进行密钥协商

    理论上是可以共用同一组曲线模型和生成参数分别进行DSA(Digital Signature Algorithm)和DH(Diffie-Hellman)两种算法, EC代表椭圆曲线. (不推荐共用一组参数, 可以使用openssl编码实现)

    ECDHE与ECDH

    ECDHE是ECDH的延伸, 它也是密钥协商, 只是它每次进行TLS握手时都进行密钥商(E=Ephemeral), 它比ECDH拥有更好的前向安全保证,  因为每次握手都会协商一次密钥, 因此的效率也会差一些. 他们的TLS握手方式也有区别, 这里不做赘述.

    ECDH相比DH的生成效率来说高很多(椭圆曲线参数的生成), 相对来说DHE成本很高, 为了更好的安全性, ECDHE也被TLS协议所应用.


    翻找这部分定义时发现没有概括性描述,  做个记录在此备忘. 

    展开全文
  • ECDHE_RSA验证

    千次阅读 2020-03-06 16:49:33
    ECDHE_RSA验证 上一篇博客中对TLS1.2中对ECDHE_RSA再握手阶段的密钥协商进行了解释,但是考虑到没有实际验证,无法100%的保证理解的正确性,后来几天一直在想办法验证,今天终于验证成功,把验证过程在这里简单说...

    ECDHE_RSA验证

    上一篇博客中对TLS1.2中对ECDHE_RSA再握手阶段的密钥协商进行了解释,但是考虑到没有实际验证,无法100%的保证理解的正确性,后来几天一直在想办法验证,今天终于验证成功,把验证过程在这里简单说一下。
    首先使用wireshark对TLS1.2握手的数据包了抓取,如下图所示:
    TLS1.2握手
    从图中可以看到Client Hello,Server Hello,Server Key Exchange等交互过程,ECDHE_RSA主要应用在Server Key Exchange的过程中,所以我们先看下这个包的内容:
    Server Key Exchange
    从图中可看出,EC Diffie- Hellman 参数在这里出现,其中Pubkey就是DH密钥交换用到的参数,而Signature就是对这个Pubkey的保护,确认其来源的正确性,防止中间人攻击。

    为了验证这个猜想,需要进行如下计算:

    1. 对Signature进行RSA加密(验签)得到摘要信息d1
    2. 计算Pubkey的SHA512摘要信息d2
    3. 比较d1和d2,如果相同说明猜想正确

    为了计算第一步,我们需要验签的公钥,这个需要去证书中寻找,如下图所示:

    证书中公钥信息
    这里可以看到有两个certificate,一个1947长度,一个1176长度,从证书信息可以看出,1176长度的证书是CA的根证书,是用来验证1974的证书的,这个就是证书链,熟悉公钥证书体系的应该知道。
    我们需要用到的公钥就在1947的证书中,其中subjectPublicKey就是我们需要的,这里有两个参数,一个是RSA的n,一个是公钥e。
    有个n和e,我们就可以验证上面的Signature了,从而得到的d1,经计算:
    d1 = 1ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff00305130d060960864801650304020305000440079daee9d2d662803b39919a94b313eef9bc989330f8dca20d379515105e59629a1ed24a7eaa447a87753004a2663fc841a3da332e82bfa94a87e1834420fcc5
    熟悉pkcs1的人对这个格式肯定不陌生,这里需要补充一点,计算hash之后再计算签名之前一般是需要对数据按照预定义好的格式进行填充的,这里就使用了pkcs1。

    所以准确的d1为:
    079daee9d2d662803b39919a94b313eef9bc989330f8dca20d379515105e59629a1ed24a7eaa447a87753004a2663fc841a3da332e82bfa94a87e1834420fcc5

    d1之前的3051300d060960864801650304020305000440为hash512的IV值

    d1得到之后就需要计算d2了,这里颇费了些周折,因为随TLS1.2的具体实现过程没有细节的研究过,对生成d2的消息具体是哪些不确定,一开始直接用Pubkey去计算,发现不对,然后又在网上搜索了半天,有人说是下图的这段数据是消息:
    ecdh参数
    但是计算后发现还是不对,然后又尝试了各种可能,甚至自己写了段代码实现hash512,发现还是不对,就还是这个说法是不对的。直到今天查看了RFC4492,其中有一段这样的描述:
    RFC4492P片段
    这里的ClientHello.random是客户端强求连接时发给服务器的hello包中的随机数:
    ClientHello.random
    ServerHello.random是服务器发给客户端的hello应答中的随机数:
    ServerHello.random
    然后使用上图RFC4492中公式计算消息的SHA512的摘要信息,如下:
    sha512_hash ( 5e4f7d144d4e1135ee95a288bf2b8804a21f440af92ab0dab49b81120ee5e00858c7ff8c2ac3b911d05d916e6384e725c8d0365e7934a107261c89265cd483f00300174104f5d34e39b69e7570f3bb0af648ef3f4a794cb3d68e39386fc55461291fd5d61271b55a1b5b8f8a9b74de16b5b5880a4b1afea7fcadbc3fd0435c066ac9b88502 )
    //-----最终计算结果 — 07 9D AE E9 D2 D6 62 80 3B 39 91 9A 94 B3 13 EE F9 BC 98 93 30 F8 DC A2 0D 37 95 15 10 5E 59 62 9A 1E D2 4A 7E AA 44 7A 87 75 30 04 A2 66 3F C8 41 A3 DA 33 2E 82 BF A9 4A 87 E1 83 44 20 FC C5

    d1 == d2,验证成功!

    THE END!

    感想:要想研究明白,还是要多看官方文档,网上的知识分享可能会让你事半功倍,也可能让你缘木求鱼。水能载舟,亦能覆舟!!!

    展开全文
  • TLS密码套件TLS_ECDHE含义

    千次阅读 2019-04-08 14:57:15
    TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 解构如下: ECDHE_RSA:密钥协商交换算法 ECDHE:使用基于椭圆曲线签密方案(EC, Elliptic Curve)的 Diffie-Hellman(DH)密钥协商协议。尾部的 E 为 Ephemeral 首字母,...

    TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 解构如下:

        ECDHE_RSA:密钥协商交换算法
            ECDHE:使用基于椭圆曲线签密方案(EC, Elliptic Curve)的 Diffie-Hellman(DH)密钥协商协议。尾部的 E 为 Ephemeral 首字母,表示协商的是临时会话密钥。相对每次会话协商的临时密钥,证书中的公钥则是永久的(long-term)。
            RSA:证书公钥加密算法,用于对证书数据部分的散列值进行签密、对 ECDHE 交换参数(的 HASH 值)进行签密。可能替换值为 ECDSA(椭圆曲线数字签名算法)。

            rfc4492 & rfc5289 定义了该 CipherSuite 的具体实现。
            the long term authenticity is confirmed via the server cert’s RSA signature but the transient keys are derived via ephemeral EC keys (which then generate the symmetric key)
            ECDHE-RSA uses Diffie-Hellman on an elliptic curve group while DHE-RSA uses Diffie-Hellman on a modulo-prime group.

        AES_128_GCM:传输会话(对称)加解密使用 GCM 模式的 AES-128 算法。
            AES_128:使用128位的会话对称加密算法,双方通过 ECDHE 交换参数协商出对称密钥。
            GCM:Galois计数器模式(Galois/Counter Mode)。消息认证码(MAC,Message Authentication Code)用于保障消息的完整性,防止各种伪造。AES-CMAC 使用分组密码,取代 HMAC 的加密散列函数。Galois 消息认证码(GMAC)则采用了 AES 算法的一种特殊模式。

            主流加密算法趋势是 AES(128/256),加密模式的趋势是 GCM。
            GCM 是一种特殊的称为 AEAD 的加密模式,不需要配合 MAC。  
     

    From:https://blog.csdn.net/phunxm/article/details/72853552

    展开全文
  • 开篇 ECDHE_RSA浅析

    千次阅读 2020-03-02 16:09:25
    开篇 ECDHE_RSA浅析 凡事都有个起因,这是本人的第一篇博客,之前工作中,当碰到技术问题时,在度娘一搜,如果有CSDN等各种博客的文章弹出,基本问题都可以得到解决,所以一致很佩服也很羡慕各种博主大神,因此自己...
  • ProxySG对ECDHE协议的支持
  • SSL_CTX_set_cipher_list (pComm->ssl_ctx, "ECDHE-ECDSA-AES128-CCM8")) { FWH_INFO ("tls_init: error selecting ECDHE-ECDSA-AES128-CCM8 cipher suite\n"); exit (0); } 采用openssl加密传输,使用函数SSL...
  • 1. ECDHE加密算法的简单数学原理:   ECDHE = ephemeral Elliptic Cure Diffie-Hellman,“短暂-椭圆曲线-迪菲-赫尔曼” 算法。 对于公式: A = G ^ a % P B = G ^ b % P 其中,G为底数,P为模数,a为对数,A为真...
  • ECDHE-RSA-AES256-GCM-SHA384 解释

    千次阅读 2020-04-22 11:56:42
    “密钥交换算法 + 签名算法 + ...“握手时使用 ECDHE 算法进行密钥交换,用 RSA 签名和身份认证,握手后的通信使用 AES 对称算法,密钥长度 256 位,分组模式是 GCM,摘要算法 SHA384 用于消息认证和产生随机数。” ...
  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

    千次阅读 2019-04-09 14:35:56
    TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 OpenSSL name: ECDHE-ECDSA-AES128-SHA256 GnuTLS name: TLS_ECDHE_ECDSA_AES_128_CBC_SHA256 Hex code: 0xC0, 0x23 TLS Version(s): TLS1.2 Prot...
  • TLSv1.2 ECDHE加密 解密
  • TLSv1.2密钥交换算法安全性及性能比较(RSA, DHE, ECDHE)
  • ECDHE)及他们在SSL/TLS协议中的应用RSA密钥交换算法DHE密钥交换算法ECDHE密钥交换算法参考 密钥交换算法的介绍稍稍来迟了一些,密钥交换算法应该在介绍SSH、SSL/TLS协议之前优先介绍。不过 Latter better than ...
  • 加密套件选用ECDHE_SM2_WITH_SM4_SM3,其中协议版本为TLS1.2,密钥交换(Key-Exchange)算法为ECDHE,认证(Authentication)算法为SM2,加密(Encryption)算法为SM4,消息认证码(Message-Authenticati...
  • 项目报错:Cannot support TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 with currently installed providers java.lang.IllegalArgumentException: Cannot support TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 with ...
  • 问题描述: 最近在使用dnspod api获取域名信息时,采用httpclient 4.3版本,jdk7,一直报ssl_handshark的问题,通过curl竟然可以,通过2次抓包,发现dnspod ...其实后面发现jdk8也不支持TLS_ECDHE_ECDSA_WITH_AES_...
  • <div><p>This change is basically the 2020 version of 18d23790 and will solve #2401, since those CBC ciphers get flagged by recent versions of Qualys SSL Labs or <a href="https://testssl.sh/">TestSSL...
  • ECDHE 算法具有前向安全,所以被广泛使用。 我在上一篇已经介绍了RSA 握手的过程,今天这一篇就「从理论再到实战抓包」介绍ECDHE 算法。 离散对数 ECDHE 密钥协商算法是 DH 算法演进过来的,所以我们先从 DH...
  • 在网上没有找到相关的资料,有大神知道麻烦可以告知一下

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 8,883
精华内容 3,553
关键字:

ecdhe