RE: Parameters and Algorithms.

OK -- let me see if I have this straight.

Taking the second point first:

1.  CMS says that you only use sha1 with DSA.  However there is absolutely
nothing in CMS which states that I could not write a new RFC that uses
dsa-with-CRC and start having people use this -- correct?  

2.  Saying that DSA only works with 160-bit hashes is not even a completely
correct statement.  I could easily write an RFC for dsa-with-MD5 and have it
work.  The first step in DSA is to compute the value of the hash mod Q, this
means that for dsa-with-sha1, there is a range of hash values that are
re-mapped onto the low end (i.e. M mod Q = M' for M >= Q).  Note that the
MD5 variant does not have this problem and could in one sense said to be
stronger.

3.  It is true to some extent that you can find some message that satifies
these needs for formatting constaints, but that is true for any
Hash/Signature algorithm pair.  You are now making a statement that
basically states ECDSA and DSA are bad generic algorithms (as defined in
IEEE P1363) since the hash function is not strictly defined.  You are also
saying that DSA cannot be reasonably used when an AES hash algorithm
appears.  It is always going to be a bad signature algorithm as long as
there is any possiblity that it may have more than one hash algorithm.  If
this is true then we might as well go home today and quit.

4.  Putting spacing and other such items is not always going to be as
effective as what you are making out.  Atleast no in the space we are
working in.  You also need to take into acount the cannonicalization that is
going to occur prior to hashing the text as well.  This means that I can do
just about anything I darn well please in one sense, and in another sense it
means that I can work againist the type of attack you are suggesting (i.e.
remove all extranious white-space, sort order of some items, etc.)

jim

> -----Original Message-----
> From: Eric Rescorla [mailto:ekr@rtfm.com]
> Sent: Wednesday, October 13, 1999 9:11 PM
> To: Jim Schaad (Exchange)
> Cc: W3c-Ietf-Xmldsig (E-mail)
> Subject: Re: Parameters and Algorithms. 
> 
> 
> > I am sorry Eric, but you are wrong in this case.  The 
> entire signature
> > algorithm is part of the hash, so they need to make a 
> message that is
> > correctly layed out, contains the new hash algorithm,...  
> Correct. We're discussing the situation where the digest algorithm has
> been completely compromised, so the attacker can efficiently make
> messages with arbitrary digests.
> 
> The formatting constraints you describe aren't really that difficult
> to achieve. Consider any message of more than 160 words. Simply by
> doubling (or not) any of the inter-word spaces, you can achieve 2^160
> different variations of reasonable looking messages. With high
> probability, one of these messages will match any given digest.
> 
> The only problem here is doing it efficiently. That's where the
> assumption that the digest has been compromised comes in.
> 
> Consider the case where one of the digest algorithms is CRC to see
> that this is possible with a sufficiently weak digest.
> 
> > If what you are saying is true, then they have an attack 
> againist DSA
> > anyway.  There is nothing to prevent somebody from creating 
> an OID for
> > DSA-with-RIPEMD-160 and putting that into the message today in CMS.
> My reading of the CMS spec is that this is forbidden. 
> 
>    The DSA signature algorithm is defined in FIPS Pub 186 
> [DSS].  DSA is
>    always used with the SHA-1 message digest algorithm.  The algorithm
>    identifier for DSA is:
> 
>       id-dsa-with-sha1 OBJECT IDENTIFIER ::=  { iso(1) member-body(2)
>           us(840) x9-57 (10040) x9cm(4) 3 }
> 
> I admit that it's not 100% clear. However, it seems to me that
> saying that DSA is always used with SHA-1 implies that it's not
> legal to define DSA-with-FOO.
> 
> > The Signature algorithm is part of the data being hashed.
> I'm aware of that. As I said in my previous message, that's
> insufficient. This is why PKCS-1 puts it in the actual
> signature, where it cannot be tampered with even if the
> digest is completely compromised. Unfortunately, this is
> not possible with DSA, which is why DSA must be used with
> SHA-1 only.
> 
> -Ekr
> 
> [Eric Rescorla                                   ekr@rtfm.com]
>           PureTLS - free SSLv3/TLS software for Java
>                 http://www.rtfm.com/puretls/
>

Received on Thursday, 14 October 1999 16:39:18 UTC