Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Does AES (128 or 256) encryption expand the data? If so, by how much?

People also ask

What is the difference between AES 128 and AES 256?

AES-128 is faster and more efficient and less likely to have a full attack developed against it (due to a stronger key schedule). AES-256 is more resistant to brute force attacks and is only weak against related key attacks (which should never happen anyway).

What is the expanded key size of AES 256?

A 256-bit key (32 bytes) is expanded to 240 bytes.

Is AES 128 or 256 more secure?

The three AES varieties are also distinguished by the number of rounds of encryption. AES 128 uses 10 rounds, AES 192 uses 12 rounds, and AES 256 uses 14 rounds. The more rounds, the more complex the encryption, making AES 256 the most secure AES implementation.

What is the difference between 128 and 256-bit encryption?

A 128-bit level of encryption has 2128 possible key combinations (340,282,366,920,938,463,463,374,607,431,768,211,456 – 39 digits long) and 256-bit AES encryption has 2256 possible key combinations (a number 78 digits long).


AES does not expand data. Moreover, the output will not generally be compressible; if you intend to compress your data, do so before encrypting it.

However, note that AES encryption is usually combined with padding, which will increase the size of the data (though only by a few bytes).


AES does not expand the data, except for a few bytes of padding at the end of the last block.

The resulting data are not compressible, at any rate, because they are basically random - no dictionary-based algorithm is able to effectively compress them. A best practice is to compress the data first, then encrypt them.


It is common to compress data before encrypting. Compressing it afterwards doesn't work, because AES encrypted data appears random (as for any good cipher, apart from any headers and whatnot).

However, compression can introduce side-channel attacks in some contexts, so you must analyse your own use. Such attacks have recently been reported against encrypted VOIP: the gist is that different syllables create characteristic variations in bitrate when compressed with VBR, because some sounds compress better than others. Some (or all) syllables may therefore be recoverable with sufficient analysis, since the data is transmitted at the rate it is generated. The fix is to either to use (less efficient) CBR compression, or to use a buffer to transmit at constant rate regardless of the data rate coming out of the encoder (increasing latency).

AES turns 16 byte input blocks into 16 byte output blocks. The only expansion is to round the data up to a whole number of blocks.


I am fairly sure AES encryption adds nothing to the data being encrypted, since that would give away information about the state variables, and that is a Bad Thing when it comes to cryptography.

If you want to mix compression and encryption, do them in that order. The reason is encrypted data (ideally) looks like totally random data, and compression algorithms will end up making the data bigger, due to its inability to actually compress any of it and overhead of book keeping that comes with any compressed file format.