RE: 2nd try at Algorithms Section

> From: xml-encryption-request@w3.org
> [mailto:xml-encryption-request@w3.org]On Behalf Of Joseph Ashwood
> Sent: Tuesday, June 05, 2001 4:43 PM
>
> ----- Original Message -----
> From: "Jim Schaad" <jimsch5@home.com>
>
> > > 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.
>
> But because we define the location of the IV in a location
> other than with
> the cipher definition any attempt to do that will break the spec.

When I define a new algorithm I need to define 3 things: The URI for the
algorithm, the XML structure of parameters for the algorithm and the
processing rules to convert an octet string to an octet string.  These are
independent for all algorithms created.  If I create an XOR encryption
function, it does not have an IV defined anyplace and none is needed.  If I
create an RC5 encryption function, the parameters (block size, key size and
rounds) could be defined in a) the URI, b)the XML structure or c) the start
of the cipher text (in a number of different formats).  This is totally
independent of how 3DES defines it's own processing rules.

>
> > 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.
>
> By moving it from the front of the ciphertext to the cipher
> definition two
> encrypted texts under the same key become a Vigenere cipher
> under counter
> mode. Vigenere ciphers are exceedingly weak and are commonly broken by
> beginners.

I disagree that putting the IV at the start of the cipher text means that a
new IV would always be used.  I don't think this item is settlable.

>
>
> > > > 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).
>
> I honestly hadn't thought too seriously about using OAEP, but
> using it with
> non-random data will not compromise things (see OAEP proof).
> However the
> situations in which this would be useful are extremely few,
> effectively
> limiting it's usefulness to situations where less than
> size(hash function)
> information is being transferred.
>
> >
> > >
> > > >
> > > > 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.)
>
> There is an implied data length available when it is used to
> transfer keys.
> We will always know that X bits are needed for the key, they
> can be simply
> taken from the end. This means that all the prior data is
> unexamined so
> placing extra requirements on it can only lead to potential attacks.

If you want to change PKCS#1 processing rules -- take it up with RSA.

>
> >
> > >
> > > > 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.
>
> And Germany had a "current practice" of using Enigma, it
> doesn't mean it's
> good, it just means that someone doesn't know any better.
> OAEP has provable
> security under a very small set of constraints, PKCS 1 v1.5 has a
> compromising attack against it. From a security standpoint there is no
> reason to even bother having PKCS1 v1.5, recommending it's
> use instead of
> something provably stronger doesn't seem like a course of
> action I would
> care to undertake.

If you think this is true, then I assume you have argued strongly againist
any incusion of RSA#1 v1.5.  Given that the best attacks I know of have to
do with either a) bad padding or b) intereactive environments, I don't think
that this is a bad recomendation.

>
> >
> > 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.
>
> OAEP is only secure as long as the value being transferred is under
> size(hash) in length, so transferring a 168 or 192-bit 3DES
> key using SHA-1
> leads to not having provable security, while trasnferring it
> with SHA-256
> results in provable security. That leaves OAEP with SHA-256 as having
> provable security for transferring 3DES, AES, and any other
> key <= 256 bits.
> OTOH PKCS1 1.5 has an attack against it.
>
>
> > > > 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.
>
> Generate DH shared secret S
> acquire nonce N
> key = hash(S | N)
>
> That is standard in the cryptography community and has provable
> characteristics (again under certain assumptions from the
> hash algorithm).
> I'm not sure I can get any clearer without going into the
> hash algorithm and
> the DH key exchange

That is a key derivation algorithm.  I asked for a KeyWrap algorithm (i.e.
encrypt a symmetric key with a symmetric key).

>
>
> > > > 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.
>
> I am generally against everything CMS, they tend to have
> found ways of doing
> very simple things in the most complex and convoluted ways ever seen.
>
> > > > 3)  What is the structure and elements for this.  I suggest
> > > the following:
>
> I think we agreed on the keysize.
>
> >
> > 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.
>
> Cryptographically there are 2 useful types of information to
> the DH key
> exchange, a shared secret, and something that doesn't repeat
> for a very long
> time and isn't a counter (with some hash functions this could
> result in an
> attack so to tighten the proof it must not be a counter).
> That is the shared
> secret, and the nonce, everything else is just extra space
> being taken up
> for what amounts to no reason.
>
> > > > 4) What is the default hash algorithm.
> > [I believe this needs discussion]
> Agreed. Does anyone else have thought on what the default
> hash algorithm
> should be? So far the proposals have been SHA-1 and SHA-256.
>
> > > > 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.
>
> Does anyone else have an opinion? We have options of "secret" "shared"
> "symmetric" "shared-secret" (am I missing any?). My preference is to
> symmetric, because it will line up with the research view.
> The argument for
> secret is that it will make sense easier to common people.
> Similar argument
> for shared, and shared-secret.
>
> >
> > >
> > > > 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.
>
> In DSIG it is used as a hash algorithm, here it is used for
> key mashing.
> There is also the argument that we might want to reduce the number of
> namespaces in use, forcing the inclusion of DSIG for the hash
> algorithms
> doesn't seem to line up with that too well. I'm neutral on
> this subject, it
> really makes no difference to me.

At this location in the document, the SHA hash function is being used for
integrety checking.

>                         Joe

jim

Received on Wednesday, 6 June 2001 00:13:10 UTC