Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

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.

Thanks!.

share|improve this question
    
Very similar to Using same keypair for Diffie-Hellman and signing –  CodesInChaos Feb 24 at 14:11
add comment

2 Answers 2

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.

share|improve this answer
    
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. –  jcea Feb 24 at 2:25
    
@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. –  poncho Feb 24 at 3:37
1  
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. –  K.G. Feb 24 at 7:38
    
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. –  tylo Feb 24 at 10:08
    
@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. –  poncho Feb 24 at 13:41
show 2 more comments

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

Asymmetric encryption is very inperformant though. You could in principle use common shemes like cypher-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 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 privte key will be able to decrypt. Unless you need this behaviour I would advice you to simple use a keyfile.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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