ECDSA keys are much shorter than RSA keys, but typically only used for signing, not encryption.

Is there an accepted way of doing this?

(https://bitcointalk.org/index.php?topic=196378.0 deliberately says don't use it.)

Note: I'm only looking at encrypting tens of bytes of data, so no AES suggestions please.

  • 5
    $\begingroup$ ECIES (or something similar) is the way to go. I don't see why AES based authenticated encryption wouldn't be a good fit. Of course reusing a key for encryption and signing is a bit of a risk, but IMO it's an acceptable one. $\endgroup$ Commented Mar 19, 2015 at 11:27
  • $\begingroup$ What are your goals and limitations? Why would a hybrid encryption scheme - as normally used with ECC - not be a good fit? $\endgroup$
    – Maarten Bodewes
    Commented Mar 19, 2015 at 11:43
  • $\begingroup$ @CodesInChaos I'm looking for Public Key Encryption of tens of bytes, not symmetric encryption. $\endgroup$
    – fadedbee
    Commented Mar 20, 2015 at 11:12
  • $\begingroup$ @MaartenBodewes I think a hybrid system is unnecessary for tens-of-bytes. A goal is short (easily-pasteable), secure, keys. $\endgroup$
    – fadedbee
    Commented Mar 20, 2015 at 11:14
  • $\begingroup$ @chrisdew A hybrid system is the way to go with ECC. The alternative is EC-ElGamal and that's clearly an inferior choice. The overhead for ECIES with AES-GCM over a 256 bit curve is 48 bytes, 32 for the ephemeral public key and 16 for the MAC. Or you could simply use NaCl's Box operation, which is conceptually very similar to ECIES. $\endgroup$ Commented Mar 20, 2015 at 11:54

1 Answer 1


The ECDSA algorithm can't be used for encryption. It's not that there's no accepted way to do it, it's that it's simply not possible to do so. Likewise, RSA signing can't be used to encrypt (there's a mandatory hash in signing that you don't want in encryption). However, RSA signatures work similarly to RSA encryption; they aren't interchangeable, but fundamentally RSA signing, verification, encryption, and decryption all revolve around running the RSA operation on some data $m$ with one of the exponents $e$ (i.e. computing $m^e\pmod{n}$). You could, by making some not-huge changes to RSA signing, get an encryption scheme.

In contrast, ECDSA looks fairly different from any encryption algorithm. Verification looks nothing like signing, and the private key and public key are different things (one's a point, one's a number), so with the public key you can't do anything that looks like signing. A change to let you encrypt wouldn't be called ECDSA, as it wouldn't particularly resemble it.

(There are ECC signing and encryption schemes both called ElGamal; ECDSA is based on ElGamal signing. However, they just share a name because that's the guy who invented both of them; they don't look particularly similar, aside from both relying on discrete logarithm. RSA encryption and signing might also have had different names if they weren't invented by the same people.)

So ECDSA simply can't be used for encryption -- it looks fundamentally different from encryption schemes. What the person on that site did was create an encryption scheme unrelated to ECDSA (but rather similar to ElGamal encryption) that happens to use the same key format. ECDSA keys, ECDH keys, ECIES keys without shared secrets, ElGamal encryption keys, ElGamal signing keys, and the keys of most other ECC systems I'm aware of look rather similar: there's a set of curve parameters (which are generally the same for everyone), and then the private key is an integer $k$ and the public key is $k$ times the generator point found in the curve parameters. This is the standard keypair for something relying on discrete logarithms; with DH and DSA, the keypair is also basically that (just replace $k\times G$ with $g^k$). In that sense, there are all sorts of ways to use ECDSA-style keys for encryption; ECIES is probably your best bet.

That said, ECDSA keys should not be directly reused as encryption keys. Using the same key for two schemes generally a bad idea (they aren't designed for that, and may interact insecurely), and there are often differences in key management between encryption and signing. However, the general structure is already used in plenty of encryption systems.

  • $\begingroup$ The question was about ECDSA(-style) keys, not the algorithm. The point of ECDSA kays is that I have read that they are much more secure, for a given bit length, than RSA keys. What I am looking for is a Public Key Encryption system, with keys of a pasteable size. (Like Bitcoin's addresses.) Thanks for the warning against using the same keys for encryption and signing - using Bitcoin addresses' private keys could lead to vulnerability if reused for encryption. $\endgroup$
    – fadedbee
    Commented Mar 20, 2015 at 11:11
  • $\begingroup$ You heard that ECDSA keys are more secure since there is not index calculus attack as in DSA and classical Diffie-Hellman. So the elliptic curve variants of DSA and DH are more efficient and since there is not index caclulus i.e. sub-exponential time attack, we can say that is more secure. ECDSA keys are used for signing only. $\endgroup$
    – 111
    Commented Mar 21, 2015 at 22:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.