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

  • $\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$ – Paŭlo Ebermann May 16 '13 at 18:37
  • $\begingroup$ yeah my purpose is to encrypt and decrypt both. $\endgroup$ – Mitaksh Gupta May 17 '13 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 '13 at 1:52

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.

| improve this answer | |
  • 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$ – Stephen Touset May 16 '13 at 23:56

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.

| improve this answer | |
  • $\begingroup$ What exactly is the end you do achieve that way? $\endgroup$ – Maeher May 16 '13 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$ – Henrick Hellström May 16 '13 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 '13 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$ – Henrick Hellström May 16 '13 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 '13 at 20:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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