0
$\begingroup$

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.

$\endgroup$
  • 1
    $\begingroup$ Who /what will manage the rejoining of the parts into the correct order? $\endgroup$ – Paul Uszak Jun 26 '17 at 15:37
  • $\begingroup$ Are you checking integrity of the parts? Don't forget to do it, otherwise you will get the avalanche effect to corrupt the whole files with CBC. $\endgroup$ – Lery Jun 26 '17 at 15:59
  • $\begingroup$ I will do my own code for 'cutting&joining' files in javascript. My point is if it is ok if I will do this... $\endgroup$ – daniel Jun 26 '17 at 18:15
  • $\begingroup$ use GCM mode, encrypt whole file, and then send it in chunks, once all chunks have been combined decrypt it. use of GCM mode will provide integrity check also, so you will be able to detect if file is corrupted on decryption $\endgroup$ – khan Aug 26 '17 at 18:01
  • $\begingroup$ Use new IV for each encryption if you are planning to use CBC mode. $\endgroup$ – khan Sep 26 '17 at 6:04
1
$\begingroup$

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.

$\endgroup$
  • $\begingroup$ Maarten like always your answer is amazing and very helpful!!! Many thx! I have one Q. Maybe you will know answer :) Is also ProtonMail email using encryption AES256 for attachments? If no do you know what are they using? Because I see that it is really hard to use AES for sending and receiving atachmnets :( $\endgroup$ – daniel Jun 27 '17 at 13:55
  • $\begingroup$ They've got their specs on their site if I remember correctly. I'd rather not comment on them without (another) study. I've got only a few relations that use ProtonMail. $\endgroup$ – Maarten Bodewes Jun 27 '17 at 14:17
  • $\begingroup$ Maarten I have also second Q. If I will use always for each file another key with also different size it will be also changing overall size of encrypted file and this can also add some more security? What I mean with key I don't mean that main 256bitAES key but I mean "personal" key (phrase) which I want use for each file new one cca 20-40 letters big. (I am coding for this special generator for this unique phrases) $\endgroup$ – daniel Jun 27 '17 at 14:18
  • $\begingroup$ "I will use always for each file another key with also different size it will be also changing overall size of encrypted file and this can also add some more security?" no, for symmetric keys the size of the ciphertext does not depend on the key size (and only a tiny bit on the block size). Changing the key size or password all the time won't enhance security. Higher key sizes currently only help to protect against Quantum Computing (QC), otherwise even AES-128 is pretty secure. Just use the maximum size for passwords; adding all kinds of password sizes doesn't help at all $\endgroup$ – Maarten Bodewes Jun 27 '17 at 15:31
  • $\begingroup$ Wait Maarten but if I will use AES 256 but I will have my password for example "123" and then I will use password "La147TRED$#-47Kpe>" the security of that encrypted file will be same? THX $\endgroup$ – daniel Jun 27 '17 at 17:20
0
$\begingroup$

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.

$\endgroup$
  • $\begingroup$ VovCA. It is possible to explain me little more what you mean with this sentence. ''Also the file before encryption must be padded with respect size of AES block. You can read PKCS#7 padding.'' thx $\endgroup$ – daniel Jun 26 '17 at 18:24
  • $\begingroup$ if you'll use openssl to encrypt the big file it'll do padding for you. AES is encrypting block by block which is equal of the key/iv size. If file is not aligned with AES block size, then what to to with the last block? PKCS#7 provides a solution to this problem. For example block size is 16 bytes. If block is align, then it'll append 16 bytes with each byte value 16. The receiving size after decryption will strip 16 bytes. If padding need 1 byte then padded byte will have 1 value. $\endgroup$ – VovCA Jun 26 '17 at 18:53
0
$\begingroup$

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.

$\endgroup$

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.