Re: Followup on I18N Last Call comments and disposition

     Are we sure that normalizing documents before digesting them allows
more "trivial variation digest search" attacks than not doing so?  I would
have thought it was the other way around.  In any case, the main defense
against birthday attacks is the sheer size of the search space.

          Tom Gindin

"Joseph M. Reagle Jr." <reagle@w3.org>@w3.org on 06/28/2000 08:56:33 PM

Sent by:  w3c-ietf-xmldsig-request@w3.org


To:   "Martin J. Duerst" <duerst@w3.org>
cc:   w3c-ietf-xmldsig@w3.org, "John Boyer" <jboyer@PureEdge.com>
Subject:  Re: Followup on I18N Last Call comments and disposition



At 11:49 6/28/00 +0900, Martin J. Duerst wrote:
(snip)
 >>   document is considered valid. Consequently, while we RECOMMEND all
 >>   documents operated upon and generated by signature applications be in
 >>   [NFC] (otherwise intermediate processors can unintentionally break
the
 >>   signature) encoding normalizations SHOULD NOT be done as part of a
 >>   signature transform.
 >>   http://www.w3.org/Signature/2000/06/section-8-I18N.html
 >
 >I think this puts two different kinds of concerns into the
 >same pot (but I'm not exactly sure, because I'm not really
 >familiar with the security language).

Well, it probably isn't even correct to call this a  "Birthday Attack," I'm
hoping someone else jumps in and tweaks the text, but I think the gist of
what you are after is there.

[Tom Gindin] The wording of section 8.1.3 is somewhat unfortunate already.
While it is true that transforms appear to increase the number of documents
which map to the same digest, that number is already literally
astronomical.  For SHA-1, for example, the number of documents of length N
octets in UTF-8 which map to a given digest is 256**(N-20) or
2**(8*(N-20)).  Larger hash algorithms may increase the number 20 somewhat,
but a 200 octet message restricted to printable ASCII would still exceed
2**1000.  Not normalizing before digesting is what allows inconsequential
changes to affect the digest.

(snip)

Received on Thursday, 29 June 2000 10:52:46 UTC