Can elliptic curve (25519) be used to encrypt file?

Question

This is probably a simple question, but I haven't been able to see it stated anywhere. Is it possible to directly encrypt a file (of any length) with some form of EC using the 25519 curve.

I know it's common to exchange a key with EC and then use symmetric encryption (AES) to encrypt a file, however I was curious if it was possible directly ?

I've seen the salsa20 and chacha stream ciphers but I am unsure if they are suitable. If so is there a pre-existing tool that can be used or is something like libsodium the way to go.

As you probably have guessed, I'm still in research mode and I'm fairly keen to use as many pre-existing tools as possible.

Answer 1

No, you cannot "directly" encrypt a file using ECC without generating your own algorithm. Encrypting a file would be extremely inefficient; this is because the block size of ECC is very small, leading to a very high overhead both with regards to data usage (the ciphertext would be strictly larger than the plaintext) as well as CPU-usage.

Yes, any curve can be used to encrypt something if it is suitable to perform ECDH. If ECDH is used then the curve can be used to implement EC-IES.

I've seen the salsa20 and chacha stream ciphers but I am unsure if they are suitable. If so is there a pre-existing tool that can be used or is something like libsodium the way to go.

Any secure cipher is suitable. It may be smart to go for some existing protocol/library if you haven't implemented a secure protocol or library yet.

---

Using authenticated encryption should be preferred.

Answer 2

In general, asymmetric encryption is slow, and generating a lot of ciphertext opens you to attack. Thus asymmetric encryption either provides signatures (small bits of encryption) or encryption of a symmetric algorithm, as you observe.

It's technically-feasible to encrypt large amounts of data with RSA or Curve 25519; it's just not particularly useful.

Answer 3

Ciphers are either block ciphers or stream ciphers. Stream ciphers process data byte by byte whereas block ciphers process them block by block.

Block ciphers can only encrypt entire blocks. E.g. AES can only encrypt 16 byte input to 16 byte output (regardless if AES-128, AES-192 or AES-256, this number just refers to the key length, not to the block size). The downside of block ciphers is that if you need to encrypt something that is not exactly as large as the block size, you need some kind of block chaining.

Asymmetric ciphers are actually block ciphers as well, so you can use them to encrypt any kind of data and also of any length using block chaining. However, asymmetric encryption is very slow and not intended to encrypt large amounts of data. Using them with block chaining for large amounts of data may open up possibilities for timing attacks, allowing to make educated guesses about the private key.

That's why one usually generates a random key, encrypts all data using that random key and a symmetric block cipher with chaining and in the end, encrypts only that random key using asymmetric encryption. That way the recipient of the data can simply decrypt the random key using his private key and then decrypt the rest of data with it. This hybrid approach has no disadvantage as long as the symmetric algorithm is at least as secure as the asymmetric one but it has plenty of advantages over just using asymmetric encryption.

Here is a Java implementation of ECIES using Curve25519. The data is encrypted using AES-256 with CBC chaining, then the AES key itself is encrypted using Curve25519 as described by ECIES.

Answer 4

You can indeed use curve 255-19 with ECIES to encrypt whatever needs to be encrypted. You may want to assess the performance of the scheme for your purpose before you make a final decision.