I have an c/c++ program used for encrypting data for communicating between two ends. Encryption is done using OpenSSL (0.9.8d-fips, Sep 2006). Think it'll be worthy to mention that I'm not much familiar with using OpenSSL.

The program works fine for larger packets. But the size overhead is very high when encrypting smaller size packets. I've done a test to demonstrate the issue.

| Input Chars | Encrypted Chars | Input/Encrypted % |
|           1 |              74 | 1.351351351       |
|           2 |              74 | 2.702702703       |
|           3 |              74 | 4.054054054       |
|           4 |              74 | 5.405405405       |
|           5 |              74 | 6.756756757       |
|           6 |              74 | 8.108108108       |
|           7 |              74 | 9.459459459       |
|           8 |              74 | 10.81081081       |
|           9 |              74 | 12.16216216       |
|          10 |              74 | 13.51351351       |
|          11 |              74 | 14.86486486       |
|          12 |              90 | 13.33333333       |
|          13 |              90 | 14.44444444       |
|          14 |              90 | 15.55555556       |
|          15 |              90 | 16.66666667       |

The test was done while incrementing the number of input characters from 1 to 10000 . Following graphs illustrate the results more clearly.

Graph 1: Encrypted size vs Input Size enter image description here

Graph 2: Ratio vs Input size enter image description here

From the second graph, it's clearly visible that the encryption overhead is very high for smaller inputs (size less than 300bytes).

Is this normal/acceptable? If it is so are there any alternatives (with less overhead). Because the application uses smaller packets heavily (Bundling them together is not an option).

As mentioned above, OpenSSL 0.9.8d is used, which is a bit older version (1.0.1g, April 2014, is available now). Will the problem be fixed if I upgrade it?


- Hello, this is TastyChef hotline, how may I help you ?

- Hello. I am cooking. I need to know how long I should put my food in the oven.

- It depends on what you are cooking, Sir.

- Oh, it is a Miele-Samsung 1200+ oven. Serial number is X67NQ-56D3034.

- Not the oven, Sir.

- Do you think replacing the oven with a 1500+ would change the cooking time ?

- ...

What matters is the protocol you are using, which boils down to the involved algorithms and encoding formats. You have to understand what you are trying to do. Right now, you appear to "use OpenSSL" as a kind of cryptographic seasoning, in the wild hope that sprinkling encryption about will make security somehow happen. It does not happen that way.

They say that software engineering begins with architecture, then analysis, then specification, then (and only then) implementation. If you skip the first three steps, then the fourth will lead to doom.

  • yeah I agree. I'm just analyzing the code written by someone else, which is currently being used in practical applications. I have to admit that I'm not familiar with the subject, but i'm intended to be. In the mean time i got this problem, thought someone will guide. – Anubis May 29 '14 at 11:38

SSL data are put into records and each record has an overhead of about 25..40 bytes (see https://www.imperialviolet.org/2010/06/25/overclocking-ssl.html). The smaller your data chunks are, the more noticeable this overhead is. Apart from SSL there is also more overhead per packet from the other layers, e.g. TCP, IP, ethernet... .

The overhead is not specific to OpenSSL, but is common for all SSL implementations.


This overhead might also turn out to be useful (I would not go as far as say it's by design, tho): for example, if you had a 1-to-1 mapping, an adversary would be able to determine what kind of traffic you're sending by looking at the packet length without having to decrypt it.

This, in turn, could leak some bits of information and depending on the circumstances. See for example this paper:

Packet headers identify the destination and source addresses and the size of the payload data, along with other information. The address and packet size information is usually sufficient to identify which page a target user downloads

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.