Plain Text--->"Plain Text" Encryption

I have only recently become interested in encryption, and know very little about the various technologies currently available. The following question is therefore likely naive:

Is there any strong form of encryption that allows you to specify both the input and output? For example, suppose I want to encrypt "This is an encrypted message" to send to a friend. Now, the standard form of PGP takes this text and transforms it into code that looks random, and it occurs to me that anyone who intercepted this message would be able to tell that it was encrypted. Could it be possible for someone to specify both the text to be encrypted and the encoded version so as to make the encrypted version appear to be unencrypted to the man in the middle, e.g. "This is an encrypted message"--->"This is an unencrypted message"? It seems that this would be a very useful tool.

Thanks for your thoughts!

 

Welcome to the forums rew89fr

What you are talking about is a form of a substitution cipher. This type of cipher is probably OK for entirely casual use, but it is extremely easy for someone to de-cipher it if he chooses to do so. Simply by analyzing the frequency of the occurence of the most popular words / letters / phrases in a given language, the most likely words to appear after a comma or in other locations, and various other techniques. Also, keep in mind that the message will not sound natural; in your example "This is an encrypted message" vs "this is an unencrypted message" is pretty cool, however in reality it would be probably something like "this is an encrypted message" vs "crow hat car cascade liberty". A cipher won't be able to give you an output in the form of a coherent sentence (well, maybe a coherent sentence, but definitely not an entire coherent conversation), so it will still be possible to tell that your message is encrypted, and then de-ciphering it is most likely a matter of days or even hours for a professional, assuming he has a large enough sample size of output data. You are better off using RSA.

EDIT:

As an example, I just took a piece of cipher text produced by applying a simple substitution cipher - one where each letter of the input text is substituted by another letter using a predefined matrix. So the input sentence This is an encrypted message might look something like this in encrypted form: xmor or fp wplgboywc jwrrfdw. I had about 200 words of output text available for analysis and had no knowledge of the source whatsoever, except that it was written in modern american English. It took me about 25 minutes to obtain the source text, using nothing other than my brain + a piece of software which analyzes the frequency of specific letters in a given piece of text (it tells you that the most common letter is X, the second most common is Y, etc.). Keep in mind that I am by no means an encryption expert or anything close to that - I've just been doing this for fun for the last few weeks.

EDIT 2:

Here is an overview of how this sort of cryptanalysis might be performed: http://en.wikipedia.org/wiki/Frequency_analysis

Of course, it would be somewhat different for the type of encryption suggested by you, however the key principals and variations upon them would still apply.

 

Just for trivia, there's the Caesar cipher which is a substitution cipher
http://en.wikipedia.org/wiki/Caesar_cipher

Great book on encryption :

http://puzzles.about.com/library/weekly/aa011012.htm

 

Thanks a lot for the responses! The world of cryptography is very interesting stuff indeed.

I'm aware of some the weakness of Caesar's ciphers, and most seem to arise as a result of the simplicity of the 1-1 relation between letters of the original and the encrypted text. I suppose one way of putting my original idea is like this:

1) You type the plain text message that you wish to encrypt
2) You type the "plain text" encrypted result that you would like
3) You use a program to generate a complex algorithm that establishes a complex relation between the characters of (1) and (2), one that would not merely be a 1-1 relation between characters. This would function as a sort of "key" to decrypt the file.

I know very little about this stuff, as I said, but I was thinking that perhaps it could work in a manner somewhat similar to PGP encryption through generating two keys that, taken together, could decrypt (2) into (1).

Not sure that this makes sense, but thanks for your responses.

 

Probably a more accurate definition of what OP is describing is a "code." Codes, technically, are different from encryption even though can be used for the same purpose. Unless the codebook is used just once, they are breakable through frequency analysis and other means, especially by people with lots of experience in the field. And if the code is recognizable (say you use the Declaration of Independence), it can become trivial to break.

Using an already existing book (like a novel) is technically considered a book cipher and it's security depends wholly on the enemy not being able to figure out which book you have used (security through obscurity). In today's modern computer era, that is not a good assumption to make. However, there are still some famous book ciphers that have not been decoded because the book has never been found. In the old days, before computers, using book ciphers was likely secure in most cases (if done properly). Nowadays with modern databases and the like, they cannot be depended upon for any real security.

Of course, one could make his own codebook; that is, take a string of text that one is sure doesn't exist anywhere else and then assign each word (or phrase) to a different word or phrase. This is essentially akin to inventing your own language and, for obvious reasons, can be tedious. The downfall is if you use the same book enough times, the enemy can perform frequency analysis on it to eventually decode it (much like linguists decode ancient languages). This is why other more modern methods of encryption are much more practical (and probably more secure).

A codebook is, in a sense (but not exactly), analogous to a one-time-pad. The difference is a one-time-pad does not hide the fact that the message is encrypted. A OTP also assumes the key is chosen completely at random and does not exist anywhere else for someone to find. Again, making a good codebook is very difficult and tedious. Not only that but you must find a way to get the key to the recipient in an outside secure channel. And then you have to depend on the recipient not having his codebook compromised or stolen. Essentially, it suffers from exactly the same practical difficulties as a one-time-pad. Even though a properly composed OTP cannot be broken, even in theory, they are rarely used because of the aforementioned reasons (i.e., the key has to be same length as the message, the key has to be sent securely beforehand, the key needs perfect random numbers, etc.). For instance, if you wanted to encrypt 300 pages of text to someone, you must first create a 300 page OTP and then send it to them securely before transmission. Likewise, on a computer, if you wanted to send 2 GB's of important business data, you must first give your contact a 2GB OTP composed of random numbers securely in an outside channel. And if you're going to do through all the trouble of secure key exchange, you may as well just transfer the message itself directly to them in person. This is why OTP's are only used today for very short messages -- mostly to spies in deep cover (see numbers stations on shortwave for an example of modern OTP transmissions).

Bottom line: you are much better off using modern crypto systems like Public-Key crypto or symmetric ciphers like AES. They are designed to mitigate the practical considerations of OTP's and codebooks.

 

Yeah in some ways they are similar (as in, they are both extremely easy to crack ). However, the Caesar cipher is a shift cipher, not a substitution cipher. Just a technicality though.

 

I believe a shift cipher is a form of substitution cipher?

 

This is easily doable, but what would be the point? You will have, for instance, "plain text 1" encrypted to "other plain text 1", but that doesn't mean that "plain text 2" will be encrypted to "another plain text 2", but to "lrtlkretjerlkhterjktherkt".

 

I just checked and you are right, sorry for the confusion. In the few encryption-related courses/books I have dealt with so far, substitution ciphers and shift ciphers were referred to and treated as two different things, that's why I said what I said.

 

If I well understand what you wish, you could combine encryption and steganography, and hide an encrypted text in an image, that you joint as an attachment to your email.

That circumvents very easily google robots (if you use gmail).

The decryption key must of course be known by your recipient (eg use his public RSA key) , as well as the software you use to encrypt the text and hide it in an image. Of course again, your recipient must know (or guess) there is something to find in the image. You can warn him eg by phone, or by post mail, or implicitly in the body of your email: Each first letter of each word could form the sentence "Look at the image".


http://www.myportablesoftware.com/freefilecamouflage.aspx (free)

https://www.briggsoft.com/cpix.htm (not free)

http://www.mobilefish.com/services/steganography/steganography.php

http://www.jjtc.com/Security/stegtools.htm


PS: Camouflage can sine recently be steganalysed. It's recommended to use an image that doesn't exist elsewhere in the universe. Eg, an home-made fractal image, built by your own pc with random parameter of "fractality". Such an image will surely be unique, so that no comparison with any original version could be made in order to steganalyse it.

 

I wouldn't recommend it for real-world usage, of course, but you can do something like this with simple XOR. For example, if I wanted the ciphertext to be the lyrics to, let's say, Zanzibar by Billy Joel, I'd XOR those lyrics with my plaintext. The resulting "ciphertext" of this is actually the key you'll use to decrypt the lyrics into the plaintext. The idea is that you can conspicuously share the lyrics in the clear, without raising too much suspicion. Of course, the obvious downside is that you can't share this key until after you've encrypted the plaintext into ciphertext, because the ciphertext is effectively the key. Not only that, but it doesn't solve the problem of how you'll get this random looking key (implying that cryptography is being used) from Alice to Bob, which seems to be one of your concerns.

Again, not that I'd recommend this at all, but to address this key management problem, you could set up a dummy communication channel, used as a red herring for the real one. Once you have the XOR of the plaintext and Billy Joel lyrics, you'll have a random-looking key with which you can then use to encrypt a dummy plaintext; you might even exchange keys in the clear, since it wouldn't matter if someone succeeded in breaking the ciphertext and deducing the key, as they'd assume the resulting plaintext is what you were actually trying to keep secret. The idea here is to find a way for Alice to get the key to Bob; this provides a means of doing so while fooling any eavesdroppers (in the ideal world of theory).


So, you'd do this (but don't actually do this):

• Alice does plaintext XOR Billy Joel lyrics = Key.
  
• Alice sends Billy Joel lyrics to Bob in the clear.
  
• Alice takes key and encrypts dummy plaintext to render ciphertext which she'll share with Bob.
  
• Alice sends the key to Bob in the clear, or in some manner that may make an eavesdropper think they're clueless and oblivious to their insecure key exchange. The eavesdropper either breaks the ciphertext, or swipes the key, and recovers the dummy plaintext, thinking he's captured Alice and Bob's juicy secret.
  
• Bob now has the key to XOR with the Billy Joel lyrics that an eavesdropper wouldn't have thought to actually be ciphertext, to which he'd pay no mind.

For a third time, I do not recommend using this; it's just an articial, fun-to-play-with example of how you might go about crafting readable ciphertext that corresponds to readable plaintext. This example doesn't imply forward secrecy, so if an adversary ever discovers the method, he'll be able to go back and decrypt old messages. There are far better ways to meet your needs with conventional cryptographic means, and if we better understood your threat model, we could likely suggest those.