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?
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.
openssl encby 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. ... $\endgroup$encat all. $\endgroup$