bugtraq - Re: SHA-1 broken

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <42185C20.2070503@syneticon.de>
Date: Sun, 20 Feb 2005 10:45:04 +0100
From: Denis Jedig <seclists@...eticon.de>
To: "bugtraq-securityfocus.com" <bugtraq@...urityfocus.com>
Subject: Re: SHA-1 broken

Tollef Fog Heen wrote:

> | we might think of changing the requirement of collision resistance
> | to "collision resistance in input data that is valid ASCII text". The
> | attacks on MD5 used the weak avalanche of the highest-order bit
> | in 32-bit words for producing the collision, basically precluding the
> | possibility of generating colliding ASCII text.
> 
> That's not really useful is you want to sign something in non-English
> languages.  Valid UTF8 might be a decent requirement, though.

What about Word documents? PDF files? Executable code? Depending on the
context the meaning of "valid" will differ greatly. So you would have to
supply a validation engine together with the signed data.

I do not know enough about the characteristics of the MD5 attack to
judge if using Base64-encoding beforehand would strongly mitigate it,
however, an abstraction layer of encoding in a well-known format would
make validation of the encoded stream easier. The big question is if
there is a gain at all when using this validation - we still do not
validate the original data, just the abstraction layer.

Denis Jedig
syneticon GbR