Adding dummy bytes to ciphertext

Question

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).

E.g.:

normal: kIolmspJgheydhNud

with dummies: kI9oklmdspJgfheydshNufd

Update:

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.