RE: 2nd try at Algorithms Section

Joseph,

see inline comments.

> -----Original Message-----
> From: xml-encryption-request@w3.org
> [mailto:xml-encryption-request@w3.org]On Behalf Of Joseph Ashwood
> Sent: Tuesday, June 05, 2001 11:55 AM
>
> ----- Original Message -----
> From: "Jim Schaad" <jimsch5@home.com>
>
-snip
>
> > 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,
>
> For now this would work since we are rather CBC centric, but
> when someone
> decides to use a stream cipher, or a cipher in counter mode this would
> completely destroy the security.
>
> 2) Prefix the IV to the CipherData,
>
> This is functional for all reasonable definitions.
>
> 3)
> > prefix one block of random data to the plain text and use
> an IV of zero
> > (tossing that block on decrypt).
>
> Same argument as 1), an attacker simply accepts that the
> first block is
> garbage and only works on the remaining blocks.

I have a hard time accepting your arguments.
1. Where the IV is for these algorithms and where it is for a future stream
cipher or a counter mode cipher is not relavant.  These algorithms can
define their own behavior.

2. Simply moving the IV from the first block of the cipher text to the
EncryptionMethod element seems to me to be a funny way to break security.
It is readily identifiable (and modifiable) in both locations.

3. Yes I know what the attack for a random block of data is, but even with
an IV the first block is "known" to the same degree as it would be in this
case.  I don't know of any cryptographic advantage or disadvantage for this
method.

4. A better arguement that I just thought of for putting the IV in its
suggested location is simply that the IV is still present even when the
EncryptionMethod element is absent.  This is the type of justification that
I was looking for.

If this is indeed the justification for doing it this way, I believe this
should be included in the general discussion of symmetric encryption
algorithms.

>
> >
> > 8. Section 5.3.1: Should add the sentence "No
> parameterization exists for
> > this algorithm." or similar text someplace.
>
> But there are several parameters, all of them assumed. There is the
> parameter of the public key, private key, key length, etc. I think the
> current "The RSA-PKCS1-v1_5 algorithm takes no explicit
> parameters." is more
> appropriate.

I was thinking in terms of the XML structure, but your wording is fine.

>
> > 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?
>
> This is one of those gray areas, with non-random data RSA has
> proven itself
> to be weaker than most people realize (see the attack on PKCS 1 v1.0)

I realize this is true for v1.5, but is the same arguement true for OAEP?
This is a mode which simplifies things in some cases and thus should be
considered (although not necessarily adopted).

>
> >
> > 12.  Section 5.3.1: change text to "at least eight octets
> long, containing
> > no zero octets and long enough.."
>
> I would strongly disagree with that change. The supplied
> weakening of the
> random pool would supply leverage that could potentially be
> used to attack
> the system. Examples of this kind of flaw show up prominently
> in public
> literature regarding Germany's Enigma machine because it
> allow a single
> value as output (nothing mapped to itself).

This is exactly the text that is in PKCS#1.  The key is identified by
scaning forward looking for a zero byte, the rest of the item is then the
key.  The existance of the zero byte seperates the padding from the key.
(Remember there is no data length encoded in the structure anyplace.)

>
> > 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."
>
> I disagree with you there. The primary reason is that when OAEP is
> implemented correctly it is a provable
> All-Or-Nothing-Transform (under the
> assumption that the hash is strong). The only problem is that
> the default
> hash (sha-1) doesn't support the entire size needed for a
> 3DES key. Since
> that is that case it may be reasonable to change the default
> to SHA-256.
> Since we're hashing a small amount of data the performance
> loss will not be
> measurable under most circumstances, SHA-256 is on track to becoming
> specified as a part of the SHA-2 specification fairly soon
> there should be
> little remaining reason not to use it.

This recomendation is simply to match current practice in the CMS world.

However, you have lost me entirely with the discussion on the length of the
hash value.  I understand this is a problem for key derivation, but was not
aware it had implications for the OAEP padding.

>
> > 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>
> > </complexType>
> >
> > 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.
>
> I'd suggest going non-standard, I can see no justification
> for requiring an
> ASN encoder/decoder along with an XML. Since we're using this
> only for key
> transport the key derivation algorithm can be simply a hash
> of the shared
> secret (let the changing IV do it's job). Or we can have a
> secondary value S
> that is XORd with the hash of the shared secret for when the
> key has to be
> chosable.

Please propose to the list the key wrap algorithm (with encoding and
implementation details) so that we can look at it.  There is no IV in case
of the CMS key wraps so you text is a NOP here and is only relevant in the
key wrap discussion.

>
> >
> > 2)
> I'm against the CMS version because it's kludgy. It's far
> more efficient to
> use either what I listed above or MQV. MQV is superior (it
> has provable
> security characteristics), but it takes more processing time
> and more data.
> The RC2 attack actually does not apply to Rijndael/AES
> 128/256, the presence
> of such an attack would have eliminated it from the AES
> selection process
> (and I looked for it myself).

The CMS version of key derivation is taken from X9.42.  I don't understand
the reasons that it was the chosen one, but I must assume from your text you
did not care for in that environment either.

>
> > 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>
> > </complexType>
> >
> > KM(counter) = Hash(ZZ | <AlgURN> | counter | Nonce | KeySize)
>
> Key size is an effectively unused parameter, the key size is
> known from the
> algorithm it is being mapped into. Everything there except
> the nonce and the
> shared secret are useless values cryptographically. The
> resulting key size
> is parameterized by the hash and the algorithm, if the
> resulting hash is too
> long simply drop the last k bits of the hash.

As long as we always have fixed size key algorithms (i.e. nobody does RC2)
then I agree that KeySize can be omitted without a problem. (In any event it
is "built into" the current algorithm urn's we are using.)

Are you arguing that the algorithm URN should also be omitted?  The
algorithm I was planning to place here was the key wrap algorithm (ala CMS),
but if I understand the above text correctly you feel this is "useless"
information.

>
> > 4) What is the default hash algorithm.
>
> I have personally argued several different sides on this, but
> I believe that
> for the time being SHA-1 is the most trusted algorithm so it
> should be the
> default. Once the SHA-2 FIPS is out (FIPS 180-2 has been
> rumored as becoming
> available with the final AES FIPS) we can safely move to
> SHA-256 or even
> SHA-512 for trust relationships. Currently using SHA-1 for
> 3DES would not
> work very well, you yourself pointed out that currently to
> conform to the
> FIPS we use a 192-bit 3DES key. I suppose we could change
> this, allowing for
> either 168 or 192-bit keys (should be easy enough to tell the
> difference).

If we go with an XML algorithm, I would say that SHA-256 is the correct
default hash algorithm.  If we stay with the X9.42/CMS algorithm then I
believe this needs discussion.

>
> > 20.  Section 5.5:  please change text from "secret" to
> "shared" in the
> first
> > sentence.
>
> I'd prefer "symmetric" but "secret" is an accepted term in
> the cryptographic
> community for the type of encryption, while "shared" is not.

I can accept symmetric, but in this case secret does not distinguish in my
mind if this is a public/private or a shared-secret algorithm.  The first
does have a secret key, but that is not the correct usage here.

I can accept shared-secret or symmetric.

>
> > 23.  Section 5.6.1:  Should we define a new id for SHA1 or
> use the one
> from
> > the signature draft.
>
> It's a significantly different usage so that could certainly
> be used to
> justify the new urn, but at the same time anywhere where they
> implement both
> the same code would be used. I could easily support either
> side on that.

How is it a signifcantly different usage?  It is still a digest algorithm.
I would not be in favor of assigning multiple names to the exact same
behavior.

>                         Joe
>

jim

Received on Tuesday, 5 June 2001 19:11:06 UTC