java - ECDH 和 ECDSA key 之间有区别吗？

Question

我正在构建一个使用 BouncyCaSTLe 作为加密提供程序的网络应用程序。假设您有此生成 key 对:

ECParameterSpec ecSpec = ECNamedCurveTable.getParameterSpec("prime192v1");
KeyPairGenerator g = KeyPairGenerator.getInstance("ECDSA", "BC");
g.initialize(ecSpec, new SecureRandom());
KeyPair pair = g.generateKeyPair();

我很困惑为什么您要获取 ECDSA KeyPairGenerator 的实例。为什么它不直接说EC？我知道 BouncyCaSTLe 附带了一个 ECDH key 类型，但我认为这两个代表关于曲线上的点的相同内容——或者我对它背后的理论完全错误？

我问的原因是，现在我的应用程序可以很好地使用 ECDH 来建立 AES key ，但现在我想使用相同的 EC key 来使用 ECDSA 对每条消息进行签名。

Answer 1

ECDSA 和 ECDH 来自不同的标准(分别为 ANSI X9.62 和 X9.63)，并在不同的上下文中使用。 X9.63 明确地重用了 X9.62 中的元素，包括公钥的标准表示(例如在 X.509 证书中)。因此，ECDSA 和 ECDH key 对在很大程度上是可以互换的。然而，给定的实现是否允许这种交换是一个悬而未决的问题。从历史上看，(EC)DSA 和 (EC)DH 来自不同的世界。

但请注意，使用上下文非常不同。密码学比椭圆曲线的计算要多一些；必须考虑“ key 生命周期”。简而言之，您不想使用相同的过程来管理 key 协商 key 和签名 key 。例如，如果您丢失了 key 协议(protocol) key (您的狗吃掉了您的智能卡——别笑，这真的发生了)，那么您将无法再解密相对于该 key 加密的数据(例如发送给您的加密电子邮件，以及以加密格式存储)。从业务的角度来看，丢失 key 也可能是失去员工(员工被解雇、被公共(public)汽车撞到、退休或其他)。因此，加密 key (包括 key 协商 key )必须经常被托管(例如，打印一份私钥副本并将其存储在保险箱中)。另一方面，丢失签名 key 意味着没有数据丢失；以前签发的签名仍然可以验证；从这种损失中恢复就像创建一个新的 key 对一样简单。然而，托管系统的存在往往会自动剥夺签名可能附加的任何合法值(value)。

此外，在更一般的基础上，我强烈建议不要在两种不同的算法中使用相同的私钥:算法之间的交互尚未得到充分探索(仅研究一种算法已经很困难)。例如，如果有人开始向您的基于 ECDH 的协议(protocol)提供从您使用相同私钥计算的 ECDSA 签名中提取的曲线点，会发生什么情况？

所以你真的不应该为 ECDH 和 ECDSA 重复使用相同的 key 。