0
$\begingroup$

Let's say I have (as an example only) 1 MB of plaintexts. I want to encrypt it using symmetric encryption algorithm (e.g. AES) and store the plaintext and ciphertext in a memory space. Does a ciphertext take the same size as its corresponding plaintext? I mean, in my example, does this mean I need 2 MB to store plaintexts and ciphertexts? Can you provide references?

$\endgroup$
  • 1
    $\begingroup$ For standard techniques, the encryption storage overhead is constant and usually way less than 100 bytes. $\endgroup$ – SEJPM Nov 18 '16 at 14:04
  • $\begingroup$ @SEJPM Thanks. But, can you clarify. What do you mean by storage overhead is constant? Do you mean that the ciphertext costs storage equal to the plaintext storage? $\endgroup$ – user6875880 Nov 18 '16 at 16:17
2
$\begingroup$

Does a ciphertext take the same size as its corresponding plaintext?

It really depends. From a cryptographic standpoint you can do this, however there are a few pieces of info you really want to be sent along with your message. The overhead thus is constant, i.e. independent of the actual message length. If you go with crazy double-encryption variants or weird custom schemes though you may of course get a linear increase here.

The (interesting) values you may or may not provide with your ciphertext may include the following ones:

  • Authentication tag. You really want this one or otherwise you won't be able to verify the integrity of the message you're receiving. Its size usually ranges from 16 (GCM) to 64 bytes (HMAC-SHA-512).
  • Nonce / IV. You really want this as otherwise you have no chance of getting actually secure encryption and same messages encrypt to same ciphertexts. The overhead introduced here is around 0 (fully context dependent) to 16 bytes (CBC-IV) usually.
  • Scheme identifier. You may want to add an identifier for your scheme used in case your application supports or will support multiple encryption algorithms. The overhead here may reach from a single byte up to a few bytes (OID).
  • Structuring. More often than not you want your various data types to be structured as standards-compliant as possible and thus you may want to use something like ASN.1 which also adds a few bytes as overhead (for encoding lengths and types).
  • Data encryption keys. Sometimes people also use different keys for the each packet of data to limit the amount of data per key. A data encryption key is then an encrypted key which can decrypt the message content. This overhead of course also depends on all the other listed overheads.
  • Other auxilliary data. This may include application-defined content such protocol version and other routing information.

So all in all you tend to be looking at a constant overhead with 32 bytes minimum in size and a few hundred bytes in size maximum.

$\endgroup$
2
$\begingroup$

Your question is too broad in this form.

There are plenty of different symmetric encryption algorithms. Most of them produce 1MB output for 1MB input. Most of them are block-based, so they round up the input size to a multiple of a block-size. If you choose a specific algorithm, you can check the exact details yourselves. You should not choose encryption algorithm based on the overhead though, but rather choose one based on security and performance.

Also, it is usual to compress data before encrypting it, because it is impossible to do so after encryption.

$\endgroup$
  • 1
    $\begingroup$ …because it is impossible to do so after encryption. – I’m aware that this is nit-picking, but compression is possible after encryption. Yet, I certainly agree that doing so will produce rather negligible compression results due to the random nature of encrypted data. $\endgroup$ – e-sushi Nov 18 '16 at 18:49
  • $\begingroup$ :facepalm: You are completely right about that. How does this compliment feel? :P $\endgroup$ – wigy Nov 22 '16 at 12:12

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.