ECDH和ECDSA密钥之间有区别吗？ [英] Is there a difference between ECDH and ECDSA keys?

问题描述

我正在构建一个将BouncyCastle用作加密提供程序的网络应用程序。假设您要生成一个密钥对：

I'm building a network application that uses BouncyCastle as a cryptography provider. Let's say you have this to generate a keypair:

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类型，但我认为两者在曲线上的点代表相同的东西-还是我完全不理解其背后的理论？

I'm confused as to why you're getting an instance of an ECDSA KeyPairGenerator. Why doesn't it just say EC? I know that there's an ECDH Key type that is shipped with BouncyCastle, but I thought that the two represented the same stuff about the points on the curve -- or am I completely wrong with the theory behind it?

我问的原因是现在我的应用程序使用ECDH fine建立了AES密钥，但是现在我想使用相同的EC密钥来使用ECDSA签名每条消息。

The reason that I ask is that right now my application uses ECDH fine to establish an AES secret key, but now I want to use the same EC key to sign each message using ECDSA.

推荐答案

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

ECDSA and ECDH are from distinct standards (ANSI X9.62 and X9.63, respectively), and used in distinct contexts. X9.63 explicitly reuses elements from X9.62, including the standard representation of public keys (e.g. in X.509 certificates). Hence, ECDSA and ECDH key pairs are largely interchangeable. Whether a given implementation will permit such exchange, however, is an open question. Historically, (EC)DSA and (EC)DH come from distinct worlds.

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

Note, though, that usage contexts are quite distinct. There is a bit more to cryptography than computations on elliptic curves; the "key lifecycle" must be taken into account. In plain words, you do not want to manage key agreement keys and signature keys with the same procedures. For instance, if you lose your key agreement key (your dog eats your smartcard -- do not laugh, it really happens), then you can no longer decrypt data which was encrypted relatively to that key (e.g. encrypted emails sent to you, and stored in encrypted format). From a business point of view, the loss of a key can also be the loss of an employee (the employee was fired, and was struck by a bus, or retired, or whatever). Hence, encryption keys (including key agreement keys) must often be escrowed (for instance, a copy of the private key is printed and stored in a safe). On the other hand, loss of a signature key implies no data loss; previously issued signatures can still be verified; recovering from such a loss is as simple as creating a new key pair. However, the existence of an escrow system tends to automatically strip signatures of any legal value that could be attached to them.

而且，在更一般的基础上，我会强烈建议建议不要在两种不同的算法中使用相同的私钥：尚未充分研究算法之间的交互（仅研究一种算法已经很辛苦了）。例如，如果有人开始使用从ECDSA签名中提取的曲线点（您使用相同的私钥计算）来提供基于ECDH的协议，该怎么办？

Also, on a more general basis, I would strongly advise against using the same private key in two distinct algorithms: interactions between algorithms have not been fully explored (simply studying one algorithm is already hard work). For instance, what happens if someone begins to feed your ECDH-based protocol with curve points extracted from ECDSA signatures which you computed with the same private key ?

所以您确实应该不要为ECDH和ECDSA重用相同的密钥。

So you really should not reuse the same key for ECDH and ECDSA.

这篇关于ECDH和ECDSA密钥之间有区别吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！