RE: Parameters and Algorithms.

Eric makes some excelent points. The issues with DSA are considerably
more constraining than as Eric States them.

The PKCS #1 RSA signature format includes the message digest algorithm
for precisely the 'downgrade attack' reasons Eric mentions. The ability to
substitute the message digest was a carefully thought out part of the
format design.

With DSA the algorithm was explicitly designed arround the use of SHA
(later changed to SHA-1). Unless the digest length is precisely 160
bits it is simply not possible to use DSA. The whole algorithm changes.

Not only is DSA not designed to support other digest algorithms, the
designer clearly took steps to prevent this occurring.


The specification of the message digest in an envelope format is generally
a courtesy notification to allow the application to perform one pass
verification of the signature. The binding of the digest alg to the
signature itself is the responsibility of the signing format.


		Phill


> -----Original Message-----
> From: w3c-ietf-xmldsig-request@w3.org
> [mailto:w3c-ietf-xmldsig-request@w3.org]On Behalf Of Eric Rescorla
> Sent: Thursday, October 14, 1999 12:11 AM
> 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 15:31:20 UTC