W3C home > Mailing lists > Public > xml-encryption@w3.org > April 2002

Re: block encryption algorithm padding

From: Tom Gindin <tgindin@us.ibm.com>
Date: Wed, 17 Apr 2002 11:07:02 -0400
To: "Joseph Ashwood" <ashwood@msn.com>
Cc: <xml-encryption@w3.org>
Message-ID: <OF37719241.B1BBF533-ON85256B9D.006FFF2B@pok.ibm.com>

      Joe:

      Perhaps I should have been more explicit.  IMHO PKCS#5 (or X.923)
causes less additional harm when the item encrypted is XML or ASN.1 BER/DER
than when the data encrypted is arbitrary binary data, because you already
have known text near the front of those message formats.  While I don't see
any reason to prefer the two deterministic paddings to ISO 10126, XML
encryption is one of the places where not permitting PKCS#5 has the least
point.
      Just speaking as a sometime implementor, I would use PKCS#5 or X.923
if they were what my encryption library supported, but if I had a choice of
all three modes I'd use ISO 10126.  I don't see the point in banning the
use of those modes, especially since I know of commercially available
libraries whose only padding mode for Triple-DES is PKCS#5 (yes, I know how
to code ISO 10126 as a separate layer of code, but it's unrealistic to
expect most implementors to do that).  The only thing in favor of leaving
them out of the specification is that because PKCS#5 and X.923 are legal
(if peculiar) cases of ISO 10126 it is not strictly necessary to put them
into the encryption method - you'll just get failed decryptions when the
encryptor didn't use the padding which your library supports.  The worst
problem caused by this would be if the decryptor's library supported PKCS#5
and X.923 separately, but not ISO 10126, and the decryptor picked the wrong
padding mode because he couldn't tell which one was used by the encryptor
(who had used one of the two weaker modes).
      In short, while only inertia keeps PKCS#5 and X.923 in use, the
particular type of inertia which does so is the existence of well-tested
and trusted code libraries which use one of these methods in preference to
ISO 10126, and we can't just wish that away.

            Tom Gindin

P.S. -      The opinions above are mine and not necessarily those of my
employer.


"Joseph Ashwood" <ashwood@msn.com>@w3.org on 04/16/2002 12:19:11 AM

Sent by:    xml-encryption-request@w3.org


To:    <xml-encryption@w3.org>
cc:
Subject:    Re: block encryption algorithm padding



----- Original Message -----
From: "Tom Gindin" <tgindin@us.ibm.com>

>       Why is PKCS#5 padding in CBC mode more dangerous for XML encryption
> than for ordinary binary encryption?

I never said it was. PKCS#5 padding is in most circumstances a poor choice.
There are many compelling reasons to use different padding modes, but I
can't think of any good reason for PKCS padding, except for it's status as
the de facto standard. Since XML is clearly a very different standard from
the others, using a de facto standard without significant reason does not
seem like a concept in keeping with the idea of XML.

If we want to consider other padding/ending modes, there are modes where
that avoid padding completely (i.e. ciphertext-stealing). I don't think
that
opening up this discussion again would be a good idea. Having just one
generally suitable padding/ending mode (like the random padding), is IMO
the
better idea. To me it comes down to, if the implementer has enough
cryptographic knowledge to determine if a different padding/ending mode is
superior, the implementor also has the knowledge to properly adjust the
spec
to meet the specific needs.

The arguments between the two may not be compelling to any one person, but
since the only thing keeping PKCS#5 in use is the inertia, that inertia is
pointless here. The inertia behind the random padding mode is that it's
already been established as viable for XML Encryption, and is already
written into the spec. This already written in inertia is useful, it means
that all the current implementations don't need to be changed, and the
investment in that is useful inertia.
                    Joe
Received on Wednesday, 17 April 2002 11:38:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 08:42:20 GMT