我正在构建一个使用BouncyCastle作为密码提供者的网络应用程序。假设你有以下代码来生成密钥对：
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密钥类型，但我认为两者表示的都是关于曲线上点的相同信息，或者我的理解完全错误吗？
我问这个问题的原因是，现在我的应用程序可以使用ECDH来建立AES秘密密钥，但是我想使用同一条EC密钥使用ECDSA对每个消息进行签名。
ECDSA和ECDH来自不同的标准(分别是ANSI X9.62和X9.63)，并用于不同的上下文环境。X9.63明确地重新使用了来自X9.62的元素，包括公钥的标准表示形式(例如在X.509证书中)。因此，ECDSA和ECDH密钥对在很大程度上可以互换。然而，一个特定的实现是否允许这种交换是一个开放的问题。历史上，(EC)DSA和(EC)DH来自不同的世界。
请注意，尽管如此，使用情境是相当不同的。加密技术比椭圆曲线计算要多一点;必须考虑"密钥生命周期"。简单地说，您不希望以相同的过程管理密钥协商密钥和签名密钥。例如，如果您丢失了密钥协商密钥(您的狗吃了智能卡——别笑，这真的发生过)，那么您就无法解密相对于该密钥加密的数据(例如发送给您并以加密格式存储的加密电子邮件)。从商业角度来看，密钥的丢失也可能意味着员工的流失(员工被解雇，被公共汽车撞了，或者退休了等等)。因此，加密密钥(包括密钥协商密钥)通常必须被托管(例如，私钥的副本被打印并存储在保险柜中)。另一方面，签名密钥的丢失不会造成数据丢失;之前发布的签名仍然可以验证;从这种损失中恢复就像创建一个新的密钥对一样简单。然而，托管系统的存在往往会自动削弱签名所附带的法律价值。
此外，在更普遍的基础上，我强烈建议不要在两个不同的算法中使用相同的私钥:算法之间的交互尚未得到充分探索(仅仅研究一个算法已经是一项艰苦的工作)。例如，如果有人开始向基于ECDH的协议提供从您计算出具有相同私钥ECDSA签名的曲线点，那会发生什么？
因此，您确实不应该重用ECDH和ECDSA的同一密钥。