- 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>
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 UTC