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

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.

The Signature algorithm is part of the data being hashed.

jim


-----Original Message-----
From: EKR [mailto:ekr@rtfm.com]
Sent: Wednesday, October 13, 1999 5:20 PM
To: Jim Schaad (Exchange)
Cc: W3c-Ietf-Xmldsig (E-mail)
Subject: Re: Parameters and Algorithms.


"Jim Schaad (Exchange)" <jimsch@EXCHANGE.MICROSOFT.com> writes:
> 2)  DSA does not (to the best of my knowledge) specify that SHA must be
> used, this is done in the DSS standard.  Thus to mix the naming of DSA and
> DSS is bad practice.  One could actually use DSA today with RIPEMD-160 as
> that also produces a 160-bit hash.  Also the new AES algorithm will
> undoubtly work with DSA (I don't remember if DSA or DSS specifies the
sizes
> of Q and P) and we should be ready for that.  So I suggest:
> 
> <SignatureAlgorithm name="urn:nist-gov:dsa">
>    <DigestAlgorithm name="urn:nist-gov:sha1"/>
> </SignatureAlgorithm>
> 
> - Again we can specfy SHA as the default if desired.
>
> 3)  RSA is underspecfied in the name and we should deal with the 3 (to
date)
> different padding algorithms that are possible for RSA.  So I suggest:
> 
> <SignatureAlgorithm name="urn:rsadsi-com:rsa">
>   <DigestAlgorithm name="urn:nist-gov:sha1"/>
>   <PaddingAlgorithm name="urn:rsadsi-com:pkcs1_v1.5"/>
> </SignatureAlgorithm>
> 
> - Here I would recomend no default digest algorithm but we could default
the
> padding alg.  Additional values for this would be
> "urn:rsadsi-com:pkcs1_v2.0", some name for the IEEE P1363 padding
algorithm
> and some string for a new OEAP algorithm (descibed here).  As part of this
I
> think we want to also think about the wisdom of removing the OIDs from the
> signature padding algorithm.  If we want to add in a new hash algorithm,
> there is no real need to put the OID value as a prefix on the digest
before
> encrypting the data, the hash algorithm is already covered in the
SignerInfo
> object and therefore is not easily changable.  As new hash algorithms come
> into existance we do not want to have to wait for  and agree on an OID to
be
> assigned to the algorithm before it can be used.
Jim,

For security reasons, both (2) and (3) are bad ideas. It's not safe to
have substitutable digests that aren't protected.

To understand why this is a problem, consider the following
scenario. Imagine that DSA may be used with both SHA-1 and RIPEMD-160,
as you suggest. Now imagine that an attacker breaks RIPEMD-160 in such
a way that he can generate messages with arbitrary digests.

Now, imagine that you don't like RIPEMD-160 and sign all your messages
with SHA-1. Nevertheless, the attacker can generate a forged message
from you (signed with RIPEMD-160/DSA).

He takes a message M that you've signed (using SHA-1/DSA).  He
generates a new message M' such that RIPEMD-160(M')=SHA-1(M).

He can then reuse your signature on M as a signature on M' by
retagging it as a signature using RIPEMD-160/DSA.

Having the name of the digest be part of the data digested does NOT
protect against this attack. It merely becomes part of the message M'
that the attacker must generate.

This attack is why PKCS-1 signatures include the algorithm OID as part
of the data signed. It's not safe to remove them.  It is also why DSA
must only be used with one type of digest in any given
application. [0] In this case, SHA-1 is the obvious choice.

-Ekr

[0] Actually, this isn't strictly true. It must be used
with any given digest for a given keysize. It should be
safe to use a different digest if Q was set to (say)
256 bits.

-- 
[Eric Rescorla                                   ekr@rtfm.com]
          PureTLS - free SSLv3/TLS software for Java
                http://www.rtfm.com/puretls/

Received on Wednesday, 13 October 1999 23:38:05 UTC