Weaknesses in SHA-1

[Simon Josefsson]

David Shaw <dshaw at jabberwocky.com> writes:

> On Mon, Sep 27, 2004 at 09:33:29PM +0200, Simon Josefsson wrote:
>> David Shaw <dshaw at jabberwocky.com> writes:
>> 
>> > On Mon, Sep 27, 2004 at 01:56:25PM +0200, Johan Wevers wrote:
>> >> Alan S. Jones wrote:
>> >> 
>> >> >Why not allow for full support of SHA384 and SHA512 and not just read-only
>> >> >support in GnuPG 1.4?
>> >> 
>> >> And not to forget Tiger192. Why remove support for it in the light of these
>> >> developments?
>> >
>> > Why would you use Tiger192 when SHA256 is available?  I imagine SHA256
>> > is getting a lot more attention by people trying to break it than
>> > Tiger192 is.
>> 
>> I don't have an opinion personally, but there's always the argument
>> that if SHA256 is getting a lot of attention, you could end up in the
>> situation where SHA256 has been broken, but Tiger192 hasn't.
>> Read-only support could be a useful for a safety fallback mechanism.
>> The problem is when people start to use Tiger192 without good
>> reasons...
>
> I think history shows that any uncommon algorithm is going to be used
> simply because it's there...

And that's bad.  Maybe we can penalize such users somehow?  Only
enable Tiger192 read-only support if a certain token is in the config
file?  Then there is an escape mechanism if all but Tiger192 is
broken.

OTOH, you might take the stand that if SHA256 is broken, you have a
lot of other problems.  So any solution that would work for other
applications (that is, release a new version with support for SHA3)
would work for GnuPG as well.

Personally, I would rather have to upgrade once in a while due to
cryptographic advances, than have even more dead code to review in
security critical applications.  And if I were a maintainer, I
wouldn't want to maintain practically useless code, nor maintain an
escape mechanisms that might not ever be used, nor take on the support
cost of a niche market.

Just my $.2...