I was wondering if interleaving the resulting crypted data with dummy bytes placed at random positions but known in advance by the peers could improve security (no matter the algorithm and strength used, this is just baby step theory here) or do the contrary (and why).


normal: kIolmspJgheydhNud

with dummies: kI9oklmdspJgfheydshNufd


after Thomas answer, I realized that my question was not clear where the dummy bytes would go.

My mistake.

So I am interested in adding dummies in the ciphertext. After all encryption of the real text occurred. The net result is to make the ciphertext longer and not logical anymore.

  • 1
    $\begingroup$ I would think placing the dummy values into the plaintext before encryption would be more effective, as it would diffuse throughout the block (at least in the case of a block cipher). Or perhaps a combination of the 2 $\endgroup$ – Richie Frame Oct 14 '15 at 21:51
  • $\begingroup$ @RichieFrame: I came to the same conclusion, until proven wrong (maybe) :) $\endgroup$ – Kroma Oct 15 '15 at 13:44
  • $\begingroup$ That isn't really ciphertext you are changing, you are changing the base 64 encoding of the ciphertext. $\endgroup$ – Maarten Bodewes Oct 15 '15 at 21:28
  • $\begingroup$ @MaartenBodewes: Yes, you are right. Do you think it changes the relevance of the selected answer? (and thanks for the edits btw) $\endgroup$ – Kroma Oct 18 '15 at 15:58
  • $\begingroup$ No, not really. I don't think it is not very useful either way. Changing the encoding just muddles the algorithm for for no specific reason, changing the ciphertext itself makes more sense. $\endgroup$ – Maarten Bodewes Oct 18 '15 at 16:06

This is essentially a very simple encryption layer on top of an existing algorithm, so reasons to not use something like that can be found elsewhere on the site. For example: Why are we not using multiple ciphers per message?

As to the specific scheme, we assume that the adversary knows your algorithm. The only thing secret is the key. So you can keep the location of the dummy bytes secret by making it depend on a (second) key, but the adversary is assumed to know they exist. They can reveal the positions with a simple chosen ciphertext attack: modify the $n$th byte, send for decryption, check if the plaintext changed. Those positions that do not affect the plaintext are dummy bytes.

Now, a more complex algorithm could somehow make the locations differ for each message, e.g. by deriving them from an IV using a key. However, even then they might have little effect on attacking the lower cipher. For example, assuming AES for the lower layer the adversary can verify a key guess $k$ by trying decryption using the first 16 bytes of plaintext, if that does not work, then skipping the $i$th for $i \in [0,15]$, etc. Unless the amount of dummy bytes is close to or larger than the amount of actual ciphertext, this adds only a small factor to the work needed.

| improve this answer | |
  • $\begingroup$ I just made a simulation. With Aes (128bits), I couldn't find the original plaintext by rearranging the letters. That is because of the input is sliced and the longer the message the harder it seems is to find the plaintext (exponentially harder). Confused $\endgroup$ – Kroma Oct 15 '15 at 13:45
  • $\begingroup$ @Kroma, if you look at the total number of possible rearrangements, it is high (though it increases polynomially rather than exponentially with message length, if you have a constant number of dummies). However, you can find solutions incrementally, e.g. one block at a time if you used AES-CBC. You can only look at which bytes to skip so that the next block makes sense, then move on. $\endgroup$ – otus Oct 16 '15 at 5:12
  • $\begingroup$ Ok. It becomes very difficult that way. You earn the final answer otus. $\endgroup$ – Kroma Oct 16 '15 at 16:20

If you're using a real encryption scheme then no it cannot weaken or strengthen the system because the encryption scheme's security is supposed to be independent the actual data being encrypted. The plaintext could be random bytes or all zeroes for all it cares, it will be just as secure.

All this modification achieves is lower your encryption scheme's capacity (number of plaintext bytes you can transfer in a given number of ciphertext bytes) and performance (number of plaintext bytes encrypted by second) as well as complicating the algorithm even further for no reason.

This is, of course, if the adversary only has access to the bytes over the wire. Your implementation of this modification may well leak sensitive information through a side channel (don't know how, but it's possible since you need to add code to implement this, and this code may have bugs and security vulnerabilities, as with any code.

Basically, it doesn't really do anything useful and has only cons, so don't do it.

| improve this answer | |
  • $\begingroup$ Ah! i am sorry I was not talking about the plaintext but the cyphertext. Let me update my question. $\endgroup$ – Kroma Oct 14 '15 at 8:52

Modern ciphers - when used with a proper mode for encryption - return a ciphertext that is - except for the size - indistinguishable from random bytes. So if you would introduce random values at random locations then you would not be able to decrypt the ciphertext. You could try to brute force the randoms away, but in that case you need to perform as many operations as the attacker. There are of course methods of doing this using a pseudo random generator but I presume that's out of scope. Basically without a full protocol description it is hard to tell.

In general your method would take a lot of time and a lot of overhead without introducing a lot of security. So in general you would be much better off using e.g. AES-256 instead of AES-128. But note that you may be trying to solve a problem that doesn't exist. Modern block ciphers such as AES are thought to be pretty secure. The same goes for modes of operation (when used properly). If anything is attacked it is usually not the block cipher.

| improve this answer | |

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.