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 20:20:26 UTC