AES CBC mode is good for encrypting 15-20mb files and then sending it in parts?

Question

I want use CBC mode for sending and receiving files (avi, mp3, docx, jpeg) max up to 20mb. But also I want cut this file after encryption on sending site for example on 2mb size and send each file separately to receiver and on his site i will again join all 10 files together to one and then decrypt it.

Is CBC good mode for this? I have read some topics here (cryptography) that CBC is not good for sending only "part" of the file. But I don't know if this is also my case because: yes I am sending only parts of whole files but on the receiver site my code will wait until all parts are downloaded and then I will join all files together. After that I will encrypt whole 20mb file.

Is it OK to use CBC for this case? I am not trying to encrypt/decrypt only some parts of the file but always whole file after I join all sending parts correctly.

Answer 1

CBC can be used to make messages confidential even in transport security. After all, TLS often still uses CBC mode to encrypt the data frames. I'd say however that CBC is not the perfect mode for the job:

1. there are certain issues with using the last ciphertext block as IV for separate messages - so you would normally have to use the random number generator to generate a fresh IV and send it with the encrypted block of data;
2. you need to figure out if you want to use padding or not, CBC can only handle data that is precisely N times the block size, padding also introduces overhead;
3. CBC with a padding mode is vulnerable against padding oracle attacks, i.e. you should avoid communicating decryption errors to the sender now and in the future; if you do not do this then an attacker can decrypt your blocks and therefore your files.

For this kind of encryption counter (CTR) mode is much easier to get right. It doesn't require padding and you can simply keep counting for the next blocks. The only thing that is really a negative is that reusing a counter (initiated using the the nonce/IV) may completely destroy confidentiality. You can skip to an offset in the stream as a bonus.

If you also want protection against changes of the files you could use an authenticated mode of encryption such as GCM. In general authenticated modes use CTR mode under the hood. Of course using GCM and skipping together may be harder to get right.

---

Note that ciphertext size may be used to guess which files have been send. You could easily fingerprint collections of files by just monitoring the file sizes, if those file sizes are known in advance.

CBC makes this slightly more difficult as you don't know what part of the last ciphertext block contains plaintext / padding. Relying on such a small change for security doesn't seem to be a good idea though. But it is an advantage of CBC over CTR, even if it is a small one.

Answer 2

If file is reconstructed correctly CBC will not have problem with decryption. Also the file before encryption must be padded with respect size of AES block. You can read PKCS#7 padding.

Answer 3

If you find yourself reaching for the letters ‘AES’ or ‘CBC’, don't! Crypto engineering is already hard enough without having to worry about esoteric objects like a pseudorandom permutation family and a mechanism of whipping 128-bit blocks in chains with it.

If you must reach for something without thinking first about what you're trying to accomplish and what your threat model is and what security properties you want, reach for an authenticated encryption or AEAD scheme, e.g. NaCl crypto_secretbox_xsalsa20poly1305, or if you must use FIPS-approved acronym soup, then AES-GCM. AE(AD) lets a sender transmit a message (any number of bytes) to a receiver who shares a secret key, so that nobody else can read the message or fool the receiver into accepting a message the sender didn't send.

If you break the file into chunks, you can enclose the message in a secretbox (or an unpronounceable aesgcm) with a secret key known to the sender and receiver for this file, and a nonce equal to number of chunks sent so far. The security contract of secretboxes is that you must pick the secret key uniformly at random and never reuse it with a nonce. The receiver opens the secretbox and doesn't worry about padding or anything; if opening the secretbox fails then it was a forgery.

If you must use a single key for multiple files, then you can either find some way to derive subkeys from it, or transmit a freshly generated key for each file before its first chunk, or, with NaCl crypto_secretbox_xsalsa20poly1305, just pick each nonce independently uniformly at random because the probability of collision in a 192-bit value is negligible.

See also chain and miscreant for a not-(yet)-standardized scheme and preliminary practical implementation of online streaming AEAD, which is basically what you seem to be looking for, and the CAESAR competition for a competition to pick the coolest-sounding AEAD acronym, with tough contestants like AEZ and NORX.