2
$\begingroup$

I have a file system with share resources over the network (like a shared FTP)

  • Is it possible to use the client's ECC public key to encrypt the AES key, and then use the AES in CRT mode for the file encryption? File size can be 1GB to 1TB.
$\endgroup$
3
$\begingroup$

I do not believe there would be any issues, as long as:

  • The problem you are attempting to solve is that you want to encrypt a file so that the client can decrypt it, but no one else can

  • The client has a public/private key pair

  • The encryptor has the client's public key and you somehow know that it's the client's public key

  • The encryptor has access to randomness (as the security of ECIES depends on it)

  • You add some integrity transform (along with the AES-CTR), to make sure that no one can modify the encrypted message without being detected. If you need a suggestion about which integrity transform to use, perhaps HMAC-SHA256 would work; alternatively, you could replace AES-CTR with (say) AES-GCM.

You appear to be concerned about the size of the file being encrypted; the public key portions could care less about how long the message is (it does the same thing regardless), and the AES-CTR portion can easily handle a terabyte without an issue.

You may want to consider breaking the file up into smaller pieces and encrypt and send each piece separately, but that is for purely practical reasons (e.g. if one of the smaller pieces get corrupted, the receiver can ask for that specific piece to be resent, and not the entire 1Tb file); however the cryptographical security would not depend on that.

$\endgroup$
  • 2
    $\begingroup$ Encrypting a large file in one go is secure in theory, yes, but the practical benefits of breaking it up into chunks for encryption has security components. E.g., the Efail attack is tied to the fact that PGP implementations chose to stream plaintext out immediately as it's decrypted, but can only authenticate the message after they've done a pass through the whole of it. Encrypting and authenticating in small chunks offers a measure of foolproofing in this regard, because it allows decryption to abort when it comes across a forged chunk. $\endgroup$ – Luis Casillas Dec 14 '18 at 23:53
  • $\begingroup$ I took a look at AES-GCM, It seems a better choice, would like to give a try, $\endgroup$ – Charles Cao Dec 16 '18 at 0:48
3
$\begingroup$

The short answer is yes, ECIES can absolutely be instantiated with AES-CTR.

This bit of the question is slightly worrisome:

Is it possible to use the client's ECC public key to encrypt the AES key, [...]

That's not how ECIES works, strictly speaking. Your formulation makes it sound as if it encrypts a pregenerated AES key; but no, it derives one using a KEM (key encapsulation mechanism) that's implicitly built into the scheme, and a KDF (key derivation function) that's chosen by the implementer (e.g., HKDF).

$\endgroup$
  • 1
    $\begingroup$ Is (EC)DH really considered a KEM? I thought KEM referred to the practice of selecting key material at random and using a public-key encryption type of algorithm to create a ciphertext of it, and then send that to the receiver. In (EC)DH there is no a priori selection of the key material nor (as you mention) a way to use such a public key to encrypt the selected key material. $\endgroup$ – Ella Rose Dec 15 '18 at 0:35
  • 2
    $\begingroup$ I'm working off how Ch. 11 of Katz & Lindell formulates IES. First they define what a KEM scheme is (Definition 11.9, p. 390). Then they define a DDH-based KEM (Construction 11.19, p. 405). And finally, they offer Construction 11.23 (p. 409), a public key encryption scheme built off that KEM, which they equate with DHIES/ECIES. $\endgroup$ – Luis Casillas Dec 15 '18 at 1:31

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.