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]
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



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ