block encryption algorithm padding

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 
   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 . 
   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 
   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, 
   07070707070707, and 0808080808080808. All input is padded with 1 to 8 
   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 


Aleksey Sanin

XML Security Library

Received on Thursday, 11 April 2002 04:50:10 UTC