W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > October to December 1999

RE: Canonicalization

From: Phillip M Hallam-Baker <pbaker@verisign.com>
Date: Fri, 22 Oct 1999 11:18:27 -0400
To: "Jim Schaad (Exchange)" <jimsch@EXCHANGE.MICROSOFT.com>, "W3c-Ietf-Xmldsig (E-mail)" <w3c-ietf-xmldsig@w3.org>
Message-ID: <001801bf1ca0$b0d72ca0$6e07a8c0@pbaker-pc.verisign.com>
> In this example, the first 62% of the document (roughly 840 characters) is
> the same for all signed messages. (This assumes that the same
> canonicalization and signature algorithm are routinely used.)  This means
> that the data that changes from message to message is not contriubuting as
> much to the hash computation as it could.

I am not familliar with an attack which takes advantage of such a situation.
Certain MAC constructions based on message digests are vulnerable to
an extension attack.

With most commonly used cryptographic digest algorithms the chaining
function biases the message in favour of the later bytes to the
extent it introduces a bias. And even then the bias is negligible
(calculate by assuming the compression function to be perfect, then
consider the probability that the various inputs to a sequence of
two compression functions cause a collision).

I fail to see how having an initial constant 840 bytes introduces any
security issue that is not introduced by always starting the chaining
function with the same initialization vector - which is arbitrary
in any case.

> I don't believe this will hurt any implemenations as I do not believe that
> one pass parsing and signature evalution is possible in XML and this
> significantly improves the hash as you cannot preload 50% of the hash
> computation.

If one pass isn't possible we are probably doing something wrong and
should fix it.

Received on Friday, 22 October 1999 11:16:55 UTC

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