# Do all stream ciphers (and AES-128-CTR in particular) produce equal output size as the input size?

I'm particulary interested on knowing if the output of the AES-128-CTR ciphertext is always going to have the same size as the input plaintext, or it could be padded somehow. It seems so from my tests using openssl.

My input (plaintext) is a bytestream (not a bitstream). Is there any difference bytestream / bitstream regarding output ciphertext size?

Does this output size == input size applies to all stream ciphers?

• If you are using commandline openssl enc by default it does Password Based Encryption WITH SALT and must add the salt to the output file; this is true for both stream and block ciphers/modes. Yes the actual ciphertext for stream including CTR is the same size as the input. "Normal" stream modes and ciphers are standardly defined down to bits, but openssl both commandline and library API only handles bytes (and specifically 8-bit bytes). Note that non-password encryption with a stream cipher requires an IV that is sent with, and often concatenated to, the ciphertext. ... Feb 18 '15 at 14:54
• ... Similarly authenticated stream modes like CCM and GCM have actual ciphertext the same size, but also create a tag that is often concatenated to the ciphertext. But AE modes aren't supported in commandline enc at all. Feb 18 '15 at 14:55
• @dave_thompson_085 your two comments should really be incorporated into an answer. Feb 18 '15 at 15:25

First I will start with AES-CTR. This is a mode which turns a block cipher into a stream cipher. Since AES has a 128-bit block size, the output of the primitive is in blocks of 16 bytes. If you have a 3 byte message, 3 bytes is kept from that block to encrypt the plaintext via XOR. A broken implementation may not truncate. CTR requires a Nonce, which is generally included with the ciphertext and is usually 96-bits (12 bytes) in length, making that final message length 15 bytes. Salsa and ChaCha also require a Nonce.

Other variants of CTR mode include the authenticated GCM, which would then add an authentication tag to the ciphertext, at an implementation defined length.

Nonces and authentication tags are generally a multiple of 8 bits, so if you are encrypting a byte string, you should end up with one. Other data required to decrypt the message may be concatenated to the ciphertext, such as KDF iteration counts and salts, cipher or KDF identifiers, and message sequence identifiers. If an authenticated mode is used, and these are processed as additionally authenticated data, they are required to decrypt as per specification, even though without them you may still be able to recover the plaintext. Additionally authenticated data may included something that is not part of the ciphertext, such as the email or IP address of the sender.

Some stream ciphers do not explicitly require a Nonce, but they may be processed as part of the key, and still need to be included with the ciphertext.

Various implementations may obfuscate or operate on the plaintext prior to encryption. Plaintext compression can substantially change the ciphertext size, or may have no effect at all, depending on the content. Obfuscation may pad the entire message to 140 bytes, so it can then be plaintext encoded to fill an entire SMS message, hiding the true message size.

• Right. At the end of the day, no (rather than all) stream cipher produce output of size equal to the input size, and is secure, and allows key reuse for several messages (which is in the definition of a cipher), if one accounts for the fraction of the output devoted to IV.
– fgrieu
Feb 19 '15 at 7:00