ECIES vs. RSA + AES

Question

I am confused about the distinction between RSA and ECC (Elliptic curve) when it comes to encryption and would appreciate it if someone could confirm if my understanding is correct.

When encrypting a large file using RSA, you:

1. Generate a random symmetric key
2. Encrypt the file using the symmetric key (AES for example)
3. Then you encrypt the symmetric key using the receiver's public key
4. You send the encrypted file + encrypted symmetric key
5. The receiver takes the encrypted symmetric key and decrypts it using his own private key
6. Then the receiver decrypts the file using the decrypted symmetric key

But if I understand correctly, encrypting using ECC is completely different, especially the order:

1. Instead of generating a random symmetric key, you "derive" it using ECDH (using sender's private key and receiver's public key)
2. Then you encrypt the file using the derived symmetric key (AES)
3. You hand this over to the receiver
4. The receiver derives the same shared key using ECDH (same logic as step 1)
5. The receiver decrypts the decrypted file using AES

Basically, there is no such thing as "asymmetric encryption" in ECIES. There is only symmetric encryption using AES, but it works like asymmetric encryption because the shared key is generated using asymmetric cryptography.

Questions

1. Is this correct?

Am I understanding this correctly? Is there no way to create a "single encrypted file" that gets shared with everyone (instead you have to generate a distinct encrypted file for each receiver)

2. Higher guarantee that only the receiver can open?

If you're effectively generating a different version for each user, does this mean ECIES (while it's more wasteful in terms of data generated and stored) has a higher guarantee of ONLY the receiver being able to open the message? Because in the case of RSA + AES there's only one encrypted file, if the session key gets leaked anyone can decrypt it, whereas in ECIES if a receiver wants to leak a message, he needs to leak his private key. Is this correct?

3. How to efficiently broadcast to multiple parties?

If this is the case, how would I implement 1-to-N broadcast encryption of a single message efficiently?

For example, let's say I want to send a single 1GB file to 1000 people. Everybody gets the same file.

1. RSA+AES: Using RSA + AES I can encrypt the file once and only generate N different encrypted keys. Let's say the encrypted file is 2GB and each encrypted key is 1KB. This means I end up with 2GB + 1000*1KB of data to transmit.
2. ECIES: But when using ECIES, I must generate N unique encrypted files, which means 2GB * 1000 = 2TB of data to transmit.

If my understanding is correct, this ECIES approach does not scale as well as RSA+AES. Am I misunderstanding something? How would one implement a broadcast encrypted messaging for ECIES?

Answer 1

1. Is this correct?

The principles are right, but a number of details are missing. Among these:

• For RSA
  • "Encrypt the file" can't be with AES only, since that's a 128-bit block cipher, and it would be insecure past 16 bytes. There is an operating mode involved, and likely it involves generation of an Initialization Vector. It's a good idea to use authenticated encryption (though in the context it won't provide authentication, since we are dealing with public-key encryption, and anybody can encipher anything). Also there's padding.
  • "Encrypt the symmetric key using the receiver's public key" is not textbook RSA applied to the symmetric key. Some padding mode (like RSAES-OAEP of PKCS#1v2.2) is used, or (like in RSA-KEM) the symmetric key used to encrypt the file is derived by some Key Derivation Function from the a wider key, itself encrypted by transformation from bytestring to integer, textbook RSA encryption, and transformation from integer to bytestring.
• For ECIES
  • At each use, the first step is that a random ephemeral secret integer $k$ is generated by the sender, $R\gets k\,G$ is computed and made part of the cryptogram, so that the Diffie-Hellman (or is it ElGamal) shared key $k\,Q_V=d_V\,R$ gets used only once, and can be recovered by the receiver [which private/public key pair is $(d_V,Q_V)$ with $Q_V=d_V\,G$ ].
  • In the key derivation step, a Key Derivation Function derives two symmetric keys from the shared secret.
  • In the encryption step, one of these keys is used for encryption, yielding the ciphertext, and in the missing "tagging operation" step, the other key is used to make a Message Authentication Code of the ciphertext (and possible other info). Otherwise said, authenticated encryption using encrypt-then-MAC is mandated by ECIES, when authenticated encryption is only good practice with RSA, and the way to achieve it unspecified.

---

2. Higher guarantee that only the receiver can open?

No. In both cases, only the receiver can decipher, as long as the underlying crypto stands secure.

The added insurance ECIES gives comes from the mandated use of authenticated encryption. Informally, it can't happen that the message is partially altered by an attacker, or that a decryption made by the receiver of an altered message is abused into allowing an attacker decipher a genuine message. In any case, the message is not authenticated, for there is no sender public/private key pair involved.

---

3. How to efficiently broadcast to multiple parties?

That's an issue for ECIES, and RSA when using RSA-KEM: since the symmetric key is derived by the asymmetric cryptography, it can't be identical for multiple recipients.

The solution is to draw a random symmetric authenticated-encryption key (e.g. for AES-GCM) used for the bulk of the file, as in RSA with RSAES-OAEP; and encipher that key to multiple recipients using ECIES, or RSA-KEM plus some cipher. In the case of RSA-KEM, it's still a good idea to use authenticated encryption for the encryption of the key, in order to not require resistance to related-key attack from the cipher used for the bulk of the file.