W3C home > Mailing lists > Public > xml-encryption@w3.org > April 2002

Re: EncryptionMethod in XMLEnc and SignatureMethod in XMLDSig

From: Tom Gindin <tgindin@us.ibm.com>
Date: Fri, 5 Apr 2002 21:33:10 -0500
To: aleksey@aleksey.com
Cc: Blair Dillaway <blaird@microsoft.com>, xml-encryption@w3.org
Message-ID: <OF857CEDA8.626F4198-ON85256B93.000CC6E8@pok.ibm.com>

      The algorithm substitution attack on signature, as a scenario, is
basically that you generate a signature without an algorithm, attach it to
a document which the message digest within the signature matches, and then
later find another document whose digest using another algorithm is that of
the original.  This attack may not be very likely with most algorithms.  It
doesn't work well against DSA (no digest algorithm changes allowed) or
PKCS#1 v1.5 (algorithm physically next to digest), and I don't think it
works against PSS very well either.  Furthermore, trying to find a
collision between two widely accepted hash algorithms (say RIPEMD-160 and
SHA-1) may not be much easier than finding a collision inside one - which
allows you to do the same kind of forgeries.  However, if attackers can
choose an arbitrary digest algorithm for the second digest, the attack
becomes much more plausible.
      However, what I don't understand on deeper consideration is how
putting the algorithm ID into the basis of the message digest stops the
attack.  Effectively, doing this changes the forger's problem from "find M2
such that H2(M2) == H1(M1)" to "find M2 such that H2(M2 || ID(H2)) == H1(M1
|| ID(H1))".  Since ID(H1) and ID(H2) are constants, this does very little
to complicate the forger's task.

            Tom Gindin

Aleksey Sanin <aleksey@aleksey.com> on 04/05/2002 04:33:28 PM

Please respond to aleksey@aleksey.com

To:    Blair Dillaway <blaird@microsoft.com>
cc:    Tom Gindin/Watson/IBM@IBMUS, xml-encryption@w3.org
Subject:    Re: EncryptionMethod in XMLEnc and SignatureMethod in XMLDSig

I still could not understand the algorithm substitution attack on XML DSig
if the SignatureMethod is ommited. The application expects that the
will be generated using algorithm A (this algorithm is is *hard coded* in
the application context). Suppose that someone generated signature using
algorithm B.
If application successfully validates this signature using *hard coded*
algorithm A
then IMHO it's the same as if an evil guy simply "guessed" the signature
algorithm A. IMHO, this simply means that algorithm A is weak and must not
be used as signature algorithm at all (evil guy can guess signature
*w/o* keys!!!)


Blair Dillaway wrote:

>I agree with you. Alg substitution isn't a very useful attack on XML Enc
>or XML Sig with the algorithms defined in the spec.  If one used some
>other algorithms, then it might be an issue for Sig.  Though, one might
>question the wisdom of using a signature alg open to this type of
Received on Friday, 5 April 2002 21:34:01 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:32:03 UTC