# How can AES be considered secure when encrypting large files?

Why is AES considered to be secure when encrypting large files since the algorithm is a block cipher?

I mean, if the file is larger than the block size, the file will be broken down to fit the blocks. Then the same key is used to encrypt each block of the file. And as I know it, using the same key to encrypt multiple messages/blocks is not a good idea. Is not that how AES works?

Or do I have misunderstood something? :-)

• – user991 Sep 11 '14 at 18:17
• You describe ECB mode, which is indeed not secure. But actually used modes make it different for each block. – CodesInChaos Sep 11 '14 at 18:34
• Using a weak mode like ECB is not secure. That's a weakness in the mode and not in AES. But even with a secure mode, the larger the data, the more likely it is to have two identical blocks be encrypted. I think a good rule of thumb is that with a block size of $b$ bits, you shouldn't encrypt more than $b*2^{b/4}$ bits with the same key. In the case of AES that works out to no more than 64GB encrypted using a single key. – kasperd Sep 13 '14 at 17:27
• @kasperd: your rule of thumb is way overly conservative; CBC/CFB modes are good for $b\cdot2^{(b+1-r)/2}$ bits where residual odds of duplication of one block are $2^{-r}$. With AES and $r=40$ (residual odds of one in a million millions, entirely negligible compared to oblivion by asteroid on any given day) that's 3 petabit (nearly 400 terabyte). CTR/OFB modes are good for even more. – fgrieu May 2 '15 at 6:28
• @fgrieu I would say $r = 40$ isn't a very high security to aim for. Aim a little bit higher ant take $r = b/2$, and you will end up with the same result as I did. CTR can be used for more data before you run into a collision, but only if you track additional information to avoid counter reuse or switch the key whenever counter reuse would be possible. However if you guarantee that a collision will not happen, then information is leaked to the adversary, because the adversary can then take advantage of that knowledge. – kasperd May 2 '15 at 13:50

Encrypting big amounts of data is no problem for block cipher - if you remember a few important things.

You can't encrypt plaintext which is bigger than the block size. You need to do some addition work. Most cipher operation modes first divide the plaintext into blocks of the size of the cipher. Now you can do different things: How about just encrypting each individual block, plain and simple? That's called ECB mode.

What happens if you encrypt the same block twice at different positions in a file? You get the same cipher text. If an attacker sees this, he can tell: "At this two positions there's the same plaintext." - The attacker could also swap two blocks without it being detectable (at least if the decrypted plaintext still makes sense).

Then there's the CBC mode. You first xor an Initialization vector (IV) with the first plaintext block. The IV should be randomly generated and has to be as big as the block size. Now you encrypt the resulting block. This is your first ciphertext block. As next step, you xor this first block with the next plaintext block. Block cipher algorithms create mostly random looking blocks after encryption and as a result, the xor of this and a plaintext block creates a new block to encrypt. This removes the two mentioned problems of the ECB mode: Swapping two blocks results in at least one garbage plaintext block. Also the same plaintext block will (in nearly every case) encrypt into different ciphertexts.

There are many more encryptions modes like the Counter mode (CTR). Also you should normally use some kind of Authenticated encryption. The use of a good cipher mode is not enough to avert most attacks. Things like a Message authentication code (MAC) are also important. A commonly used, but pretty complex way of combining both ways is the Galois/Counter Mode.