[Geek] Updating message digest tools
Oct. 16th, 2004 12:55 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
doc_strange...which is to say, file integrity checking tools.
A couple of my LJ friends have commented on the recent intentional-collision-finding attacks published on SHA0 and the strong indication that SHA1 is also vulnerable. Because of those publications, and similar issues with several other message digest algorithms including MD5(warning: PDF file), I've overhauled a number of the tools I and my usual cronies use. For the moment, I'm going with RIPEMD-160. RIPEMD-160 is, for the moment, not claimed as vulnerable to collision-finding attacks, since a published attack on a weakened variant of RIPEMD in 1995 is what led to the creation of RIPEMD-160. However, it's similar to SHA1, and so, it's probably just a matter of time.
The RIPEMD-160 primitives, I have to say, were SO FRICKING easy to integrate into programs already using MD5 or SHA1, that it took less than an hour to do, validate, and repackage them all. (Ok, and then a few hours to trim all the various buffers back down to the sizes they really need to be after testing my prototypes with buffer bloat and then reading lots of man pages to get the real size of all the items. Ahem. [me<--Not a professional programmer])
I certainly hope RIPEMD-160 lasts for more than a year as a viable integrity hash, but it's probably the next target of the academic crypto community, so here's hoping it really got improved in 1996. That said, it's a matter now of waiting for the AES-based hashes to make their way into clean, portable C primitives. The reference code's out there, but not the usual easy-to-import {cipher}Init, {cipher}Update, {cipher}Final, {cipher}End, and {cipher}Transform. And no way am I programmer/mathematician/cryptographer enough to even think about creating them from reference code.
A couple of my LJ friends have commented on the recent intentional-collision-finding attacks published on SHA0 and the strong indication that SHA1 is also vulnerable. Because of those publications, and similar issues with several other message digest algorithms including MD5(warning: PDF file), I've overhauled a number of the tools I and my usual cronies use. For the moment, I'm going with RIPEMD-160. RIPEMD-160 is, for the moment, not claimed as vulnerable to collision-finding attacks, since a published attack on a weakened variant of RIPEMD in 1995 is what led to the creation of RIPEMD-160. However, it's similar to SHA1, and so, it's probably just a matter of time.
The RIPEMD-160 primitives, I have to say, were SO FRICKING easy to integrate into programs already using MD5 or SHA1, that it took less than an hour to do, validate, and repackage them all. (Ok, and then a few hours to trim all the various buffers back down to the sizes they really need to be after testing my prototypes with buffer bloat and then reading lots of man pages to get the real size of all the items. Ahem. [me<--Not a professional programmer])
I certainly hope RIPEMD-160 lasts for more than a year as a viable integrity hash, but it's probably the next target of the academic crypto community, so here's hoping it really got improved in 1996. That said, it's a matter now of waiting for the AES-based hashes to make their way into clean, portable C primitives. The reference code's out there, but not the usual easy-to-import {cipher}Init, {cipher}Update, {cipher}Final, {cipher}End, and {cipher}Transform. And no way am I programmer/mathematician/cryptographer enough to even think about creating them from reference code.
