Re: 2nd try at Algorithms Section

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

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


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

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

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


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

Received on Tuesday, 5 June 2001 20:12:58 UTC