Request for review: known plaintext mitigation by rotation and xor encoding

Question

When using structured data inside a plaintext (such as gzip headers, xml, etc.) they generate known plaintext which may be useful in cracking the ciphertext.

So I had these two ideas on how to make this known structure less useful to attackers while preserving the value to those with valid decryption keys:

First, if we prepend zero use a random xor, when decrypting we can remove the first value and xor the remainder of the text by that value it may make decrypting the ciphertext somewhat more difficult as the known plaintext is somewhat varied.

The second idea is to just rotate the start of the message by a random amount putting the known plaintext at a random place in the block (obviously less useful with streams). By prepending the coded plaintext with the offset with the original message can easily be recovered without introducing a known plaintext as the offset is a random number).

Further these two methods can be combined. Obviously these would add no cryptographic value to texts without known substrings and are completely useless without being paired with a real cipher.

The question is how useful would they be in mitigating a known plaintext attack?

Answer 1

For a secure cipher, the best attack is a brute-force key search: Iterate through all keys and try decryption until you find one where the result fits.

Having known plaintext in known blocks of the message helps, because then we need to only decrypt one block for most keys.

With your method, one might need to decrypt enough blocks to be able to undo the transformation ... this makes it a bit harder, but only by a small constant factor (depending on the number of blocks needed, at most the whole message will need to be decrypted).

As usually the key sizes for ciphers considered secure (like anything $\geq 128$ bit for a symmetric cipher) are anyways out of reach for brute-forcing even with known plaintext, your method doesn't help in practice.

With a non-secure cipher, or one with a too small key size, this could help to increase the costs (or time) of cracking for an attacker significantly, for example from using 5 million \$ hardware to 50 million \$ (in the same time), or from 5 hours to 50 hours (using the same hardware), assuming that in average 10 blocks instead of one needs to be tried. But then, you are better of using a secure algorithm with a sufficiently big key size than trying arbitrary modifications of the plaintext combined with an insecure cipher.