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.
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.
