Re: block encryption algorithm padding

Hi,

I think it is too late to change things.

While using fixed value padding bytes before the counter byte makes for
better validity checking, it also makes some forms of attack easier due
to grossly skewing the probability of various types of values for the
last block. In particular, one out of B messages, on average, has a
fixed value final block. From that point of view, you want to specify
that all the padding bytes are to be random except for the bottom n
of the last byte.

Thanks,
Donald

On Thu, 11 Apr 2002, Aleksey Sanin wrote:

> Date: Thu, 11 Apr 2002 01:49:20 -0700
> From: Aleksey Sanin <aleksey@aleksey.com>
> To: xml-encryption@w3.org
> Subject: block encryption algorithm padding
> Resent-Date: Thu, 11 Apr 2002 04:50:22 -0400 (EDT)
> Resent-From: xml-encryption@w3.org
>
> In the section 5.2 "Block encryption algorithms" of XML Encryption [1]
> the padding is described as follows:
>
>    The padding algorithm is to calculate the smallest non-zero number of
>    octets, say N, that must be suffixed to the plain text to bring it up
> to a
>    multiple of the block size. We will assume the block size is B octets
> so N is
>    in the range of 1 to B. Pad by suffixing the plain text with N-1
> arbitrary pad
>    bytes and a final byte whose value is N. On decryption, just take the
> last
>    byte and, after sanity checking it, strip that many bytes from the
> end of
>    the decrypted cipher text.
>
>    For example, assume an 8 byte block size and plain text of 0x616263 .
> The
>    padded plain text would then be 0x616263????????05 where the "??" bytes
>    can be any value. Similarly, plain text of 0x2122232425262728 would
> be padded
>    to 0x2122232425262728??????????????08.
>
> However, this is different from DES CBC padding described in RFC1423
> [2]:
>
>    The input to the DES CBC encryption process shall be padded to a
> multiple of
>    8 octets, in the following manner. Let n be the length in octets of
> the input. Pad
>    the input by appending 8-(n mod 8) octets to the end of the message,
> each having
>    the value 8-(n mod 8), the number of octets being added. In
> hexadecimal, the
>    possible paddings are: 01, 0202, 030303, 04040404, 0505050505,
> 060606060606,
>    07070707070707, and 0808080808080808. All input is padded with 1 to 8
> octets
>    to produce a multiple of 8 octets in length. The padding can be
> removed unambiguously
>    after decryption.
>
> The difference is that RFC1423 defines the value of all bytes added to
> the cipher text.
> This allows to do slightly better validation in most cases (especially,
> in the last 080808...08 case :) ).
>
> I run into this problem when I've tried to decrypt Merlin's examples. It
> turns out that
> the package I am using (OpenSSL) does check *all* padded bytes as it is
> described in RFC.
> I thought that this is only OpenSSL specific but quick check showed that
> BSAFE library
> does the same.
>
> I suggest to change the XML Enc specification because the current
> padding causes
> interoperability problems and it would be better to follow existing
> standards.
>
>
> [1]  http://www.w3.org/TR/xmlenc-core/#sec-Alg-Block
> [2]  http://www.ietf.org/rfc/rfc1423.txt
>
>
> Aleksey Sanin
>
> XML Security Library
> http://www.aleksey.com/xmlsec
>
>
>
>

Received on Thursday, 11 April 2002 09:28:42 UTC