Talk:Merkle–Damgård construction

message: Aren't points 1 and 3 equivalent or a subset/superset of the other? 87.254.83.229 (talk) 03:36, 23 December 2008 (UTC)
replies: text: No, but the distinction isn't clear in the article. Length extension depends on the colliding sets of messages having the same prefix, whereas multicollision attacks can find multiple collisions for messages of the same length. --David-Sarah Hopwood ⚥ (talk) 15:32, 11 October 2009 (UTC)
thread_title:  Security Characteristics 

message: Since I am not in the mood and currently don't have the time to edit the article itself, here goes:
I disagree with parts of the content in the new "Wide pipe construction" section in this article:
* The section currently states that "Stefan Lucks proposed the use of the wide-pipe hash" and links to a paper from 2004. However, the idea of using a larger internal state in the Merkle-Damgård construction for added security has been well known for decades. And some of the well known hash algorithms designed in the 1980's and 1990's do use a larger internal state. So I think Stefan Lucks' name should be removed. (He graduated in 1992 so I doubt he influenced hash designs in the 1980's.)
* Such compressing of a larger internal state to a smaller final output state is also mentioned in the Handbook of Applied Cryptography in chapter 9. That book was written in 2001. And it is part of the graphs used to describe the Merkle-Damgård construction in that book and other cryptography books. 
* I disagree with wording such as "instead of Merkle–Damgård construction", since the wide-pipe construction still is the Merkle-Damgård construction. It is just a small extension that usually is shown together with the Merkle-Damgård construction in most books and graphs.
* Even before the "wide-pipe" section was added to this article the image used in this article already showed the "finalisation function" (the green box in the image) and the first section already described it: 
::To harden the hash further the last result is then sometimes fed through a finalisation function. The finalisation function can have several purposes such as compressing a bigger internal state (the last result) into a smaller output hash size or to guarantee a better mixing and avalanche effect on the bits in the hash sum. The finalisation function is often built by using the compression function. (Note that in some documents instead the act of length padding is called "finalisation".)
''
* The wide-pipe section also says: "Therefore, in final step a second compression function compresses the last internal hash value to the final hash value." I disagree with the wording "a second compression function" since usually it is the same compression function that is used to do the finalisation, and then simply parts of its output is discarded to get the shorter output. The reason that the same compression function is used is that otherwise the hash function would use about twice the amount of code.
* And a minor note: The "Fast wide pipe construction" section mentions that "Widepipe hash function can be made approximately twice faster". However, if the same one-way compression function is used that method only makes the hashing 50% faster. And it makes the hashing less secure than using full wide-pipe.
--David Göthberg (talk) 07:24, 24 July 2011 (UTC)
thread_title:  Wide-pipe construction 

message: Though having a basic familiarity with hash functions, I went to Wikipedia to brush up on the Merkle-Damgard construction.  Two aspects of the current diagram 
(which also appears in the article on cryptographic hash functions) at first confused me.  The n'th message block is depicted as the same length as all the others, when in fact it is usually shorter; and the two upper rows, with arrows going e.g. from block 1 to block 1 below, made me think some processing of contents was happening, rather than a no-op.  Though lacking the nice colors, the former diagram 
 
is free of the first of these confusing features, and in addition nicely indicates the compression of the data by using trapezoids to represent the compression function.  The present figure is visually nicer, and available in different resolutions, so the best thing would be to redraw it to 1) eliminate the top row, 2) represent message block n by a visibly shorter rectangle, and 3) use trapezoids to indicate compression.  I would try to draw this myself, but lack the necessary skills.
If someone undertakes revision of the drawing to incorporate some or all of these suggestions, here's another thing to consider.  The construction of the padding is a rather subtle matter, depending on the length of the whole message, not just the last block. The fact that the padding depends on all the preceding blocks might be indicated graphically, e.g. by a large horizontally oriented brace symbol "}" at the top, spanning all n original message blocks, with a arrow labeled "MD-compliant padding" extending from the brace to the padding that extends the last block to the same length as the others. But this may be more trouble than it's worth, because the text example explains it so well, and my suggested drawing would not capture cases where the original last block is only slightly too short, causing the padding to overflow into an n+1'st block.CharlesHBennett (talk) 14:43, 15 September 2015 (UTC)
replies: text: two years passed, nothing happened. i support that change, i find the image incorrect too. but i suggest further tweaks, because it *is* possible that you need one more block. it could be marked as optional on the picture. Krisztián Pintér (talk) 21:31, 3 August 2017 (UTC)
thread_title:  Confusing aspects of the diagram, and suggested improvements 

message: Not long ago there was a flurry of methods for producing collisions in MD5 (and others), a once popular hash function that uses the MD construction. These were perfected to the point that a modest laptop took only some minutes to find instances of colliding messages, and led to the mandatory deprecation of MD5 for, basically, all new applications. Now, IIRC, these methods all worked by finding 2 pairs of consecutive message blocks (say, A:B and A':B') such that any differences between the intermediate hash values after blocks A and A' were nullified after blocks B and B', respectively. That is, roughly, one had H(A:B)==H(A':B') even though H(A)!=H(A'), meaning, this method found collisions in the full hash function without giving any hint of an instance of a collision for the compression function. Doesn't this conflict with what is claimed in Merkle's thesis, namely, that a secure compression function plus the MD construction generates a secure hash? As far as i see it, the only way to reconcile these 2 facts is to admit that MD5's compression function has thus been proven to be insecure, even though nobody knows of a single instance of compression-function collision, nor any way to obtain it that is better than the birthday attack (which must work against all functions). Or am i misunderstanding something here?  — Preceding unsigned comment added by 89.180.144.158 (talk) 21:02, 1 February 2017 (UTC)
replies: text: (Same girl as above, despite different IP.) Well, after having had a chance to go through the wonderful (but in dire need of extensive copy-editing) lecture notes by Goldwasser&Bellare, referenced in this article, i've realised that the source of the contradiction was my misunderstanding that the final XOR operation after every application of the compression function is part of the compression function. Probably influenced from wherever i first learned about the structure of MD5 and similar hashes, i was under the impression that 'compression function' referred only to the (actually reversible, at least in MD5's case) function that computes, from the current hash value and message block, the 'XOR-difference', if you will, to be applied to the current hash value to generate the next one. I thought that this final XOR was part of, and actually mandated by, the Merkle-Damgard construction. So: Nevermind.  — Preceding unsigned comment added by 81.193.5.173 (talk) 13:17, 13 February 2017 (UTC)
thread_title:  Apparent Contradiction 

message: After reading the CWI site referenced in the paragraph about the Nostradamus, or 'herding' attack, i decided to change said paragraph because the previous version (which alluded to 'committing to an output h') might mislead the reader into thinking that significant progress had been made in finding preimages for MD5, as 'output' usually refers to the final result of the hash calculation. I believe the altered version to be both significantly more descriptive and more correct.  — Preceding unsigned comment added by 89.180.151.104 (talk) 21:53, 1 February 2017 (UTC)
thread_title:  Nostradamus 

message: The first source has a broken link 46.114.111.156 (talk) 07:49, 23 February 2022 (UTC)
thread_title:  Broken source