Re: What padding do we use?

OK, so there's no reason to change the current editor's draft which
specifies a method I took, as I say below, from FIPS 81.

Donald

From:  Christian Geuer-Pollmann <geuer-pollmann@nue.et-inf.uni-siegen.de>
Date:  Tue, 18 Dec 2001 08:05:41 +0100
To:  "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>
Cc:  XML Encryption WG <xml-encryption@w3.org>
Message-ID:  <3640394136.1008662741@pinkpanther>
In-Reply-To:  <200111021409.JAA0000086428@torque.pothole.com>

>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 10:11:15 UTC