- From: Donald Eastlake 3rd <Donald.Eastlake@motorola.com>
- Date: Wed, 23 May 2001 10:00:09 -0400
- To: xml-encryption@w3.org, Donald.Eastlake@motorola.com
- Message-ID: <3B0BC268.9472902C@motorola.com>
Hi, Attached is my second expanded try at an algorithms section. It's still tentative and a bit incomplete and no doubt has a number of errors in it... I did split out integrity hash functions (which are also useful in OAEP) so these can be orthogonally specified with data encryption functions. I've also dropped SHA384, as suggested by Joseph Ashwood, on the grounds that in the XML environment, if you are going to the same amount of work as needed to compute SHA512 you might as well just use SHA512. (SHA384 is not exactly a truncationed SHA512 because different initial constants are used and this point can certainly still be debated...) Among the open questions are the follows: (1) Should a stream cipher be added? "OTP", BBS, RC4, and ISAAC have been suggested. There is clearly almost no support of having a mandatory stream cipher but one or more could be optional or recommended. (2) Should we add a European hash algorithm or algorithms such as RIPEMD-160? (3) On Diffie-Hellman, the attached makes specification of the hash function orthogonal (since we have separate hash algorithm URIs anyway) as well as "P" but rolls the Mask Generation Function into the DH URI to avoid bothering to create a new class of algorithms and additional verbosity when I don't think there will be much need for a different MGF any time soon. And when there is, we can define a new DH-MGF2 URI or whatever. This could be changed either way. The MGF could be broken out as an additional explicit parameter. Or we could remove the ability to specify an arbitrary "P" and just have it be null and/or fix the hash algorithm at SHA1 or something... (4) On the Symmetric Key Wrap algorithms, I have assumed that the consensus is still to follow the CMS algorithms exactly. However, especially now that I have written it up, it seems very odd that we have RC2 CMS wrap mandatory, which requires the implementation of the RC2 cipher, when that ciper isn't even optional for data encrytion. Should this be made consistent and if so how? (5) Additional Block Ciphers. It has been suggested that all the other AES finalists be added as at least optional except possibly RC6 which is encumbered. (I suggested that, since we already have 3DES and AES, we add a block cipher that was a composition of them but there seems to be no net support for that which was probably a bad idea.) (6) Additional chaining modes. It has been suggested that at least provision be made for specifying other chaining modes (other than by definining new URIs) and/or that a counter mode be added. I'll post my opinions on these in a separate message. Thanks, Donald
Attachments
- text/html attachment: x10.html
Received on Wednesday, 23 May 2001 10:01:19 UTC