Do I need to prepare plain text before encryption?

Question

When I want to encrypt chat messages (in ASCII) before sending, whether it brings some bit of security if I add some extra bytes to the message or shuffle it in some way? I can even try to make data to look like uniform distribution.

Because chat messages consist only of letters and even words, but don't contain binary data and other bytes except that from ASCII, so it gives some information about unencrypted data to eavesdropper.

But I'm afraid that some manipulations over the text could bring much more information to the attacker than doing nothing.

Answer 1

If you are using a modern, secure cipher, there is no reason whatsoever to perform such manipulations of the plaintext.

I'm not sure how to elaborate much more on the topic than that. The entire purpose of a cipher is to perform the exact types of confusion and diffusion you describe. Only, the approach that it will use has been designed, peer-reviewed, and cryptanalyzed by professional cryptographers. Your hypothetical algorithm has not.

At best case, it will do nothing to improve the security of your ciphertexts. At worst case, you can introduce bugs that unintentionally cause plaintexts to be unrecoverable from the ciphertext, or ones that accidentally reveal information about the plaintext (for instance, via a leak of timing information).

Answer 2

As Stephen already said in his answer, if you use a modern secure encryption scheme, then you do not have to worry about the confidentiality of the messages.

However, as you say your application is a chat the following part of your question:

if I add some extra bytes to the message

seems to be a valid (although maybe "paranoid") issue.

I interpret this as follows: Besides being save with respect to confidentiality when using a secure modern encryption scheme, i.e., an attacker will not learn the content of your message, the attacker, without any other measures, can still learn the length of a chat message (up to some minor padding if you use some mode of operation that requires padding).

Padding to disguise message size

If you do not want to learn the attacker this information then you could pad all messages to some constant fixed size before encryption. Then, if the choice of this value is appropriate, an attacker could not distinguish for instance whether $A$ and $B$ have a "nonsense" communication like this:

• $A$: hi!
• $B$: waz up?
• $A$: ;)
• $B$: LOL
• $\ldots$

or $A$ and $B$ are discussing something really intensive, which might be a highly intellectual political debate and suspicious. Clearly, $A$ and $B$ could only send single word message to make it look like such a conversation, but the number of sent messages may reveal that this is not the case.

Dummy messages

Another thing that comes up to my mind is to introduce dummy messages sent between $A$ and $B$ to "obfuscate" the real conversation and to not reveal too much information about the real conversation.

I do not want to make any statement about which measure makes sense or how to choose this fixed message size and even if you do so you might still leak enough information as a "nonsense" discussion might only involve very short messages and the said highly intellectual discussion on a political topic might involve very long messages. Thus, choosing the fixed message size to even hide such an information might make the chat application too bandwidth and cost intensive (from a computational point of view). Furthermore, dummy traffic clearly also introduces additional costs.

Answer 3

I think, what You are talking about is hiding your message in some random messages and then send it. Then yeah you can do that. This technique is called Steganography https://en.wikipedia.org/wiki/Steganography . You can always use Cryptography along with Stegnography to make your interaction session more secure but it'll increase overhead of network.

Answer 4

Somewhere on this site (or Security.SE) I read there used to be a time when security experts recommended compressing the data before encrypting, to increase entropy. I can't find the reference anymore (if someone does please put a link to it) but the conclusion was that we've moved past this.

Your thinking makes sense if your cipher of choice doesn't handle that on its own. If a cipher doesn't make the output look random, it's not a good cipher, which means you won't come across it it a library, and that you shouldn't use it for anything other than fooling around with.

To answer your question: Obfuscating before encrypting doesn't increase security, but it doesn't lower it either. It will increase the overall complexity of your system though, and for that reason it should be avoided. The concept of "separation of duties" applies.

Answer 5

When I want to encrypt chat messages (in ascii) before sending, whether it brings some bit of security if I add some extra bytes to the message or shuffle it in some way? I can even try to make data to look like uniform distribution.

I recommend to encode your chat messages with base64 before encrypting and sending them through the chat channel. This method has advantages and disadvantages though.

Advantages:

1. It obfuscates the plaintext and adds more complexity and an extra layer of security, because when brute-forcing your ciphertext an attacker would be forced to guess base64-encoded strings instead of direct phrases or words from a dictionary as usual.
2. You can also use this very efficiently to obfuscate all your internet passwords and make them tougher and longer quite easily.

Example:

1. Plain Chat Msg = Hi there!
2. Base64 Chat Msg = SGkgdGhlcmUh (Layer 1, Encode of 1.)
3. Encryption of 2. (Layer 2)
4. Ciphertext

Disadvantages:

1. Base64-encoded text would be bigger in size than the original plaintext due to the conversion method. In a chat conversation it would probably be no problem since most chat messages are short anyway.
2. Base64-encoding is not encryption but a data conversion method of any type of data to printable ASCII characters, thus an attacker could also encode words, passwords or entire phrases from a dictionary with base64 when running a brute-force attack on ciphertexts. This way the attacker could bypass the base64 security layer.