Re: What padding do we use?

Hi,

From:  Christian Geuer-Pollmann <geuer-pollmann@nue.et-inf.uni-siegen.de>
Date:  Tue, 30 Oct 2001 20:21:49 +0100
To:  "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>
Cc:  XML Encryption WG <xml-encryption@w3.org>, Joseph Reagle <reagle@w3.org>
Message-id:  <3745930018.1004473309@pinkpanther>

>Hi Donald,
>
>--On Dienstag, 30. Oktober 2001 12:16 -0500 "Donald E. Eastlake 3rd" 
><dee3@torque.pothole.com> wrote:
>
>>> in [1], I did not find any information about what padding mechanism we
>>> use?  PKCS7/PKCS5?
>>
>> This depends on which algorithm you are talking about.
>>
>> For TripleDES, and AES, I suppose we should continue to go with
>> whatever S/MIME does / will do.
>
>That exactly was my question. Especially, how do we pad "payload" inside an 
>xenc:EncryptedData/xenc:CipherData element which is encrypted using 
>#tripledes-cbc and #aesXXX-cbc.

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?

>In chapter 5.1 Algorithm IDs, we make a distinction between "Block 
>encryption" and "Symmetric KeyWrap" algorithms. It's obvious (but not 
>stated explicitly if I'm right) that "Block encryption" refers to 
>encrypting xenc:EncryptedData and that "Symmetric KeyWrap" is used for 
>encrypting xenc:EncryptedKey.

There have been objections in the past overly restrictive wording. I
believe the current document states that Block Encryption algorithms
are "designed for" encrypting data and Symmetric KeyWrap are "designed
for" encrypting symmetric keys. I currently see no reason to add text
restricting them to such use.

>When we use EncryptedData to encrypt arbirary data which is in most cases 
>not a multiple of 64 bit, we have to define a padding mechanism for block 
>encryption.
>
>But even if we're talking about symmetric key wrap, there is no assurance 
>that the wrapped key inside an EncryptedKey is a multiple of 64 bit. If I 
>only used algorithms explicitly mentioned in the spec, it's not a problem. 
>But we define a syntax for using stream ciphers which do not necessarily 
>have a 64x key length, and user-defined block algorithms could be scalable, 
>too. So we need padding for KeyWrap, too.

TripleDES KeyWrap uses CBC so would be the same as abouve as would AES
KeyWrap if NSA defines it to use CBC. If NSA chooses some other
chaining or specifies a different padding, we should follow them.

>> For key transport, the padding is explicitly given for RSA 1.5. It's
>> complicated for RSA-OAEP but is given in the referenced RFC.
>
>Yes, the padding for key transport is defined.
>
>> For Symmetric Key Wrap, the normal case of a TripleDES wrap of a
>> TripleDES key or any key that is a multile of 64 bit (i.e., all AES
>> keys) needs no padding and one would assume that NSA will define
>> appropriate padding for AES wrapping of AES keys. Since a TripleDES
>> key is the same size (192 bits) as an allowed AES key, it will
>> presumably be possible to AES wrap it like a 192 bit AES key. However,
>> I suppose, that we should either restrict TripleDES wrapping to keys
>> that are a multiple of 64 bits or say how to pad other lengths. For
>> AES, I'd prefer not to change any text until we see the NSA
>> recommendation.
>
>See above.
>
>Best regards,
>Christian

Thanks,
Donald

Received on Wednesday, 31 October 2001 12:55:58 UTC