# Do I need to prepare plain text before encryption?

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.

-
Also, rather than inventing your own protocol, you should consider implementing the TextSecure protocol or the OTR protocol, both of which have been designed for this purpose. OTR is available (either by default, or as a plugin) for many instant messaging systems. –  Stephen Touset Jan 13 '14 at 19:36
Yes, I'm just thinking about OTR as in TextSecure ) –  Abzac Jan 13 '14 at 23:40

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.

-
I like your answer but would like to add that it's not always interesting how much two instances exchange messages. Sometimes it's also very interesting for eavesdropper that they know there is message exchange (wether its encrypted or not) –  Stefan Jan 14 '14 at 9:20
@Stefan Thx! I absolutely agree, but I considered this a bit too far away from what was asked. My intention was to highlight that even if the two communicating users would be anonymous in some way a heavy conversation (message exchange) might already be suspicious. If this happens, then the adversary could start identifying the two chat partners. –  DrLecter Jan 14 '14 at 10:14
yes I think so, +1 for your answer –  Stefan Jan 14 '14 at 10:54

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

-
Beyond confusion and diffusion, some information about the plaintext remains: The length of the message and (depending on the cipher) if encrypting the same message results in the same ciphertext. If this is an issue, fixing block size and using CCA-secure ciphers or certain mode of operations will help –  tylo Jan 13 '14 at 10:55
@tylo : $\:$ CCA-security is independent of the issues you mention in your first sentence. $\hspace{1.19 in}$ –  Ricky Demer Jan 13 '14 at 20:10

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.

-

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.

-
Compressing data does not increase entropy. The advice you may be thinking of is that if you are going to compress, you must do so before encrypting because compression only works on data with low entropy (e.g., common plaintexts) – purely random data cannot be compressed. Encryption combines the entropy of a randomly-generated key with the plaintext, making the resulting ciphertext incompressible. –  Stephen Touset Jan 13 '14 at 0:56
Compression does not increase the total entropy of the plain text, but it does increase the average entropy per bit, by, well, compressing it. Theoretically, it might increase security in some sense, but only in so far that the compression algorithm effectively hides the length of the original plain text. –  Henrick Hellström Jan 13 '14 at 2:57
Chances are, that question you're looking for is: "Is compressing data prior to encryption necessary to reduce plaintext redundancy?" –  e-sushi Jan 13 '14 at 5:14

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.

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