# How can I create pre-determined encrypted results?

1. I want my encryption results to be the lyrics to Star Spangled Banner.
2. The original text I'm encrypting would be, for instance, the menu to a local pizza place.
3. I know what I want my passphrase to be.

How can I determine how to do this if I want to require a particular passphrase for its decryption? Obviously, I don't want something simple like ROT. I want to use cascade ciphers to accomplish this, something like AES, Serpent or Twofish.

• So, you're given the plaintext, the ciphertext and the key and want to find an appropriate mapping that is actually at least somewhat secure? That will be extremely hard. If you had only a requirement for either the plain- or ciphertext this would be trivial. – SEJPM Jun 11 '16 at 20:46
• Can you store additional information next to the ciphertext? – Maarten Bodewes Jun 11 '16 at 20:52
• @Maarten Bodewes I'm not sure what you're asking. But, if that's what it takes then I guess the answer would be yes. – Darwin Jun 11 '16 at 21:49
• Yes? You can edit comments up to 5 minutes :) – Maarten Bodewes Jun 11 '16 at 21:49
• It would indeed work similar to this, but what you have is different. You have $P,C,K$ and look for some function $f:\mathcal P \times \mathcal K \rightarrow \mathcal C$ such that $f(P,K)=C$ and such that $f(\cdot,\cdot)$ holds up well in the security games. Finding such functions is hard, as would be finding a suitable key (which is what these games are all about), but finding $P$ or $C$ given the other three parts is trivial. In your example you wouldn't be looking for some "X" but for operation like "+" that would satisfy something like "2+3=7". – SEJPM Jun 11 '16 at 22:02

1. There exists a decryption method that given only the encryption results and the passphrase, outputs the original text.
2. The encryption/decryption method is not highly specific to a particular input (a particular menu to a local pizza place) or desired output (the lyrics to Star Spangled Banner).
3. In "I want my encryption results to be the lyrics to Star Spangled Banner", what's meant is that the full encryption results is exactly equal to prescribed data rendering as the lyrics to Star Spangled Banner.

Proof: suppose what's asked is possible with these three constraints. Using the same passphrase, encipher a variant of the menu to that local pizza place, in the same hypothetical method that gives the prescribed data rendering as the lyrics to Star Spangled Banner. The deciphering program of 1 has no way to decide which of the two menus it should output.

If we remove any of these constraints, what's asked is easy.

Argument for 1: Consider a decryption program that uses the help of an online server to retrieve the original text stored there, using the desired output as key.

Argument for 2: Consider a program that outputs the lyrics to Star Spangled Banner whenever the original text is a specific menu to a local pizza place, and otherwise performs as a normal encryption program; add a few easy technicalities.

Argument for 3: Consider an encryption program that accepts as additional input a text file with the desired output; and outputs a PDF or JPEG file that shows the text of that desired output, but contains in a comment field (not rendered by a PDF or JPEG viewer) the result of the encryption of the original text under the passphrase, per some standard encryption method. The decryption program will first extract the comment field, then use the standard decryption method. We can perfect the illusion by replacing the passphrase with the SHA-256 hash of the passphrase followed by the PDF or JPEG output file less its comment field.

There are countless ways to work around requirement 3; some even use a standard method modified in a detail. For example, with AES-CBC, it is easy to specially chose an IV such that a given 16-byte plaintext block enciphers to a given 16-byte ciphertext block under a given key, with no change to the decryption program. That's apparently how the idea illustrated in Angecryption started.

An entropy argument gives us a limit to how far we can go while meeting requirements 1 and 2: regardless of how clever we are in working around 3, the ciphertext is bound to be at least as big as we can losslessly compress the combination of the input and desired output, minus the entropy in the passphrase.

Since you tagged one time pads, I'll mention that this is easy to do with a OTP. It's just a matter of choosing the key letter that maps the plaintext letter to the desired ciphertext letter.

As a simple example, here's a small one I did with pencil and paper using NSA's DIANA reciprocal OTP system. I skipped spaces to make it easier.

Ciphertext: OHSAYCANYOUSEE

Key: ZSPSXUKYILMTRD

Here's the table I used

To decrypt it, look at the conversion table, find the key ketter on the left of the table, then find the ciphertext letter in its corresponding row. The letter below it is the plaintext. Repeat for each and you have the entire plaintext message.

If you wanted to use a specific passphrase, you could encrypt the key using that passphrase as a pad, provided it's the same length. Decryption would then be

1. Decrypt the key using the passphrase as a pad

2. Decrypt message using the key

Note that the security guarantees of the OTP system require random keys, so if your passphrase is not random, they will not apply, nor would I trust this as anything but a fun toy that keeps most casual attackers at bay.