Hello.

> As I understand, one bit is enough to destroy a tediously prepared collision

If the attacker can prepare one collision, he can also prepare multiple sets 
collisions.
It only adds some amount of complexity to the attack.

> and Wiktor noted that PGP includes a timestamp (to one second) in the signed 
> data

Timestamps are not random bits. An attacker can set up a situation where the 
victim will create the signature in a very short time window, and prepare 
accordingly.

If you need randomness, use real randomness.

> and the protocol allows implementations to add more data to the signature.

Of course there are countermeasures. But they cannot fully compensate 
weaknesses of the hash algorithm. (If they were, no cryptographic hash 
algorithm would be needed at all.)

To guide this discussion back to the origin:

B. W. thought that there is no way to launch a collision attack against 
signatures.

J. B. thought that modifying one bit would be enough protection.

J. B. also thought that including a timestamp would add to security in this 
situation.

I only want to illustrate kindly with examples why these thoughts are wrong, so 
that you do not make unsafe decisions based on these – very human – mistakes. 
(Absolutely no offense intended: I myself make similar mistakes far too often 
... :-) )

Kind regards
-- 
Rainer Perske
Systemdienste + Leiter der Zertifizierungsstelle (UCAM)
-- 
Universität Münster
CIT - Center for Information Technology
Rainer Perske, Systemdienste
Röntgenstraße 7-13, Raum 006
48149 Münster
Tel.: +49 251 83-31582
E-Mail: [email protected]
Website: www.uni-muenster.de/IT

Universitätszertifizierungsstelle Münster (UCAM):
Tel.: +49 251 83-31590
E-Mail: [email protected]
WWW: www.uni-muenster.de/CA

YouTube: youtube.com/@uni_muenster
Instagram: instagram.com/uni_muenster
LinkedIn: linkedin.com/school/university-of-muenster
Facebook: facebook.com/unimuenster

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Gnupg-devel mailing list
[email protected]
https://lists.gnupg.org/mailman/listinfo/gnupg-devel

Reply via email to