My original problem was that if I have to encrypt large amounts of data, AES would expand the data even more, but this is not the case. This question states that AES does not expand data at all.


I have a list of data URIs containing image data that I need to encrypt and save to a file. On average, the data URIs I need to save are thousands of characters in length and may get longer depending on how I configure my system. Currently, I am using the AES encryption algorithm.

What encryption algorithm would provide the shortest resulting ciphertext for strings of this length?

  • 1
    $\begingroup$ I'm not sure how to read this. Is the issue that AES encryption is currently adding large amounts of data? And is it not related to double encoding base64? $\endgroup$ – Modal Nest Dec 18 '20 at 19:32
  • 4
    $\begingroup$ Is there a limit to your data storage? AES-CTR can only increase 16 bytes due to the storage of the IV. CBC mode can increase an additional max 16 bytes due to the padding. $\endgroup$ – kelalaka Dec 18 '20 at 20:00
  • 1
    $\begingroup$ Why do you want to encrypt URIs? And why is the length important? $\endgroup$ – mentallurg Dec 18 '20 at 20:16
  • $\begingroup$ And what security requirements are there? Do you need to defend against someone altering the ciphertext? If so, you'll need 16 bytes for a tag + 12 bytes for an IV if using AES-GCM $\endgroup$ – SAI Peregrinus Dec 18 '20 at 22:07

The general method for shortest ciphertext goes

  1. Compress [but see cautionary note], perhaps using a general-purpose lossless compression such as (among many) Deflate or LZFSE; or some context-aware compression.
  2. Encrypt, using authenticated encryption such as (among many) AES(-256)-GCM-SIV.
  3. If the context requires, reformat to fit requirement, e.g. as Base64.

Decryption undoes each layer in reverse order. It is critical to use authenticated encryption or (much preferably, and) a robust de-compressor to avoid all kind of attacks, or crashes when deciphering an invalid ciphertext or decryption key.

For “a list of data URIs (that) are thousands of characters in length”, compression in step 1 will I guess reduce size by more than 1/4. It can outweigh the (small, constant) expansion in 2, and the ≈1/3 expansion of Base64 in step 3.

CAUTION: with compression, the size of ciphertext will reveal something about the size and compressibility of the plaintext, when normally encryption reveals only the size. This is known to be an issue in some contexts (including, digitized voice). Knowledge about the nature of the URI and what's confidential in them would be required to determine if that's an issue . If in doubt, don't compress.

Note: if size is paramount, and it is not an issue (or perhaps, if it is desired) that encryption of the same data with the same key always yields the same ciphertext, then it is safe to use a constant (e.g. all-zero and implicit) Initialization Vector in an authenticated encryption with the aforementioned AES-GCM-SIV.


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.