# How to disguise ciphertext

If I want to have a secret conversation, then I can encrypt it (with OTR etc). However, since big brother watches all communication, sending encrypted data will likely raise flags. Does anyone know of an algorithm to take ciphertext and convert it into harmless looking plaintext?

For example, I could take each group of three hex digits, like "3E8" and convert it to an english word, like "peanut". So "2E8A983F7E100B6CE1" gets converted to "fork would said free dish quark". But I think that would still be pretty easy for big brother to detect.

Anyone know of a good algorithm for this? Anyone seen any research on it?

EDIT: Imagine two people want to communicate securely over a channel, but the channel only allows plaintext. If the channel doesn't understand the message, it will block it. So they have to find a way send a strong encrypted message that looks like plaintext.

• The technical name for these sorts of techniques is steganography Feb 15 '16 at 17:19
• Unfortunately, it's very hard to get steganography right. I would anyway suggest encrypting securely and then applying whatever (heuristic) steganography you want. Feb 15 '16 at 19:01
• @YehudaLindell thanks, yes i didn't mean instead of encryption. I am looking for a method to make the ciphertext look inconspicuous and innocuous. Feb 15 '16 at 22:41
• That is: you want to well hide the information (basically bits) of the given ciphertext in a covertext that is formulated in a natural language. I suppose it's understandable that the efficiency of such processing is naturally fairly low in general, i.e. the ratio of the length of the covertext to the length of the given ciphertext is fairly high. In case that inefficiency could be acceptable for your applications, you could try out two schemes of mine: s13.zetaboards.com/Crypto/topic/6939954/1 and s13.zetaboards.com/Crypto/topic/7338098/1 Feb 16 '16 at 12:56
• @JohnHenckel: Don't the schemes mentioned in my previous comment well satisfy your requirements (especially as explained in your last edit), excepting the IMHO practically unavoidable disadvantage of fairly low stego bit rate? (I should certainly highly appreciate your evaluation of the schemes from the viewpoint of your concrete applications.) Feb 16 '16 at 19:29

What you are looking for is called steganography. It is a different field from cryptography so you might want to check in some other fora also.

I don't know much about steganography but i remember this paricular algorithm. You can take you ciphertext, and an image say a greyscale bitmap. Then you can replace the least significant bits of every pixel with a bit from your ciphertext. Since ciphertext are "random" bitstrings one would no be able to recognise a ciphertext from random noise on the pixel values.

You can then reconstruct the ciphertext by reading the last bit from each pixel.

• Steganography is actually a subset of cryptography. It's as old as the Caeser cipher, but employed wax underneath tablets to conceal the temporary messages. May 3 '17 at 0:42

Maybe you can use format-transforming encryption, which works by taking values from a message space $M$ and encrypting them into a ciphertext $C$ whose elements have some specified format.

I know that this kind of encryption was already used to the same things you are asking for.

Furthermore, there is a (easy to use) public available implementation maintained by Kevin P. Dyer. In this implementation, the set $C$ is defined by a regular expression, so, for instance, you could take $C$ as a set of elements having the format [0-9]+(.[0-9]+)? to generate ciphertexts with the csv format described in the Eckert's answer.

Translate each cipher data byte to an integer string. Append "." + some random digits as a string. Prepend, to the integer portion, some random digits as a string. So 'A' (for example) = 65. Encrypted for Dummies by adding 1 = 66. Treated as a string, now "66.3867", then "1066.3867". Then, each superencrypted or just mutated string representation of your cipher bytes now an enormous, ordered collection of numeric data, perfect for a csv or other text file. What could be more innocent and boring than some Big Data? I have a question in return about degree of randomness produced from shuffling ordered data. Hope this helps.

But I think that would still be pretty easy for big brother to detect

Perhaps not. You might be able to use a form of steganography that I'll call spam steganography. Total rubbish text (like your cipher text) is transmitted all the time these days interleaved with spam emails. You've probably had these yourself. Random text is added (more of less effectively) to spam to foil AI based spam filters. If you created these yourself, your cipher text could be the random text. It would be difficult to differentiate your special spam from that of authentic spam, especially if you consider that spam bots vary in their effectiveness. After all some of these emails even get through the Gmail filters and Goggle are clever chaps. Your (assumed) low level bandwidth would not significantly skew the probability weightings identifying the majority of the authentic spam, so your emails should just blend in.

All you'd have to add is some convincing text promoting a length extension product or innovative get rich quick scheme...

Youn need linguistic steganography. In linguistic steganography you hide bits inside text.

This kind of steganography has two drawbacks:

• The capacity is very low: 0.5/1 bits per word.

• If you want the resulting text to make sense you need to do the process by hand. There are algorithms that allow you to generate statistically correct text, but then it does not make sense and a person can easily detect it.

• In the real world nothing can be perfect/ideal and there is trade-off everywhere. If one wants the cover to be a very naturally appearing text, which has the advantage of not liable of drawing attention of the adversary in comparison to covers of other media in general, and there is sufficiently high security, then what you described is what I have at best achieved with my scheme after long time of efforts, see mok-kong-shen.de. However, as I argue there, in favorable situations one could e.g. employ a codebook to highly compress the stegabit sequence to render the scheme to be practical. May 4 '17 at 15:41