Re: block encryption algorithm padding

      Why is PKCS#5 padding in CBC mode more dangerous for XML encryption
than for ordinary binary encryption?  There are more and better
known-plaintext attacks against XML than against most things anyway.  IMHO
we need separate values for EncryptionMethod for using padding and not
using it, and I have nothing against making the defaults or the current
method name a variant without padding, since the arguments for padding are
not that compelling.

            Tom Gindin


"Joseph Ashwood" <ashwood@msn.com>@w3.org on 04/11/2002 06:10:22 PM

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


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


----- Original Message -----
From: Aleksey Sanin

> Thanks for your suggestion but the problem arrives when you are
decrypting
> the message and not when you are encrypting it (the libraries do padding
> check before returning the result).

Then you should be using a different encryption engine. Since the three
libraries you listed obviously don't suit the needs of the situation, they
are not and should not be considered useful. This will make implementation
more difficult, but difficulty is no reason to sacrifice a multitude of
benefits.

> As I said before from my point of vew the current proposed padding makes
> XML Enc non-interop with RFC1423 and from my expirience it makes
> harder to follow XML Enc standard for implementors.

RFCs are called "Request for Comment" for a reason, they are not absolute
standards. That RFC 1423 doesn't fit any purpose here, and only serves to
place limits of the security, serves as clear evidence that it would not be
an optimal choice. The padding verification is useless in a proper design,
I
shoed 1 simple attack against a cipher in CBC mode, what I didn't show is
that it is accepted policy to use a MAC algorithm to certify the integrity
of a message, making the padding completely useless as a verifier of
integrity.
                Joe

Received on Monday, 15 April 2002 11:38:04 UTC