I know that ECDSA is used for signature only, but I wonder if I can use the public/private Elliptic Curve keys for encryption too.

I have ECDSA SSH public keys and I wonder if I can use them to encrypt data that only the matching machine could decrypt, writing the proper software.

Pointers welcomed.


Of course you can use Elliptic Curve cryptography to do public key encryption, that is, a method with a public key and a private key; anyone with the public key can encrypt, but only someone with the private key can decrypt.

One way would be to use the Integrated Encryption System. It's does most everything for you (allowing the encryption of arbitrary sized plaintext efficiently, and throws in an integrity check as well).

However, in your case, I do see two potential pitfalls:

  • If all you got is some software that verifies an ECDSA signature, I don't know how that could be used to generate ECIES ciphertexts - or any other type of ciphertext. Something that verifies a signature may only produce one bit of output ("it verified" or "it didn't"); it does not need to export any of its internal computations. On the other hand, if you do have something that does a 'point multiplication' - and you don't mind putting together everything else ECIES needs to run - this may not be an issue for you.

  • I also wouldn't recommend you use their existing ECDSA keys with that scheme; it doesn't look like it should cause any weaknesses. I mean that I don't believe that an attacker could send them a 'ciphertext' that, if they decrypt it and reveal the plaintext, that it would enable the attacker to generate an ECDSA forgery; I don't believe that someone could ask for a specific message to be signed, and use that signature to decrypt an ECIES-encrypted message); it however still makes me nervous. Good crypto hygiene says to use a key for only one purpose (unless there's a proof somewhere that it is safe for both uses).

Instead, if possible, I would suggest that the devices create a separate encryption key; generating EC public/private key pairs are cheap.

  • 1
    $\begingroup$ I currently store in a database the ECDSA SSH keys of a ton of appliances. Was wondering if I could use them to deploy firmware patches "private" for each device. Generating a new EC pair would be easy, but I already have a EC pair (SSH) and I was wondering if "reusing" it for encryption would be fair and secure. I already have EC crypto software written, I was wondering about "importing" the ECDSA keys in it for encryption. In a way, my question is if there is any reason a ECDSA pair should not be used for encryption too. $\endgroup$ – jcea Feb 24 '14 at 2:25
  • 2
    $\begingroup$ @jcea: grumble, I can almost "see" a proof that it's safe (any ECIES ciphertext that is not generated with a specific "shared secret" in mind will with high probability fail the MAC check, and hence the attacker will learn nothing; when ECDSA signs a value, the signer picks a random 'k' value which the attacker cannot influence, hence he cannot ask for a signature to allow him to decrypt something somehow). However, I am not confident enough that I haven't missed something to give you absolution; I don't see a problem, but that doesn't mean that one's not there. $\endgroup$ – poncho Feb 24 '14 at 3:37
  • 2
    $\begingroup$ I agree that using ECIES and ECDSA with the same key is probably safe, but that you shouldn't do it. About provability: I don't think a proof of security for ECDSA is known (not counting generic group model proofs). A proof of joint security would imply a proof of ECDSA security, so we can't expect such a joint proof. Probably you could prove that the ECDSA signing oracle doesn't break ECIES if you only sign each message once. $\endgroup$ – K.G. Feb 24 '14 at 7:38
  • $\begingroup$ Using the same keys for encryption and signing is usually a bad idea (regardless of scheme): If an attacker can make trick you into signing something, then this can be used to actually make you decrypt an encrypted message. $\endgroup$ – tylo Feb 24 '14 at 10:08
  • 2
    $\begingroup$ @tylo: how would signing an attacker-selected message using ECDSA allow you to decrypt an ECIES-encrypted message (assuming that the same private key was used by both)? It's pretty obvious with "textbook RSA", however it's not obvious in this case. $\endgroup$ – poncho Feb 24 '14 at 13:41

ECDSA is a signature algorithm derived from ECC (elliptic curve cryptography). So in a way encryption even "came first".

Asymmetric encryption is very inperformant though. You could in principle use common schemes like Cipher-Block-Chaining (CBC) to encrypt large files asymmetrically, but the gains do not justify the means.

What is typically done (eg in email encryption) is to encrypt the data symmetrically (eg with AES-CBC) with a random key, encrypt the key asymmetrically with the ECC key and prepend it to the encrypted data.

But then again there is the question of why you would want to do this. If the private key is stored on the computer unencrypted, then you could just as well create a random keyfile and use it to encrypt and decrypt whatever you wanted to store. As long as no other computer knows this keyfile only this one machine will be able to decrypt the data. The big advantage of asymmetric encryptions like ECC is that the person encrypting the data need not know the key that is used to decrypt. In fact the key used for encryption can be public (thus the name public key ;) ). Anybody who knows this public key can encrypt data that only the person / machine with the right private key will be able to decrypt. Unless you need this behaviour I would advice you to simply use a keyfile.


In order to encrypt with ECC you have to take a look at El-Gamal. As mentioned above, ECIES is a common way to do it but it is based on symmetric keys and it forces both sides to agree on the key while the idea with PKI encryption is that one can publish his public key so anyone can send data that can be read only by the publisher.

  • $\begingroup$ In fact, ECIES uses ElGamal internally, but provides a better and more secure interface. $\endgroup$ – SEJPM Jun 1 '15 at 20:02
  • $\begingroup$ ECIES is a public key encryption system; one side has a public key and uses that to encrypt, the other side has the private key and that allows him to decrypt. $\endgroup$ – poncho Jun 2 '15 at 23:17
  • $\begingroup$ ECIES uses also a common secret and symmetric keys unlike pure asymmetric methods that are not based on a common secret but encrypt directly with the other party public key $\endgroup$ – Simon Jun 4 '15 at 5:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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