Talk:One-way compression function: Difference between revisions

Content deleted Content added
Attack on Davies-Meyer: add title and sig.. sorry bout that :)
Line 6:
== Comparisons? ==
I'm curious if one of these methods is preferred to another in general, or under certain circumstances. Are there certain applications where one method is more appropriate than another? [[User:150.135.65.20|150.135.65.20]] 19:05, 30 January 2006 (UTC)
 
:Well, I am not a crypto analyst but my gutt feeling is that of the three methods described in the article so far the last one (Miyaguchi-Preneel) is the most secure.
:However, a slight modification of it might be twice as fast in some cases and perhaps about as secure. Many block cryptos today take keys twice the size of their block size, say 256-bit keys and 128-bit block size. So instead doing like in Davies-Meyer would be twice as fast. That is, to feed the messages blocks (m) as keys (256 bits at a time) and the previous hash (H) as cleartext to be encrypted. But you could still XOR in both m an H onto the output like in Miyaguchi-Preneel since that seems more robust then Davies-Meyer.
:But note that many cryptos only have 64-bit block size and with the methods so far described in the article thus only produces 64-bit hashes which is far to short to be secure for most needs. Also note that even 128-bit hashes (produced by 128-bit block cryptos) might be to short to be fully secure. Thankfully there is methods to make for instance 256-bit hashes out of block cryptos that has the block size of 128-bit. Two such methods are the MDC-2 and the MDC-4. We will probably add those methods to the article some day. (Much work to be done...)
:However if you can't wait until we added MDC-2 to the article you can read about it in the ''[http://www.cacr.math.uwaterloo.ca/hac/ Handbook of Applied Cryptography]''. You can follow that link to their web site and freely and legally download it as pdf-files! Chapter 9 tells all about hashes.
:--[[User:Davidgothberg|David Göthberg]] 10:07, 2 February 2006 (UTC)