I am currently working on my JavaScript project where I am also trying to encrypt attachments with AES-256. Right now I am testing it and I am getting this results.

For photo file which has size about 2mb after encryption I get 3.7MB... Which is cca double that original size.

I want ask you guys if it is OK because what I have heard AES cypher is not like RSA and it is not adding any or not to much additional size. Am I right?

If this help I am using open source AES-JS...

  • $\begingroup$ Yeah, that sounds weird. If it's open source, do you have a Github link? $\endgroup$ – Nat Jun 20 '17 at 8:45
  • 2
    $\begingroup$ Perhaps it hex-encodes the ciphertext. $\endgroup$ – CodesInChaos Jun 20 '17 at 8:52
  • $\begingroup$ As requested here is the Github link gist.github.com/chrisveness/b28bd30b2b0c03806b0c $\endgroup$ – daniel Jun 20 '17 at 9:26

No, AES is a block cipher that encrypts precisely one block of plaintext and results in a block of ciphertext.

The amount of overhead depends on the mode, but it is usually limited to one block for the IV and one block of padding at most. When an authenticated mode is used such as GCM then you may have one block of authentication tag as well.

Adding to that is any kind of meta data to keep the structure intact, salt for password based key derivation etc. You would not expect an overhead more than 100 bytes or so, where AES and it mode only takes 32 bytes max (as padding and an authentication tag usually aren't used together).

So what can cause this overhead? The most likely culprit is encoding of the bytes. Many libraries output base64 instead of bytes if "raw" output is not specified. Base 64 adds an overhead of about 33% (4 characters for each 3 byte, plus one or two padding characters). This would be in line with your result.

Note that "hex" encoding is not the same as "raw" encoding of the bytes. Hexadecimals is a direct representation of each byte value in text using two hexadecimal digits 0-9 and A-F per byte. If you save these two characters they become a byte each, doubling the size in bytes of the ciphertext. Or, if you are unlucky and save in UTF-16 (the braindead default of .NET) you get a quadrupling in size.

It is of course also possible to wrongly implement the AES, even given a high level API. For instance you could read the input data in blocks and then encrypt each block separately. This could in principle more than triple the size (IV and padding or IV and authentication tag). Instead it is wise to look for a streaming option or update function in the library.

| improve this answer | |
  • 11
    $\begingroup$ And yes, I've seen hex encoding being base 64 encoded and then saved as UTF-16. Ouch. $\endgroup$ – Maarten Bodewes Jun 20 '17 at 9:07
  • $\begingroup$ Maarten THX for your help! It is possible maybe to write (or where can I find) more about these two types "hex" and "raw" which is better for which aplication etc. again many thx $\endgroup$ – daniel Jun 20 '17 at 13:47
  • $\begingroup$ What I understand is that raw is for plaintext and hex is good for data? Or my thinking is wrong? $\endgroup$ – daniel Jun 20 '17 at 13:57
  • $\begingroup$ @daniel In modern crypto, the plaintext is actually not text but binary (bytes, in other words). Hex and base64 are textual representation of the bytes, e.g. for use in textual strings in JSON, XML, text fields etc.. In hex you can easily make out the bit & byte values while base64 is more efficient. $\endgroup$ – Maarten Bodewes Jun 20 '17 at 14:06
  • 1
    $\begingroup$ For files I would not use any encoding. Files consist of bytes. It's most efficient to leave it that way. Just encrypt and save the plaintext as bytes. If you need to specify an encoding try "raw" or "none" or similar. Some libraries will call have "hex" encoding when they really mean just the bytes. In that case use another library. $\endgroup$ – Maarten Bodewes Jun 20 '17 at 16:02

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.