# Encryption in which ciphertext is bigger than plaintext?

Is there an encryption which would produce a ciphertext longer than the plaintext? (please ignore block-chaining IV stuff, which would result in a data being generated from the plaintext).

The point in question is that a ciphertext generated $\{0,1\}^n$ seems inferior to one twice as long $\{0,1\}^{2n}$ in terms that more permutations are possible in the later one.

Yet if the plaintext was of a blocktype being $\{0,1\}^n$ it seems puzzling how the encryption would map bothways $$\{0,1\}^n \to \text{encrypt} \to \{0,1\}^{2n}$$ and $$\{0,1\}^{2n} \to \text{decrypt} \to \{0,1\}^n$$

I assume this question to touch on the necessary attriubutes of encryption that it is reversibility and deterministic behaviour both way.

• You seem to implicitly want a block cipher specifically, if this is indeed the case you should probably state it explicitly. Nov 11, 2014 at 13:49
• In cipher designs one usually tries to avoid a (more than constant) increase of the ciphertext. Apr 12, 2015 at 19:32
• The extra $n$ bits can't possibly contain any new information, so to me it seems unlikely that $2n$ bits output is superior: after all, you're giving the attacker more information instead of less. Apr 12, 2015 at 21:56
• What about ElGamal encryption scheme? In public key encryption, ciphertexts are often really large compared to plaintexts... Apr 13, 2015 at 13:01

There's no blockcipher providing this.

However if you want this kind of mapping there are two usage scenarios.

1. Strengthen the symmetric encryption. You could double the keysize by this construction. In "Applied Cryptography" Schneier suggested to combine two encryption algorithms so the ciphertext would be double the size of the plaintext.
1. Generate a pad $R$ at random, as long as your message
2. Calculate $P=R \oplus M$
3. Encrypt $P$ using one Cipher-Key-Pair
4. Encrypt $R$ using the other Cipher-Key-Pair
2. It might be possible to construct an online AEAD mode with intermediate tagging as one could basically authenticate each single block of the message. F.ex. using HMAC + CTR on 512-bit blocks one could encrypt the continous data stream using CTR and place the 512-bit HMAC tag after each 512-bit block. This might be nice, as you've got all the desireable properties of online encryption and intermediate tag verification that such modes provide. It might as well be possible to construct such a mode using a blockcipher (and maybe something like VMAC).

However for the first usage scenario there's no need as current blockciphers are secure enough and if you need larger blocksizes simply switch to something like Threefish.

Generating a ciphertext, c larger than the plaintext p (|c| > |p|) is a very useful configuration. It allows for one-to-many (p to c), with many to one (c to p), so the same message may randomly encrypt to different ciphertexts. Alternatively the choice of which of the possible ciphertexts that decrypts back to the same plaintext to use, may be used as subliminal channel. In reverse such a cipher can serve in a hashing protocol. See more in the Crypto Academy. More uses see US Patent #6,823,068