I think a more complete answer is in order here. Some modes (CTR, OFB, CFB, stream ciphers) never increase the size of the ciphertext. But in many cases, an IV is prepended to the ciphertext. The IV makes sure that different messages encrypt to different values. Almost every mode uses an IV, but in some cases both sides of the conversation know the IV, so you don't have to transmit it. IVs usually don't have to be random, but you must never use the same IV for a particular key.
Some older modes (CBC, ECB) require block alignment and normally use padding. Some forms of padding always increase the ciphertext size, and some forms only increase it to a multiple of one block (usually 16 bytes). Once again, there may be an IV. CBC mode (and ECB to a lesser extent) can replace the padding with something called "ciphertext stealing". With ciphertext stealing, the ciphertext is the same size as the plaintext. There are some issues in dealing with very short messages; I'm not sure how crypto++ works around them. The "best" modes provide authentication as well as encryption, so you can detect if someone has tampered with the message. These include EAX, OCB, GCM and CCM modes, among others. These modes always require an IV (but once again, you don't have to send the IV if the other side knows it). In addition, they put a "tag" value (you can choose the size, but it's usually 64 or 128 bits) at the end of the message. The tag is like a checksum that prevents an attacker from changing the message without being noticed. It's recommended that you use some form of authentication in almost every case, so you'll likely have to deal with some increase in message size. A few modes are designed for cases when message expansion is unacceptable, but they usually have fixed sizes, so you can't send just any message. They're mostly used for disk encryption. They require an IV, but the IV is usually just the address on the disk. These enclude LRW, XEX, XTS, CMC, and EME. I hope this helps. Cheers, Mike Hamburg On Thu, 2010-08-05 at 12:37 +0200, Elias Önal wrote: > Oh it shows the encryption of 12 byte plaintext. As I said it has to be > padded to the blocksize unless you use a streamcipher. That's all they > state. > > Andy Lewis wrote: > > > > Oh, well, got it, thanks. > > > http://www.codeproject.com/KB/security/BlockCiphers.aspx I was asking > > > this, because this page`s table "Plain Text versus Cipher Text Sizes" > > > confused me. Thanks again :) > > > > > > On 5 авг, 12:38, "Elias Önal" <[email protected]> wrote: > > > > > > >> >> The famous Huffman encryption usually produces smaller, but sometimes > >> >> bigger ciphertexts. But common algorithms like Triple-ROT13 should keep > >> >> the same size! :P > >> >> > >> >> Seriously, smaller isn't possible since you'd lose data (Usually you > >> >> can't compress entropy) - And bigger... no one would want to use that > >> >> since we have better alternatives which don't bloat the ciphertext. In > >> >> some cases you have to add padding till a multiple of the blocksize, but > >> >> since it is added to the plaintext they still remain the same size. > >> >> Asymmetric encryption often adds heaps of bloat but that's a different > >> >> story. > >> >> > >> >> > >> >> > >> >> Andy Lewis wrote: > >> >> > >> > >>> >>> Hello, > >>> >>> > >>> >>> I`d like to know, after encrypting PlainText in any of BlockCipher/in > >>> >>> any of mode, are CipherText and PlainText always same length? Or are > >>> >>> there some modes or ciphers, which produce CipherText, that is longer/ > >>> >>> shorter that PlainText? > >>> >>> > >>> > > > > > > > > > > -- You received this message because you are subscribed to the "Crypto++ Users" Google Group. To unsubscribe, send an email to [email protected]. More information about Crypto++ and this group is available at http://www.cryptopp.com.
