Cryptography Reference
In-Depth Information
5.1.2 Padding in Block Algorithms
When implementing block algorithms, we generally hit an apparent side prob-
lem relatively late: what should we do with the last block? If we use the block
algorithm as a stream cipher (CFB and OFB modes), we work bytewise and
have no problem. Things look differently with blockwise encryption, e.g., in
ECB or CBC mode. In general, the length of the plaintext is not a multiple
of the block length so that we
have
to pad the last block when using either
of these modes. In doing so, we don't want to bargain it with cryptological
insecurities, of course. This task is less simple than it looks.
If the structure of the plaintext is such that its end is uniquely marked, e.g., by
ˆZ in text files under MS-DOS, then we can pad the last block with random
characters without running a risk. Unfortunately, the plaintext end is not always
marked. We will often have to encrypt a binary file, and the end of such a file
is determined only by the file length, for example, in UNIX. We also have to
assume that arbitrary characters and patterns can occur in the plaintext, i.e., we
cannot 'invent' an end identifier and simply append it.
Luckily, there is a very simple method recommended when a few bytes more
in the ciphertext won't matter: we pad the last plaintext block with random
bytes, and accommodate the number of filler bytes in the last byte:
Each_blo
|
|
|
ck_conta
ins_8_ch
aracters
XX3
Here we have used 'X' for padding; there are three additional bytes, together
with the 'count byte'. It is not important whether this last byte includes the
character
'3' or the
numerical value
3 (corresponding to ˆC) — the main thing
is that the statement is unambiguous, and that the receiver program can handle
it: it first decrypts all blocks, then looks at the last plaintext byte and truncates
the number of bytes from the end.
Unfortunately, this method is inelegant when the plaintext just about fills the
last block. In this case, we have to append a 'dummy block', the last byte of
which has a value of 8 when using 64-bit blocks.
And here is another drawback of this method: the ciphertext is longer than the
plaintext. This is undesirable, for example, when a subsection in the middle of
a file (or a database) is to be encrypted.
