Random padding / Confusion about "IV" padding vs "Last block" padding?

[danielmarschall]

You told me a few days that it would be preferrable if the padding would be randomized instead of static.
I have researched on the topic and indeed, randomized padding for the last block is highly recommended.

I have tried to find out how it currently works, but I believe that the documentation does not fit the code

Documentation:

    /// <param name="IFiller">
    ///   optional parameter defining the value with which the last block will
    ///   be filled up if the size of the data to be processed cannot be divided
    ///   by block size without reminder. Means: if the last block is not
    ///   completely filled with data.
    /// </param>

vs. Implementation (This is the only place where I could see that IFillter is used):

FillChar(FInitializationVector^, FBufferSize, IFiller)

The I is probably also a hint that the filler is the padding of the IV and not the padding of the last block?

So a few questions arrised:

1. If indeed IFiller is only for the IV, are we safe then? (Because the blocks are dependant on each previous block, so the padding of the last block will be rather unguessable.) Edit: To answer my own question: We might be more safe if we'd use the standard PKCS#7 to fill the last block.
2. I am not 100% sure what this does: FillChar(FInitializationVector^, FBufferSize, IFiller) Why is the IV filled with the length of the buffer size, and not with the length of the block? I thought the IV only needs the size of a single block, and not the size of the buffer?

In case we want random padding, I guess we could use TBlockFillMode for this purpose; something like:

  if FillMode = fmByte then
    FillChar(FInitializationVector^, FBufferSize, IFiller)
  else if FillMode = fmRandomByte then
    FillChar(FInitializationVector^, FBufferSize, ....Random stuff....);

---

Edit: Actually, if we use TBlockFillMode as it is intended to be (to fill the last block instead of the IV), then it might be good to have it actually be defined as (fmByte, fmRandom, fmPkcs5, fmPkcs7) where fmByte is defined as constant byte.

[danielmarschall]

Just a small notice what I found out how padding is currently implemented:

Mode	Padding implemented
cmECBx	Throws Exception (#56?)
cmCBCx	Calls EncodeCFB8 for padding + sets csPadded
cmCTSx	Calls EncodeCFS8 for padding + sets csPadded
cmCTS3	Calls EncodeCFSx for padding + sets csPadded
cmCFB8	No code for padding? How does it work???
cmCFBx	No code for padding? How does it work???
cmOFB8	No code for padding? How does it work???
cmOFBx	No code for padding? How does it work???
cmCFS8	No code for padding? How does it work???
cmCFSx	No code for padding? How does it work???
cmGCM	No code for padding? How does it work???

[danielmarschall]

Spent a few hours to understand how the padding in DEC works, but I am very stuck at the moment.

Let block size be 16 bytes.

• Plaintext 20 bytes.
• EncodeBytes() gives 20 bytes. Why does this work? Isn't there 12 bytes of data lost???
• DecodeBytes() gives 20 bytes, which are correct.

[MHumm]

Ok, about the padding: that might require more work. About IFiller: I think meanwhile that the XMLDOC comment is wrong, as this is really only used to prefill the initialization vector so in case somebody provides an IV with less data than required something defined is contained in the last few bytes. I'll change the documentation. See my newest commit in development branch.

[MHumm]

I also corrected the documentation, but that's not yet available as new PDF version.