Re: block encryption algorithm padding

>On Thursday 11 April 2002 14:26, Aleksey Sanin wrote:
>> 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.
>Aside from questions of myth, what an RFC means, and who knows Ron Rivest 
>(he's a couple offices down from me but I fear it doesn't rub off on me! 
><smile/>), I think the simple issue is we already have interop over what 
>has been specified and it's hard to break that without a consensus of what 
>was specified is broken. In this case, the non-interop with RFC1423 is a 
>fact, but we didn't have a requirement to use that and we had reasons 
>for not using it. I'm open to a parenthetical comment in the spec to this 
>point if it's likely to be a surprise to others. And the fact that it isn't 
>common in the libraries you are using is unfortunate but remediable.
>I've documented the issue in [1] and will mark it closed unless there's an 
>objection that it should stay open to consideration by the Director when I 
>request document advancement.

The fact that we don't use PKCS#5 padding does add a tiny bit of
complexity, but it is trivial to solve. I also don't think the
argument that padding adds predictability is in any way applicable;
common uses of xmlenc will probably involve highly predictable text
(e.g., "<CreditCard..."). CBC mode and a random IV protects us against
dictionary attacks; otherwise, an extra bit of padding predictability just
doesn't harm us any more. I do think it is a pity that we don't support
transforms on the ciphertext; a compression transform could address this
problem. However, I know that this was discussed and discarded very early.


The information contained in this message is confidential and is intended
for the addressee(s) only.  If you have received this message in error or
there are any problems please notify the originator immediately.  The 
unauthorised use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for
direct, special, indirect or consequential damages arising from alteration
of the contents of this message by a third party or as a result of any 
virus being passed on.

This footnote confirms that this email message has been swept for Content
Security threats, including computer viruses.

Received on Friday, 12 April 2002 16:34:08 UTC