1
$\begingroup$

EDIT:

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.

ORIGINAL QUESTION:

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?

Improve this question
$\endgroup$
4
  • 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, 2020 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, 2020 at 20:00
  • 1
    $\begingroup$ Why do you want to encrypt URIs? And why is the length important? $\endgroup$
    – mentallurg
    Dec 18, 2020 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, 2020 at 22:07

1 Answer 1

Reset to default
1
$\begingroup$

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.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.