Presently 160 bits of hash block width seems to provide adequate security against brute force attacks. The recent developments concerning SHA-1 have reduced the effort to force collisions by 5 orders of magnitude according to the latest Wikipedia edit.
Other cryptographic primitives have been evolved to fix issues that were similarly found, such as:-
- RSA -> increasing bit count
- RC4 -> RC4A -> Spritz
- Whirlpool0 -> WhirlpoolT -> Whirlpool
I'm specifically using the term fix, to mean keeping the SHA-1 160 bit essentials and making internal changes /improvements. So some (but not limited to) changes might be:-
- amending the round count with perhaps double rounds to tie in with the existing key schedule as 80 x 2 instead of 80 x 1
- changes to key schedule to increase rounds directly
- something akin to internalising SHA-1(SHA-1(message))
- additional bit wise operations
Hopefully you get the idea. Why can't we do this so that it forms a plug in upgrade whereby the existing block size can be kept? My intention is to easily prolong the life of SHA-1 in existing code and data bases without huge and far reaching programmatic changes. I realise that 160 bits will someday become insecure requiring it's ultimate replacement by a wider hash.