Re: 2nd try at Algorithms Section

----- Original Message -----
From: "Jim Schaad" <jimsch5@home.com>

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

There's really no reason to include the ede (we discussed this, the FIPS
actually specifies EDE), but the cbc should be included at least for the
sake of completeness.

I disagree with you on the changing the chaining mode changes the algorithm
though, but we've been round that bush enough times already, it was decided
that there was nothing I could say to change the concensus and there was
nothing they could say to change my opinion, so the chaining mode is a part
of the algorithm.

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

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

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

>
> 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).

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

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

>
> 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).

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

> 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).

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

> 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.
                        Joe

Received on Tuesday, 5 June 2001 15:02:30 UTC