views:

1807

answers:

8

I would like to add AES encryption to a software product, but am concerned by increasing the size of the data. I am guessing that the data does increase in size, and then I'll have to add a compression algorithm to compensate.

+12  A: 

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.

moonshadow
+3  A: 

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.

freespace
A: 

If compression is necessary do it before you encrypt.

Mike
+9  A: 

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.

Dario Solera
A: 

No. The only change will be a small amount of padding to align the data to the size of a block

However, if you are compressing the content note that you should do this before encrypting. Encrypted data should generally be indistinguishable from random data, which means that it will not compress.

Brian
A: 

@freespace and others: One of the things I remember from my cryptography classes is that you should not compress your data before encryption, because some repeatable chunks of compressed stream (like section headers for example) may make it easier to crack your encryption.

Kasprzol
It's a possibility. Then again, there may be even longer cribs in your plaintext - for example binary data files are often half-full of zeros, and MPEG data contains just as many magic numbers as PKZIP data. It's not possible to generalise.
Steve Jessop
If your algorithm is that vulnerable to a known plaintext attack, you're probably screwed regardless. There are just as predictable cribs in many structured format commonly transferred. Most modern systems are designed to operate in modes that prevent such attacks being feasible.
Brian
Correct! the compressed data will often have fewer repeating or guessable segments than actual plaintext. Suppose you are encrypting a Java code file. Will anyone guess that // appears often? Also: Zip vendors compress before encrypting.
Cheeso
+1  A: 

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.

Steve Jessop
A: 

Hello, I'm implementing the AES 128 bits encryption in my application. First I hash my data with a sha256 algorithm and then I sign them using the AES 128 algorithm. So, my data now are 256 bits bigger than the original one. Do you think that's the right way to do?