collision vs. preimage attacks: policy for signing data created by others

[spam man]

So the question is...

1.) I have two different messages that have the same hash value (a
collision).
           hash("foo") = abcdefg
           hash("bar") = abcdefg

2.) Now you want to append identical new data to the messages and see if
the new hashes would still be collisions?
          hash("foo and here are some more words") = tuvwxyz
          hash("bar and here are some more words") = tuvwxyz

Is this your question?


On Wed, Oct 3, 2012 at 12:07 AM, Hauke Laging <mailinglisten at hauke-laging.de
> wrote:

> Am Mo 24.09.2012, 19:06:17 schrieb Hauke Laging:
>
> Oh no – I am responding to my own email...
>
> > Given the much bigger difficulty of preimage attacks, would a rule make
> > sense not to sign a document that someone else has created (and thus been
> > given the opportunity for a collision attack)? The solution would be to
> > change the file in a way that does not affect the meaning (e.g. an
> > additional space somewhere) and can easily be detected to match this
> > condition.
>
> But I happened to find and answer to my question. In a seven and a half
> years
> old article about a collision attack against SHA-1. It's in German, though:
>
> http://www.heise.de/security/artikel/Keine-Panik-271334.html
>
> ("Grundsätzlich ist es eine gute Idee, vor dem digitalen Signieren eines
> Dokuments immer noch selbst eine kosmetische Änderung vorzunehmen.")
>
> It says: It does in general make sense to make a small change (that does
> not
> change the meaning) to a file before signing.
>
>
> I have another question about hashes:
> Given two different files that have the same hash value. If some data is
> appended (or prepended) to both files do the resulting files still have the
> same hash value?
>
>
> Hauke
> --
> ☺
> PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20121004/49adee6a/attachment.htm>