Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

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

share|improve this question
    
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. –  Paŭlo Ebermann May 16 '13 at 18:37
    
yeah my purpose is to encrypt and decrypt both. –  Mitaksh Gupta May 17 '13 at 7:18
    
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. –  rath May 18 '13 at 1:52

2 Answers 2

up vote 5 down vote accepted

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.

share|improve this answer
    
Okay @Maeher thanks –  Mitaksh Gupta May 16 '13 at 11:38
1  
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. –  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.

share|improve this answer
    
What exactly is the end you do achieve that way? –  Maeher May 16 '13 at 13:02
    
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. –  Henrick Hellström May 16 '13 at 13:11
    
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. –  Maeher May 16 '13 at 18:42
    
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. –  Henrick Hellström May 16 '13 at 19:27
    
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. –  Maeher May 16 '13 at 20:05

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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