4
$\begingroup$

Using an encryption algorithm like AES, is it possible to generate a fixed length cipher text no matter how long the plain text becomes?

$\endgroup$
3
  • $\begingroup$ Welcome to Cryptography Stack Exchange. Do you want to be able to decrypt this again? Then it is impossible in general to have a shorter ciphertext than the plaintext. Otherwise this is not called encryption but a "hash" ... it is possible to build a hash function from AES, but not trivial to do so in a secure way. $\endgroup$ May 16, 2013 at 18:37
  • $\begingroup$ yeah my purpose is to encrypt and decrypt both. $\endgroup$ May 17, 2013 at 7:18
  • $\begingroup$ Well you could but the solution is a rather ugly one: Pad your plaintext with random data so that all plaintexts are the same size. $\endgroup$
    – rath
    May 18, 2013 at 1:52

2 Answers 2

8
$\begingroup$

That is quite impossible. Lets assume that such an encryption scheme would exist and assume that it always outputs ciphertexts of length $n$ bits.

Then, because the scheme is assumed to encrypt plaintexts of arbitrary length, it in particular encrypts all plaintexts of length $n+1$ to ciphertexts of length $n$. However, there exist twice as many plaintexts of length $n+1$ than ciphertexts of length $n$. So by the pigeonhole principle there exists at least one ciphertexts that encrypts more than one plaintext. This directly implies, that decryption would be impossible in such a scheme.

$\endgroup$
1
  • 1
    $\begingroup$ Simplistically, such a construct would allow for infinitely efficient compression. Want to distribute a 10TB file? Easy! "Encrypt" it with this scheme and it's now only $n$ bits in size. $\endgroup$ May 16, 2013 at 23:56
1
$\begingroup$

If you agree to define "fixed length cipher text" in such way that the import criterion isn't that the cipher text has a constant bounded length, but that the length of the cipher text is independent of the length of the plain text, the trick is simply to ensure that the cipher text is at least not shorter than the total amount of plain text.

In practice, this end is typically achieved by encrypting the medium instead of encrypting the contents. If you want to protect the confidentiality of files you store on a hard drive - encrypt the entire hard drive, instead of the individual files; if you want to protect the confidentiality of data you send over a transport - send a continuous stream of cipher text over the transport.

$\endgroup$
5
  • $\begingroup$ What exactly is the end you do achieve that way? $\endgroup$
    – Maeher
    May 16, 2013 at 13:02
  • $\begingroup$ You hide the amount of actual plain text content. For instance, compare it to the WWII continuous broadcasts of seemingly random words. If you were listening in and didn't know which keyword to listen for, you couldn't tell when a message began or ended. $\endgroup$ May 16, 2013 at 13:11
  • $\begingroup$ I'm just not sure that this answers the question. Of course you can always assume some upper bound (space on harddrive, duration of your "random" stream) and pad your plaintexts to this length. (This is essentially what you are doing) but the question explicitly stated that an upper bound was not wanted. $\endgroup$
    – Maeher
    May 16, 2013 at 18:42
  • $\begingroup$ Correct, the whole idea behind en.wikipedia.org/wiki/Numbers_station encryption is that the broadcast goes on forever, so that you don't get an indication when the actual traffic occurs. Obviously you are also theoretically correct about file encryption and drive encryption, but in practice there is equally obviously always a practical upper bound on how large a file might get, before you have to change medium. $\endgroup$ May 16, 2013 at 19:27
  • $\begingroup$ Yes you are of course correct. So in conclusion, while the functionality as stated is theoretically impossible, it can be emulated in most practical circumstances, if the benefit outweighs the potentially large overhead. $\endgroup$
    – Maeher
    May 16, 2013 at 20:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.