关于ECDSA防止中间人的问题

[BruceVan1987]

注意到，由于签名算法中的公钥ECDSA_verify_key是一直公开的，攻击者没有办法阻止别人获取公钥，除非完全掐断发送方的通信。这样一来，中间人攻击就不存在了，因为Eve无法伪造签名。具体过程如图5所示：

关于这一点不是很理解——中间人（Eve)仍然可以:

1. 拦截客户端的请求后，通过自己生成一对sign_key和verify_key
2. 篡改Bob_ECDH_pub_key之后，将中间人自己生成的signature_eve、eve_verify_key 和 eve_ECDH_pub_key，发给服务端
3. 同理对客户端。

不知道我的理解中哪个部分是有问题的部分呢？

还是说，原本微信的sign_key和verify_key其实是根据static_svr_pub_key生成的，所以中间人在不破解客户端代码的情况下，生成的sign_key和verify_key无法通过微信后端校验？

[dourgulf]

verify_key是保存在客户端的，中间人自己产生的sign_key和客户端保存的verify_key不是一对的，中间人产生的签名信息，在客户端的验证就不会通过了。

[cjs-2020]

由于VX中只对服务器进行校验，所以把服务器生成的ECDSA公钥Alice_Verify_Key直接保存在客户端，客户端不再使用ECDSA_generate_key()方法生成签名密钥，而只在服务器生成（原文继续往下看后面有)。故上图中ECDSA_sign以及服务器ECDSA_Verify中的Bob_verify_key在实际应用中应该是Alice_Verify_Key。

[xiaoxiaScut]

这是来自QQ邮箱的动回复邮件。   您好，你的邮件已成功接收。

[tcc0lin]

由于VX中只对服务器进行校验，所以把服务器生成的ECDSA公钥Alice_Verify_Key直接保存在客户端，客户端不再使用ECDSA_generate_key()方法生成签名密钥，而只在服务器生成（原文继续往下看后面有)。故上图中ECDSA_sign以及服务器ECDSA_Verify中的Bob_verify_key在实际应用中应该是Alice_Verify_Key。

是的，端上的公钥相当于是公开的，服务端将通过私钥生成的签名发过来

[xiaoxiaScut]

这是来自QQ邮箱的动回复邮件。   您好，你的邮件已成功接收。