Home/ Questions/Q 3944228
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-20T00:52:31+00:00

I’m building a network application that uses BouncyCastle as a cryptography provider. Let’s say

  • 0

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();

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?

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.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    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 ?

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

    • 0