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

spam man spam2000 at
Thu Oct 4 17:51:57 CEST 2012

So the question is...

1.) I have two different messages that have the same hash value (a
           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
> 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:
> ("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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20121004/49adee6a/attachment.htm>

More information about the Gnupg-users mailing list