Tell where messages begin and end in a series of ciphertext blocks? With block ciphers, I understand that the plaintext is first broken down into the right-sized blocks, padded, and then encrypted into the same number of cipher blocks.

Once these blocks are sent over to the receiver, does this mean that (after decryption) the receiver would have to parse each block looking for the padding in order to be able to tell that the current message has ended and that the next cipherblock belongs to the next message?

Is there a way to mark somewhere how many cipher blocks a given message is, so the receiver would not have to do this parsing on every single cipher block that it receives?

Thanks.
With block ciphers, I understand that the plaintext is first broken down into the right-sized blocks, padded, and then encrypted into the same number of cipher blocks.


Actually, it's a bit more complex than that.  There are some block cipher modes (for example, CTR, CFB) that don't require any padding.  On the other hand, even if the encryption mode doesn't require padding, we usually do want to provide some integrity protection to the ciphertext (so that if someone modifies the ciphertext, we can determine that); we usually do this by dividing the message up, and generating a Message Authenticated Code for each segment (or using a Authenticating Encryption Cipher, which effectively does the same thing); this would also cause us to treat the messsage as something other than a continuous stream (even if, to the application, it might be).


  does this mean that (after decryption) the receiver would have to parse each block looking for the padding


Actually, the receiver wouldn't be able to determine if a particular block is the last block in a message.  That's because we generally allow all blocks but the last to take on any value (so that we can encrypt 128 bits per block with AES); this means that the decrypted plaintext block might take on any value; there's no way that the decryptor would be able to distinguish 'padded last block' vs 'just more data'.

Instead, we generally rely on a noncryptographic higher-level protocol to divide distinct messages.  The use of a higher level protocol means that an attacker can deduce the size of the messages (and the timing); however the cryptographical piece ensures that that's the only thing that an attacker can learn).

One example which might be illuminating is TLS; that breaks up the stream of plaintext into 'records', and individually encrypts each record.  Before each record, it includes (in plaintext) the length of the encrypted record.  Hence, the decryptor knows up front where the last encrypted block is.

This isn't the only way to mark where the start of the next record is; another way is the IPsec approach.  With IPsec, each ciphertext is placed in its own packet; hence where the ciphertext ends is easy (it's at the end of the packet).