W3C home > Mailing lists > Public > xml-encryption@w3.org > June 2001

Re: 2nd try at Algorithms Section

From: Donald E. Eastlake 3rd <dee3@torque.pothole.com>
Date: Wed, 06 Jun 2001 13:22:41 -0400
Message-Id: <200106061722.NAA0000041614@torque.pothole.com>
To: <jimsch@exmsft.com>
cc: <xml-encryption@w3.org>, lde008@dma.isgmot.com

[I know there are later comments in this thread but I'm going to
finish off this response before diving into them...]

Hi Jim,

It's great to get such extensive and detailed commentary!

From:  "Jim Schaad" <jimsch5@home.com>
Reply-To:  <jimsch@exmsft.com>
To:  <xml-encryption@w3.org>, <Donald.Eastlake@motorola.com>
Date:  Tue, 5 Jun 2001 02:21:19 -0700
Message-ID:  <001701c0eda0$e1da3c20$0d00a8c0@soaringhawk.net>

>Here are my comments on your draft.
>1.  The current thinking for the S/MIME working group is that 128 and 256
>are going to be MUST algorithms with 192 probably being a MAY.  The working
>assumption here is that 128 is going to be strong enough for the "near"
>term, and that 256 is there for the paranoid to use.  I suggest that we
>following the S/MIME working group's lead.  128 and 256 are REQUIRED, 192 is

OK with me.

>2.  I suggest that we remove RC2 key wrap from the table.  We are not using
>RC2 as an algorithm so there is no need to keep the RC2 key wrap.


>3.  Section 5.2, para 1:  Please omit the text "Any initialization vector
>required is encoded with the cipher text."  Why this is true of the
>algorithms we are defining, it is not necessarily true for other peoples

Will reword.

>4.  General:  I have not looked at the DigSig draft recently, however I
>would like to know which name form is going to be used for this algorithm:
>The one based on the xmlenc draft (xmlenc#3des) or the "urn" version used in
>the examples draft.  I think this item needs discussion.

I believe that, consistent with the XMLDSIG draft, we should use all
URLs that can point to documnetation.

>5.  Section 5.3.1:  I found the discussion of the 3DES key processing to be
>very confusing.  After reading the text I found that I needed to change my
>current key handling significantly as the "parity" bits are no longer
>carried in the key value.  Currently implementations have a 192-bit key
>value of which 168-bits are significant key information.  Processing the way
>it is currently described is very hard as every 8-th bit is parity and needs
>to be inserted in the 56-bit key to make a 64-bit key value.  This text
>should be altered by removing the discussion on EDE entirely as this is
>covered in the FIPS and ANSI documents.

I think you mean 5.2.1.

There are reasons for tossing the silly parity bits. Their presence
leads to additional complexity in generating them and sometimes in the
harmful checking of them. (Note the famous case of the secure telnet
implementation which generated DES keys with all zero parity bits but
then called crypto routines which ignored the key if the parity was
wrong and just encrypted with a zero DES key. This meant that 255 out
of 256 times, you wre encrypting with a constant known key. Of course
the data looked random and this implementation interoperated fine with
itself,which was how it was normally used. It was in use for years
before anyone noticed.) However, if it is really that inconvenient for
many people to eliminate the parity bits due to the crypto library
they are using or whatever, I'll change it.

I see no harm in the one sentence which tell you what's going on with
EDE. This document has some limited details on algorithms so someone
generally familiar with modern crytography can tell what's going on,
rather than a terse "algorihm X as defined in document Y".

>6. Section 5.3.1:  I firmly believe that changing the chaining mode changes
>the algorithm and a new URI should be assigned.  I also would like
>information such as the chaining mode to be included in the URI so I prefer
>the text "xmlenc#3des-ede-cbc" for the name.

This is a spectrum. After all, why stop with 3des-ede-cbc? What about
the padding? What about the type of CBC? As I recall, there are really
four different ways to do CBC.  I really can't see any reason anyone
would bother with other that EDE so I'm not willing to stick that in
unless there is a clear consensus to do so.  I suppose we could add
"-cbc" but I'm inclined to have it be the default and add a suffix
if/when a different chaining mode algorithm is ever defined.

>7. Section 5.3.1:  Can somebody summerize for me the basis on which it was
>decided to place the IV in the cipher text.  There are three alternatives
>here and I would like to know the rational behind the decision.  1) Put the
>IV in the EncryptionMethod element, 2) Prefix the IV to the CipherData, 3)
>prefix one block of random data to the plain text and use an IV of zero
>(tossing that block on decrypt).

I don't remember exactly but apparently it was felt to more tightly
link the IV and the cipher text to avoid confusion or any temptation
to use the same IV element for more than one ciphertext or
something. It's also less verbose.  I really don't care on this point
and would not mind an <IV/> parameter but was just following what the
group wanted. But I don't like your option 3.

>8. Section 5.3.1: Should add the sentence "No parameterization exists for
>this algorithm." or similar text someplace.

? First sentence in the section says "...takes no explicit parameters."

>9. Section 5.2.2:  See comment 6 above - recomend inclusion of -cbc in the

See response above  :-)

>10. Section 5.2.2: ditto item 8.

Will do but if no explicit parameters are defined for an algorithm I
don't see why anyone would be confused...

>11. Section 5.3.1:  There is nothing in theory that prevents the use of RSA
>within an EncryptedData element, that is to encrypt the data directly.  Is
>this a mode that we need to /should support?

Generally adding RSA as a sort of block encryption algorithm for
messages that might be large relative to the modulus would require
defining the padding and formatting...

Just allowing rsa-1_5 and rsa-oaep for encrypting data which is small
enough to fit in place of the "key" as those algorithms are defined
would be easy to add as an option but I question how useful it would

>12.  Section 5.3.1: change text to "at least eight octets long, containing
>no zero octets and long enough.."


>13.  Section 5.3.1: I suggest adding the following text. "This document
>RECOMMENDS that rsa-v1.5 NOT be used for transport of AES keys as there are
>some known attacks againist it [RSA-ATTACKS].  This document RECOMMENDS that
>rsa-v1.5 be used for transport of 3DES keys for compatilibity with existing
>cryptographic systems."  RSA-ATTACKS could either be a future document from
>the S/MIME group or a reference to the appropriate section in V2.

Hummm, a NOT RECOMMENDED here seems a bit strong... How about if we just
say that RSA-OAEP is preferred for AES keys?

>14.  Section 5.3.2:  schema should be along the lines of:
><element name="RSA-OAEP" type ="RSA-OAEPType"/>
><complexType name="RSA-OAEPType">
>  <sequence>
>    <element name="DigestMethodAlgorithm" type="ds:AlgId" minOccurs="0"/>
>    <element name="MaskGeneratorAlgorithm" type="ds:AlgId" minOccurs="0"/>
>    <element name="PSourceAlgorithm" type="ds:AlgId" minOccurs="0"/>
>  </sequence>

You are quite right that the digest function parameter element shouldn't
be the somewhat weird OAEP I had defined. I was already going to change
it to <DigestMethod/> for commonality. I'm not sure if it's worth 
having a default here.

>Define MaskGeneratorAlgorithm "rsa-oaep-mgf1" to be the MGF1 in RSA#1v2.0
>and be the default value if unspecified.

I wanted to avoid a whole new category of algorithms. I don't see any
evidence of a new mask generator with noticeable
deployment. Permitting this adds to the complexity of implementaion...
(If it was added to the syntax, it should be MaskGeneratorMethod.)

>Define PSourceAlgorithm "rsa-oaep-pSpecified" with content base64 value.
>default for this algorithm is no P value specified.

With DigestMethod being a paremeter element that could take content
for some hypothetical parameterized digest function, we do need a
separate element here.  What's wrong with just <P/>?

>Default for DigestMethodAlgorithm would be urn:sha-1.
>15.  Section 5.3.2: I suggest adding the following text: "This document
>RECOMMENDS that rsa-v2.0 be used for the transport of AES keys.  This
>document RECOMMENDS that rsa-v2.0 NOT be used for transport of 3DES keys."

First part fine. But if someone is useing 3DES, what's wrong with
transporting a 3DES key with rsa-oaep?

>16.  Section 5.4, para 1:  "associatred" should be "associated"

Sorry, maybe I'll actually spell check the next version...

>17.  Section 5.4:  I don't like the implied schema for this algorithm.  I
>suggest something along the lines of:
><complexType name="dhType">
>  <sequence>
>    <element name="OriginatorKey" type="ds:KeyValue" minOccurs="0"/>
>    <element name="KeyDerivationAlgorithm" type="ds:AlgId" minOccurs="0"/>
>    <element name="KeyWrapAlgorithm" type="ds:AlgId"/>
>  </sequence>

Why call it OriginatorKey instead of simply KeyInfo for commonality?

I'm not sure why this is a type. Algorithms are not elment nemaes but
attribute values. But maybe I'm confused.

I assume by derivation algorithm you mean how to get the key from the
shared secret produced by the agreemnt algorithm?  As with the MGF, I
don't see sufficient motivation to add a new category of algorithms.

Why does it need a KeyWrap Algorthm?

>18.  Add new section 5.4.3:  KeyDerivationAlgorithms.  Discussion is needed
>on the list about the following
>1) do we use the CMS version (which requires ASN encoding and mapping from
>xml algorithm identifiers to OIDs) or do we define our own "non-standard"
>method of doing it.

Obviously I think we should do our own derivation.  Otherwise we would
be requiring real ASN encoding. (XMLDSIG has some vestigial ASN but it
can all be handled with big hex constants.)

>2) What CMS elements do we want to omit and why were they there to begin
>The elements used in CMS for key derivation are: a) ZZ (the dh-agreement
>value), b) Nonce, c) Algorithm ID, d) resulting key size and e) counter.
>The resulting key size was specifcally added to address attacks on RC2
>dealing with the fact that it could be both 40-bit and 128-bit.  I don't
>remember the specifics on the attack anymore but think it would also apply
>to AES with 128 or 256 bit key size.

Currently the key size is included in the algorithm URI but I guess
there can be algorithms for which the key size is a parameter or
something so adding a key size integer to the concatenated elements
seems reasonable.

>3)  What is the structure and elements for this.  I suggest the following:
><complexType name="xmlKeyDerivationType>
>  <sequence>
>    <element name="Nonce" type="ds:base64" minOccurs="0"/>
>    <element name="DigestMethod" type="ds:AlgId" minOccurs="0"/>
>    <element name="KeySize" type="integer" minOccurs="0"/>
>  </sequence>
>KM(counter) = Hash(ZZ | <AlgURN> | counter | Nonce | KeySize)
>4) What is the default hash algorithm.  I recommend that we use SHA-1 for
>3DES iff we use the CMS encoding of the data.  Otherwise SHA-256 allows for
>a much better key as all bits are generated independently (rather than using
>the counter to "re-generate" some dependent bits).

I don't see the coupling to CMS encoding.  As far as I'm concerned, we
should be avoiding ASN.1 and using string/XML encoding where we can.
Perhaps there should be no default and specification of a DigestMethod
be required.

>19. Section 5.4.1:  I suggest that the name X be altered to "Public".  I
>have seen a number of different letters used for this value (note that the
>CMS DH document uses ya and yb) and Public says what goes there and does not
>lead into possible errors of x vs X.


>20.  Section 5.5:  please change text from "secret" to "shared" in the first

How about if I say "shared secret"...

>22.  Section 5.5.3:  This section should be omitted as we are not doing an
>RC2 anyplace else.  If somebody defines RC2 as a block algorithm they can
>defined the key wrap for it.


>23.  Section 5.6.1:  Should we define a new id for SHA1 or use the one from
>the signature draft.

Multiple ids for the same thing = bad.


Received on Wednesday, 6 June 2001 13:23:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:32:00 UTC