Re: What padding do we use?

Hi Donald,

just for the records, under [1], I found the NISTs "Recommendation for 
Block Cipher Modes of Operation" [2]. There they mention on page 17:

--------------------------------

Appendix A: Padding

[...]

If the data string to be encrypted does not initially satisfy this 
property, then the formatting of the plaintext must entail an increase in 
the number of bits. A common way to achieve the necessary increase is to 
append some extra bits, called padding, to the trailing end of the data 
string as the last step in the formatting of the plaintext. An example of a 
padding method is to append a single '1' bit to the data string and then to 
pad the resulting string by as few '0' bits, possibly none, as are 
necessary to complete the final block (segment). Other methods may be used; 
in general, the formatting of the plaintext is outside the scope of this 
recommendation.

For the above padding method, the padding bits can be removed 
unambiguously, provided the receiver can determine that the message is 
indeed padded. One way to ensure that the receiver does not mistakenly 
remove bits from an unpadded message is to require the sender to pad every 
message, including messages in which the final block (segment) is already 
complete. For such messages, an entire block (segment) of padding is 
appended. Alternatively, such messages can be sent without padding if, for 
every message, the existence of padding can be reliably inferred, e.g., 
from a message length indicator.

--------------------------------

For me, this reads that there will be no fixed padding mechanism for AES 
and we can choose our own (like you already did).

Christian

[1] http://csrc.nist.gov/publications/nistpubs/index.html
[2] http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf

--On Freitag, 2. November 2001 09:09 -0500 "Donald E. Eastlake 3rd" 
<dee3@torque.pothole.com> wrote:

> Hi,
>
> True, this padding is not normative. But it is the only padding given
> for "byte data". The other method suggested is for "bit data", where
> the number of bits is not necessarily a multiple of 8, although it
> would also work for bytes... Since all our stuff and most modern
> cryptography is byte oriented and no one has objected, I plan to
> document the style of padding I describe below.
>
> It is more or less the same padding as in PKCS#5 which I think is
> quite old and was in PEM (see RFC 1423). The only difference is that
> most of these other descriptions unnecessarily require all the padding
> bytes to have the same value as the final padding count byte.
>
> Thanks,
> Donald
>
> From:  "Takeshi Imamura" <IMAMU@jp.ibm.com>
> To:  "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>
> Cc:  Christian Geuer-Pollmann <geuer-pollmann@nue.et-inf.uni-siegen.de>,
>             XML Encryption WG <xml-encryption@w3.org>
> Message-ID:  <OF47AAE325.EF27ACBB-ON49256AF8.001EFDF9@LocalDomain>
> Date:  Fri, 2 Nov 2001 14:59:06 +0900
>
>> Donald,
>>
>>> FIPS-81, DES Modes of operations, in Appendix C on CBC with byte data
>>> specified that it is to be padded by placing in the last byte of the
>>> last cblock of input data the number of padding bytes (including this
>>> count byte) and filling remaining pad bytes with anything.  I.E., if
>>> there were 5 bytes of data in the last block, these would be left
>>> justified, the bottom byte set to 0x03, and the two bytes between the
>>> data and this "3" byte set to any pad characters. If the data exactly
>>> fills the last block, an additional block is added with 0x08 in the
>>> bottom byte and its remaining 7 bytes filled with any pad character.
>>>
>>> Since this seems to be sort of part of the definition of CBC, would
>>> there be any objection to explicitly specifying this for XML ENC?
>>
>> I studied FIPS-81 and found that the padding method you had pointed is
>> given just as an example.  Moreover another padding method is given,
>> which may lead to a misunderstanding.  So I believe that we should
>> specify the padding method explicitly or use standard padding methods
>> like the PKCS#5 padding.
>>
>> Thanks,
>> Takeshi IMAMURA

Received on Tuesday, 18 December 2001 02:02:52 UTC