1
$\begingroup$

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.

$\endgroup$
2
$\begingroup$

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).

| improve this answer | |
$\endgroup$
1
$\begingroup$

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.

Basically, you are right. I just mention two things in addition to @poncho's answer:

(1) just as @poncho said that, block ciphers can run in different modes of operation. The message must be padded to a multiple of the cipher block size with ECB, CBC and PCBC modes.

(2) the number of padded blocks might be greater than the clear text length divides the block size. (For example, if PCKS#5 padding is used and the length of the clear text is exactly a multiple of the block size, an addition block then will be padded to the clear text.)

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 cipher block belongs to the next message?

I do not know exactly what is "the next message" in your question; messages can be sent via different ways at different layers (@poncho uses TLS as a good example).

But whatever a message is sent, there is a way to exchange the message length between the sender and the receiver. (Also, I assume that there is a way to exchange how the cipher text is encrypted.)

So, the receiver gets the entire cipher text (by its length), decrypts it, and removes the pad from the last block (if with ECB, CBC or PCBC mode and PKCS#5 padding).

The sender and the receiver must use the other way(s) to exchange the message length. A block ends with "0x01", "0x02 0x02", "0x03 0x03 0x03" does not guarantee this block is the last block with a PCKS#5 padding; it might be right in the middle of the clear text.

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?

@poncho mentions some ways. But whatever it is, do not depend on the padding alone to tell the end of the clear text.

| improve this answer | |
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.