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

[Hauke Laging]

Hello,

not a GnuPG specific problem but perhaps relevant to GnuPG users.

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. There could even be a 
field especially for a random modification by the recipient.

Often documents have to be signed by both parties. How can the sender be safe 
against a collision attack by the recipient's modification? One aspect is 
time. If you get the document back within days it seems very hard to get the 
attack done in that time. But perhaps it also helps to have certain 
requirements for the modification; requirements which make a collision attack 
a lot harder (but are easy to check). I can just guess what that may be. 
Perhaps the combination of a random value and its hash:

ACAM: JIu1ZmRJdYFH9wVspZr9 a6dd2f422f95606ff3e1de4ccb662f5f3a876d92

There could be one such Anti Collision Attack Modification field for each 
party. It would make sense to require a hash algorithm with heavy CPU load for 
this. But perhaps this is exaggerated and the additional space serves just as 
well? :-)

Of course, this is not intended as a possibility to continue using hash 
functions with known collision attacks but as a precautionary measure as you 
can never be sure that you know all your attacker knows (who need not even be 
the one you want to make a treaty with). Probably not even the majority of 
OpenPGP users is immediately aware of the publishing of new attacks.


Hauke
-- 
☺
PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 555 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20120924/c63a0091/attachment.pgp>