我的公众号:密码学人CipherHUB 本文描述一种客户端-服务器加密通信方案,核心流程结合临时ECDH密钥交换、HKDF密钥强化、AES-GCM数据加密三阶段技术栈。 通过ECDH算法计算共享密钥 SharedSecret = ECDH(ECC-Tmp-Key-B_Private, ECC-PERSIST-KEY-A) 安全逻辑:前向保密基础,会话密钥与服务器私钥无直接关联 敏感数据(SecretPlain)使用AES-GCM加密 {Cipher, Tag} = AES-GCM-Encrypt(DerivedKey, SecretPlain) 优化点:HKDF消除原始ECDH 设计思想 现代密码学分层设计思想: 非对称层:ECDH提供密钥协商(临时密钥实现前向保密) 转换层:HKDF消解算法耦合,输出标准化密钥 对称层:AES-GCM实现高速保密通信undefined
前面有几篇blog就提到我有计划支持使用ECDH密钥交换。近期也是抽空把以前的DH密钥交换跨平台适配从atgateway抽离出来,而后接入了ECDH流程。 背景 对DH和ECDH算法的具体原理这里不做具体介绍了,可以点击链接看。DH和ECDH的主要的作用就是在通信双方发送一些公有参数,保留私有参数,而后通过一系列计算双方都能够得到一个一致的结果。 ECDH和DH 使用ECDH做密钥交换得时候你可能也会看到ECDHE这个词,这个多出来的E的意思是指每次公钥都随机生成。因为像HTTPS里那种是可以从证书文件里取静态公钥的。 )) == NULL) || (EC_KEY_get0_public_key(ecdh) == NULL) || (EC_KEY_get0_private_key(ecdh) == NULL [ OK ] crypto_dh.dh (228.725 ms) [ RUN ] crypto_dh.ecdh [ RUNNING ] Test ECDH algorithm
_256_CBC_SHA,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES _128_CBC_SHA,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,TLS_ECDH_ECDSA_WITH_RC4_128_SHA,TLS_ECDH_RSA_WITH_RC4_ _256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDH_RSA_WITH_AES _128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDH_RSA_WITH_AES _128_GCM_SHA256,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDH_RSA_WITH_AES
256 bit ECDH (P-256) Android 7.0 TLSv1.2 ECDHE-RSA-CHACHA20-POLY1305, 253 bit ECDH (X25519) Chrome -POLY1305, 253 bit ECDH (X25519) Firefox 53 Win 7 TLSv1.2 ECDHE-RSA-CHACHA20-POLY1305, 253 bit ECDH ECDH (P-256) Edge 15 Win 10 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 253 bit ECDH (X25519) Opera 17 Win , 256 bit ECDH (P-256) Safari 9 OS X 10.11 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256) bit ECDH (P-256) Java 6u45 TLSv1.0 AES128-SHA Java 7u25 TLSv1.0 ECDHE-RSA-AES128-SHA, 256 bit ECDH
The server supports these methods: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256, ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512 diffie-hellman-group14-sha256 解决 vim /etc/ssh/sshd_config 添加 KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2 -nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14
The server supports these methods: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256, ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512 diffie-hellman-group14-sha256 通过web管理终端登录系统 编辑/etc/ssh/sshd_config 在最下面新增 KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2 -nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14 -nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14
而 requests 里面默认的加密算法如下 参考文件:https://www.cnblogs.com/Eeyhan/p/15662849.html ECDH+AESGCM:DH+AESGCM:ECDH +AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+HIGH:DH+HIGH:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+HIGH: HTTPAdapter from requests.packages.urllib3.util.ssl_ import create_urllib3_context ORIGIN_CIPHERS = ('ECDH +AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+HIGH:' 'DH+HIGH:ECDH+3DES:DH+3DES:RSA +AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+HIGH:DH+HIGH:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+HIGH:
DH:ECDH是DH的加强版 ECDH: DH算法的加强版, 常用的是NIST系列,但是后面curve25519 curve25519: 实质上也是一种ECDH,但是其实现更为优秀,表现的更为安全,可能是下一代秘钥交换算法的标准 ECDH即建立在此数学难题之上 ECDH 和 curve25519 go的实现 引用: 密码学简介与Golang的加密库Crypto的使用 package main import ( "crypto" 秘钥交换算法的主接口 type ECDH interface { GenerateKey(io.Reader) (crypto.PrivateKey, crypto.PublicKey, error Bernstein的椭圆曲线算法:Curve25519来创建ECDH实例 // 因为Curve25519独立于NIST之外, 没在标准库实现, 需要单独为期实现一套接口来支持ECDH func NewCurve25519ECDH () ECDH { return &curve25519ECDH{} } type curve25519ECDH struct { ECDH } // GenerateKey 基于curve25519
而 requests 里面默认的加密算法如下: ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+HIGH:DH+HIGH :ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+HIGH:RSA+3DES:! HTTPAdapter from requests.packages.urllib3.util.ssl_ import create_urllib3_context ORIGIN_CIPHERS = ('ECDH +AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+HIGH:' 'DH+HIGH:ECDH+3DES:DH+3DES:RSA
-GCM-SHA384 ssl_options.ciphers.7 = ECDH-RSA-AES256-GCM-SHA384 ssl_options.ciphers.8 = ECDH-ECDSA-AES256 -SHA384 ssl_options.ciphers.9 = ECDH-RSA-AES256-SHA384 ssl_options.ciphers.10 = DHE-DSS-AES256-GCM-SHA384 -GCM-SHA256 ssl_options.ciphers.19 = ECDH-RSA-AES128-GCM-SHA256 ssl_options.ciphers.20 = ECDH-ECDSA-AES128 -SHA ssl_options.ciphers.30 = ECDH-RSA-AES256-SHA ssl_options.ciphers.31 = AES256-SHA ssl_options.ciphers -SHA ssl_options.ciphers.37 = ECDH-RSA-AES128-SHA ssl_options.ciphers.38 = AES128-SHA 部署完以后,会有一个坑,http
通信双方 Alice 和 Bob 使用 ECDH 密钥交换协议进行密钥协商,ECDH 密钥交换协议拥有两个算法: 密钥生成算法 ECDH_Generate_Key,输出一个公钥和私钥对 (ECDH_pub_key , ECDH_pri_key),ECDH_pri_key 需要秘密地保存,ECDH_pub_key 可以公开发送给对方。 当 Bob 将他的 Bob_ECDH_pub_key 发送给 Alice 时,攻击者可以截获 Bob_ECDH_pub_key,自己运行 ECDH_Generate_Key 算法 产生一个公钥/私钥对, 消息认证码的认证方式需要一个私密的 Key,由于此时没有一个私密的 Key,因此 ECDH 认证密钥协商就是 ECDH 密钥协商加上数字签名算法。 回顾一下,上面描述的带认证的 ECDH 协商过程,似乎已经足够安全,无懈可击了,但是,面对成亿的客户端发起 ECDH 握手到成千上万台接入层机器,每台机器对一个 TCP 连接随机生成不同的 ECDH 公私钥对
可选的主要的密钥交换算法包括: RSA, DH, ECDH, ECDHE。可选的主要的证书算法包括:RSA, DSA, ECDSA。两者可以独立选择,并不冲突。 -GCM-SHA384 ssl_options.ciphers.6 = ECDH-RSA-AES256-GCM-SHA384 ssl_options.ciphers.7 = ECDH-ECDSA-AES256 -GCM-SHA256 ssl_options.ciphers.18 = ECDH-RSA-AES128-GCM-SHA256 ssl_options.ciphers.19 = ECDH-ECDSA-AES128 ECDH-ECDSA-AES256-SHA384", "ECDH-RSA-AES256-SHA384", ECDH-ECDSA-AES128-SHA256", "ECDH-RSA-AES128-SHA256",
通信双方Alice和Bob使用ECDH密钥交换协议进行密钥协商,ECDH密钥交换协议拥有两个算法: 密钥生成算法ECDH_Generate_Key,输出一个公钥和私钥对(ECDH_pub_key, ECDH_pri_key ),ECDH_pri_key需要秘密地保存,ECDH_pub_key可以公开发送给对方。 当Bob将他的Bob_ECDH_pub_key发送给Alice时,攻击者可以截获Bob_ECDH_pub_key,自己运行ECDH_Generate_Key算法产生一个公钥/私钥对,然后把他产生的公钥发送给 这里说明一下:ECDH协商中,如果公私钥对都是临时生成的,一般称为ECDHE,因此1-RTT的ECDH协商方式被称为1-RTT ECDHE握手,0-RTT 中有一个静态内置的公钥,因此称为0-RTT ECDH 回顾一下,上面描述的带认证的ECDH协商过程,似乎已经足够安全,无懈可击了,但是,面对成亿的客户端发起ECDH握手到成千上万台接入层机器,每台机器对一个TCP连接随机生成不同的ECDH公私钥对,这里试想一种情况
临时公钥,同时回复 ServerKeyExchange 消息; 第三步,客户端接收 ServerKeyExchange 后,使用证书公钥进行签名验证,获取服务器端的 ECDH 临时公钥,生成会话所需要的共享密钥 ;生成 ECDH 临时公钥和 ClientKeyExchange 消息发送给服务端; 第四步,服务器处理 ClientKeyExchange 消息,获取客户端 ECDH 临时公钥;服务器生成会话所需要的共享密钥 将客户端发送 ECDH 临时公钥的过程提前到 ClientHello,同时删除了 ChangeCipherSpec 协议简化握手过程,使第一次握手时只需要 1-RTT,来看具体的流程: ? 、DH 密钥交换参数列表 KeyShare; 服务端回复 ServerHello,包含选定的加密套件;发送证书给客户端;使用证书对应的私钥对握手消息签名,将结果发送给客户端;选用客户端提供的参数生成 ECDH DH 参数计算出用于加密 HTTP 消息的共享密钥;服务端生成的临时公钥通过 KeyShare 消息发送给客户端; 客户端接收到 KeyShare 消息后,使用证书公钥进行签名验证,获取服务器端的 ECDH
requests.packages.urllib3.util.ssl_ import create_urllib3_context CIPHERS = ( 'ECDH +AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+HIGH:' 'DH+HIGH:ECDH
这种用法没有前向安全性,因此在 TLS 1.3中被废弃了 ECDH_ECDSA / ECDH_RSA 能做 ECDH 用途的公钥;公钥必须使用 客户端支持的ec曲线和点格式。 其中有5种是ECC密钥交换算法:ECDH_ECDSA, ECDHE_ECDSA, ECDH_RSA, ECDHE_RSA, ECDH_anon。 注意这也意味着DH_DSS,DH_RSA,ECDH_ECDSA,和ECDH_RSA 密钥交换不限制签署证书的算法。 对下面几种密钥交换方法,发送ServerKeyExchange消息是非法的: RSA DH_DSS DH_RSA ECDH_ECDSA ECDH_RSA 需要注意的是,ECDH和ECDSA公钥的数据结构是一样的 rsa_fixed_ecdh / ecdsa_fixed_ecdh 可以用作 ECDH 的公钥。
server 二、解决方法: 追加KexAlgorithms vim /etc/ssh/sshd_config KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2 -nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group14-sha1 重启 service sshd restart
Au=RSA Enc=AESGCM(128) Mac=AEAD 0xC0,0x2B - ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD 0xC0,0x27 - ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au =RSA Enc=AES(128) Mac=SHA256 0xC0,0x23 - ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au =ECDSA Enc=AES(128) Mac=SHA256 0xC0,0x13 - ECDHE-RSA-AES128-SHA SSLv3 Kx=ECDH Au Au=ECDSA Enc=AESGCM(128) Mac=AEAD 0xC0,0x23 - ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH
CTB_Locker勒索软件加密用户文件的所用算法主要是AES算法和ECDH算法。其 ECDH算法选用curve25519曲线。 关于ECDH算法和curve25519曲线的更多细节可以在wiki 上找到: ECDH : <点击原文查看链接> curve25519 : <点击原文查看链接> 必须指出的是,ECDH是一种密钥协商算法 CTB_Locker勒索软件的加密过程可以粗略地理解为3层加密,第一层是运用内置在样本中的公钥通过ECDH算法加密随机生成的 ECDH密钥: ? 粗略地,TeslaCrypt勒索软件同样采用三层加密方法,第一层中,使用样本中内置ECDH公钥加密随机生成的 ECDH 密钥。第二层中,使用随机生成的ECDH密钥加密随机生成的AES密钥: ? 使用三层加密算法,ECDH+ECDH+AES等,如2.2章节所述的勒索软件等。 5.
导语2022年10月份,隐语发布了PSI的性能数据,当时就引起了内部和外部用户的广泛关注,具体协议包括:ecdh/kkrt16/bc22协议,这些协议更适合双方数据量差别不大的场景,称为平衡PSI(Balanced 具体来讲:与ecdh-psi对比,ecdh-psi在大数据集上进行两次加密操作。 隐语实现的非平衡PSI只在大数据集上进行一次加密操作,在大数据集与小数据集的体量相差非常大的时候,总体计算量和运行时间大约是ecdh-psi的1/2。 数据要求Alice方:2000万Bob方:20亿交集:1000万六、Benchmark脚本脚本分为offline和online,offline用于对大数据方的setup、online对小数据的执行基于ecdh Unbalanced PSI的online阶段,可以划分为两部分子阶段,对小数据集数据执行ecdh-oprf得到小数据集的加密结果;小数据集加密结果和offline阶段的到大数据集加密数据进行比较的到交集