Talk:One-way compression function

message: Ok, the merge of several other articles into this one is done, sort of. There is some more information in the old Davies-Meyer article about an attack that I did not merge since I did not understand it. If I just cut and paste that paragraph it will make even less sense since it depends on the notification established further up in the old article and I have changed that notification in this article. So for now I left the old Davies-Meyer article as it is (not turned it into a redirect). I left a note about it and link to it in the Davies-Meyer section of this article. I hope some one can make sense to it and rewrite it properly and merge it some day. --David Göthberg 06:05, 28 January 2006 (UTC)
replies: text: According to Bruce Schneier this "is not really worth worrying about"[4] He probably meant in practice, this is not worth worrying about. In the Eurocrypt 2005 paper with Kelsey, Schneier DOES use the fixpoint attack to show that the MD construction is far from being a random oracle, and so in a sense more brittle than one would wish it to be. However their attack is completely impractical because to be effective, it requires gigantic messages. 71.142.222.181 19:04, 9 March 2007 (UTC)
thread_title:  Attack on Davies-Meyer 

message: I took the liberty to revert to the first image. (The colourful one made by me but which really is only a slight extension of Matt_Crypto's old version.) Note that the other pictures on this page on purpose is colourmatched with this image (yellow boxes) to make it clearer where they fit in the Merkle-Damgård structure. I have tested the different images on the chatters in #crypto on irc.freenode.net and they prefered the colourful version. --David Göthberg 08:10, 6 March 2006 (UTC)
replies: text: Your version certainly looks nicer. I don't suppose you could tweak it to show the padding as in Mangojuice's diagram? — Matt Crypto 08:43, 6 March 2006 (UTC)
replies: text: Ok, since both of you seem to want it like that I'll give it a shot. I am also thinking of removing the pink balls around IV and HASH and only use text for them. I'll see how that looks. (Sorry Matt, but I think that might look better.) Oh, and I should mention that last week I read through the source code of about 10 different hash functions and discovered that most do not use a finalisation function. (Apart from doing the "100..." + length padding of course.) But since some use it I think I will keep the finalisation function box but mention in the text of the Merkle-Damgård article that only some hashes use a finalisation function. But I will still have the length padding fed to a separate compression function, since length padding within the last message block is just a speed optimisation that not all hashes use and that optimisation I think I explain well in the length padding example in the Merkle-Damgård article. --David Göthberg 10:18, 6 March 2006 (UTC)
thread_title:  Merkle-Damgård image 

message: "The resulting hash size is big enough. 64-bit is too small, 128-bit might be enough."
What does this mean? What are the criteria? If your 128-bit key is secure, shouldn't it require 2^64 operations to find even a collision? Why isn't that big enough? Or is there something being left unsaid about how secure the block based ciphers are?
--72.18.229.146 00:21, 29 August 2006 
:Because the most powerful computing systems available to some organisations nowadays probably can do about 264 operations. Thus a 128-bit hash might not be secure against such powerful adversaries. And in some cases you want your hash to be secure say at least 10 years into the future too. If you want to read more you can for instance read the Handbook of Applied Cryptography that we link to in the references. You can follow that link and freely and legally download the book as pdf-files. --David Göthberg 19:46, 10 June 2007 (UTC)
thread_title:  Might be enough to write like an encyclopedia 

message: I see a function E() in the equations, but I can't figure out from the context what this function is.  Could someone fill it in more completely? User:mbset 13:50, 9 June 2007
:E() is the encrypt function of the block cipher used. So E_{m}{(H)} means to encrypt the data "H" and use the key "m". --David Göthberg 19:46, 10 June 2007 (UTC)
thread_title:  What is E? 

message: I moved this article from Hash functions based on block ciphers to One-way compression function since that is what this article really is about. The Merkle-Damgård hash function article takes care of the rest of the description of how compression functions are used to build hashes. --David Göthberg 04:52, 26 July 2007 (UTC)
thread_title:  Article move 

message: What in the world does this statement mean?  It makes the entire article rather confusing.  Do we mean "If the block cipher is ideal"?  I'm not even sure that statement holds w.r.t. all of these constructions.  This needs to be fixed, removed, elaborated on.  Any suggestions?
: I've made some small changes. Not sure if the black box model and the ideal cipher model are exactly the same. Similar to the random oracle model there exist some (contrieved?) constructions that are secure in the ideal cipher model, but not secure with any instantiation of a block cipher, hence showing that the "ideal cipher world = real world" assumption cannot be made in general. 85.2.78.238 (talk) 08:10, 19 November 2007 (UTC)
replies: text: I'm not yet satisfied with my changes, but are looking for some specific references. In particular, in order to get a secure hash function the block cipher needs some properties that would not be necessary to just make encryption secure. 85.2.78.238 (talk) 08:46, 19 November 2007 (UTC)
thread_title:  If "the block cipher is secure" 

message: Might be useful to note that block ciphers with expensive key setup (e.g. Twofish) do not interact well with any of these constructions because the key setup must be done once for every message block. Aragorn2 (talk) 11:31, 12 June 2019 (UTC)
thread_title:  Ciphers with Expensive Key Setup