Talk:Cryptographic hash function

message: This page should be redirected to Message digest which is the established term of art in the field since the 80s. In the early days, no distinction was made between message digests and hash functions. And then the same name was used for both. Then someone brought a stupid lawsuit claiming that the use of a message digest as a hash violated their patent. I suspect the page was redirected from Message Digest during that dispute.  — Preceding unsigned comment added by 96.237.138.82 (talk) 21:58, 7 January 2020 (UTC)
thread_title:  The field has chosen the term Message digest 

message: The way this article describes second pre-image resistance and collision resistance they seem like the exact same thing. Am I missing somethimg big here or is this just poorly explained??? 98.213.119.182 (talk) 09:04, 17 May 2015 (UTC)
replies: text: See Preimage attack for an explaination of the difference.--agr (talk) 12:55, 17 May 2015 (UTC)
thread_title:  Confused???? 

message: Two editors (one anon) have argued that the last four words should be removed.  I'm really against this; to my eyes, it's a vitally important caveat.  Without that caveat, we would be able to define precisely what it meant for the attacker to learn nothing about the message.  As it is, they definitely learn at least one thing: the digest of the message is x.  This seemingly trivial fact completely frustrates any effort to come to a more precise definition of what it means for the attacker not to learn anything about the message.  It's an absolutely vital difference.
I won't revert it a third time if it's removed again, but I'd really like to discuss it here first if possible.  Thanks.  — ciphergoth 08:30, 24 October 2005 (UTC)
replies: text: I agree with your revert and edits ciphergoth. It is a vital difference since in some cases knowing the digest itself can make a difference. (I have worked professionally with crypto protocol design and teached it at universities.) --David Göthberg 11:13, 24 October 2005 (UTC)
thread_title: nor should an [[adversary|attacker]] learn anything useful about a message given only its digest besides the digest itself

message: According to the MD5 article it is not collision resistance so the table should be modified.
Are their any objections to this?
Lambedan (talk) 23:16, 2 April 2009 (UTC)
replies: text: The entries in the table are OK. MD5 is not collision resistant, but so far no attack against preimage resistance is published. However, the titles of the colums are ambiguous. The column "Collision resistance" really means "Is there are any known attacks against collision resistance?". The column "Preimage resistance" means equally "Are there any known attacks against preimage resistance?". Maybe the titles should be made more clear. 81.62.21.174 (talk) 07:43, 3 April 2009 (UTC)
replies: text:  The entry for MD2 has a blank in the preimage column though the MD2 article describes a preimage attack? If I knew more about Cryptography I'd be tempted to ammend this myself; can an expert check this please  —Preceding unsigned comment added by 83.104.81.210 (talk) 09:56, 28 May 2009 (UTC)
thread_title:  Preimage resistance 

message: User:C4chandu removed the discussion of preimage resistance from the statement of what the hash function is supposed to be able to do.  Why?  If anything, we should be extending that section to add second preimage resistance as well. — ciphergoth 08:30, 24 October 2005 (UTC)
thread_title:  Preimage resistance 

message: On March 27 I removed about a dozen of links from Wikipedia like this one from WHIRLPOOL:
:Jacksum — by Dipl.-Inf. (FH) Johann N. Löfflmann in Java. Various message verification functions, including all three revisions of WHIRLPOOL. Released under the GPL.
, the author of Jacksum has in most cases restored these links; see his contributions.  I would be interested to know what other Wikipedia editors feel about this dispute.  There is some discussion of this on his Talk page My own feelings follow.
* Omit the links - I do not think it is appropriate to pepper Wikipedia with links to your software so even when it is open source.  — ciphergoth 19:47, 30 March 2006 (UTC)
thread_title:  Jacksum 

message: We need a column for effective size to give an indication of each algorithm's quality. For instance, a perfect 128-bit hash would take 2^64 operations to find a collision. Because e.g. SHA-1 takes 2^63 operations to find a collision, its effective size would be 126 bits. Otherwise, the reader has to visit each article one-by-one in order to get an idea of how cryptographically broken each algorithm is. --Damian Yerrick (☎) 02:40, 3 June 2006 (UTC)
replies: text: I think such a summary would be more misleading than useful.  My experience with eSTREAM has been that it's best to discuss security status on the page for the relevant primitive, where you have the space to do it properly. — ciphergoth 08:56, 3 June 2006 (UTC)
thread_title:  Effective size? 

message: Wouldn't a good property of a hash function be the ability to show, given a string X, that only a string of its length (or a string that's an anagram of that one, or which starts with the same character of as that one, or something) could result in the hash it results in without revealing the string itself (like revealing that the MD5 hash 6cd3556deb0da54bca060b4c39479839 must belong to a string 13 characters long)? --Ihope127 00:57, 4 July 2006 (UTC)
thread_title:  Revealing properties? 

message: There is no underlying theoretical discussion included in the article. Many claim it is not possible at all to design a perfectly collision-free and one-way hash method , so all hash algorythms are futile for security use. I think this is related to P <-->NP problem. 195.70.48.242 20:36, 5 December 2006 (UTC)
replies: text: Actually, I'd say the article does a reasonable job of expressing the theoretical basics.  If you want more, you can read up on random oracles or go to the Handbook of Applied Cryptography.  "Perfectly collision-free" is meaningless with respect to hash functions (consider a hash with 128-bit output.  Feed it all 256-bit strings, and each will have an average of 2^128 collisions, even if it's a true random oracle.)  P<->NP is irrelevant.  And "futile for security use" doesn't really make sense either -- almost all cryptography is based on well-tested assumptions about what's hard and what's not.  That said, there is lots of work to be done in strengthening our definition and implementation of cryptographic hashes, and that work is being aggressively undertaken now that sha1 and md5 are creaking ominously.  Lunkwill 19:46, 7 December 2006 (UTC)
thread_title:  Are hash methods theoretically viable? 

message: NIST has been having some workshops on cryptographic hashes.  There have been a few ideas for new hash functions submitted; three have web pages and reference code: LASH, RadioGatún, and EDON-C/EDON-R (scroll down and look for "Two infinite classes of cryptographic hash functions").  Samboy 05:29, 21 December 2006 (UTC)
thread_title:  NIST has been having some workshops on cryptographic hashes 

message: I reverted the 2007 March 18 modification to collision resistance.
The attacker is free to choose both m1 and m2. He need not be confined to an m1 fixed by others .
NormHardy 00:21, 20 July 2007 (UTC)
thread_title:  Definition of collision resistance 

message: Some days ago User:Jafet.vixle changed the image used in the article. I disagree with the change. 
I think Jafet's image is much harder to understand for beginners. Among other things it does not show generic terms such as "hash function" and "hash sum", instead it uses the name of an arbitrarily chosen hash function "Whirlpool". And it doesn't show the process, that is that input is fed to the hash function that then produces the hash sum.
--David Göthberg 16:26, 21 August 2007 (UTC)
replies: text: I agree. The older picture is preferable. 169.231.5.121 07:22, 22 August 2007 (UTC)
replies: text: Since no one else said anything I switched back to my image in the article. --David Göthberg 15:15, 26 August 2007 (UTC)

text: Since the quotes the 'input' as the 'message', change the label to 'input message'.  — Preceding unsigned comment added by 82.31.143.204 (talk) 20:37, 30 October 2012 (UTC)
thread_title:  Image choise 

message: Can someone knowledgeable please clarify the units used in the "List of cryptographic hash functions" section?  For instance, does SHA-1 output 160 bits or 160 bytes?  —Preceding unsigned comment added by 196.7.19.250 (talk) 15:44, 26 October 2007 (UTC)
thread_title:  Clarification required 

message: Why does Category:CISSP apply here? Just because hash functions are related to Internet security and knowledge of them is needed for taking that test? There's a lot of software protocols that rely on hash functions, courses that teach hash functions, books that mention them -- do we link those as well? I'm not convinced that people reading the hash function page will find value in that category. Mentioning hash functions as being part of the CISSP test, on the CISSP page, might be more appropriate. NoDepositNoReturn (talk) 18:25, 29 June 2008 (UTC)
thread_title:  CISSP? 

message: The article is wrong about why Debian Packages files contain multiple hashes. Apt only checks the strongest hash that it knows how to deal with. For current apt, this is the SHA256 hash. For older apts, it is the SHA1 or MD5SUM. Weaker hashes are ignored. The weaker hashes are left in the files so that older versions of apt can still verify the files during upgrades.
Proof: Line 1324 of acquire-item.cc in apt's source. ExpectedHash is set to only the strongest hash found.  —Preceding unsigned comment added by 67.223.5.142 (talk) 19:39, 31 December 2008 (UTC)
thread_title:  Incorrect re Debian and concacenated hashes 

message: There are no current WP articles about the so-called "info hash", which is used with torrents.  
The passing mention in BitTorrent protocol encryption seems to be the only current content.
If you understand this subject, please add the term to this article, in proper context.
"The info hash is strictly for the bittorrent client. The BT Client you use uses the info hash to make sure that what you are downloading is legit from the server's point of view. You don't do anything with it."
-96.237.7.209 (talk) 13:59, 18 January 2009 (UTC)
thread_title:  info hash - infohash 

message: * Randomized hashing is just a fancy name for signers putting a random number in the content to be hashed for a digital signature, more or less.  But it would have made the 2008 SSL cert hack impossible, because the attackers wouldn't be able choose exactly what content would be signed, and it's seemingly caught the attention of NIST because it could make signatures more resilient against algorithm breaks.  (To replicate the 2008 MD5 crack with randomized hashing, attackers would need either a preimage attack or a collision attack that works even when part of the hash input is unknown.)  The researchers who did the 2008 crack suggested something similar -- ensure the cert serial number is random.
* The 2008 MD5 SSL cert break drives home that hash functions matter; seems like it deserves some mention here.  You don't know what you got 'till it's gone; you don't think about plumbing until it breaks; and we all don't appreciate hash functions until some researchers break the Internet because we're not using good ones. :)
It would be fun, if hopelessly pedantic, to flag exactly which uses require hash functions to be merely pretty-random-looking (e.g. integrity checks), preimage resistant, collision resistant, pseudorandom, or based on strong block ciphers.
Notes to self, but if anyone wants to pick this up I'm tickled.
67.119.195.43 (talk) 04:53, 2 February 2009 (UTC)
thread_title:  Randomized hashing, 2008 MD5 SSL cert break 

message: I disagree with the following claim in the text:
:Concatening outputs from multiple hash functions provides security at least as good as the strongest of the algorithms included in the concatenated result.
This may be true for collision resistance, but is incorrect with regard to preimage resistance. E.g. if one hash function is SHA-1 and the other function is just the identity function then it is trivial to find x from SHA-1(x) || x. The potential one-wayness of SHA-1 doesn't help to protect x here at all. After all, preimage resistance is a requirement for a secure hash function. 85.0.14.230 (talk) 08:46, 2 February 2009 (UTC)
replies: text: I believe you're right, the text needs to clearly source this claim and specify which types of attacks it's true for; it's clear per your example that a preimage attack on a concatenation of hashes need only examine the weakest of them, and may in fact be able to do even better. Dcoetzee 10:34, 2 February 2009 (UTC)

text: I agree that the statement only holds for collision resistance.  Proof of security of concatenated hashes http://eprint.iacr.org/2008/075.  Also, it won't provide security "at least as good" but "at most."  I'm going to attempt some cleanup on this one but suspect it'll take multiple iterations to fully correct it.Quelrod (talk) 19:01, 31 July 2010 (UTC)

text: this statement holds for collision resistance and second pre-image resistance. The citation suggested above (http://eprint.iacr.org/2008/075), however, deals with a different issue. The correct citation imho is my paper, which is also much earlier but here in the journal version: Herzberg, Amir. "Folklore, practice and theory of robust combiners." Journal of Computer Security 17.2 (2009): 159-189.  — Preceding unsigned comment added by Amirhe (talk • contribs) 21:32, 29 August 2018 (UTC)
thread_title:  Concatenation of hash functions 

message: # it is infeasible to modify a message without changing its hash,
# it is infeasible to find two different messages with the same hash.
aren't they the same thing? Twipley (talk) 22:59, 22 July 2009 (UTC)
replies: text: WP:NOTAFORUM, but finding an attack that violates the first item is called a "pre-image" attack; finding an attack that violates the second item is a "collision" attack.  Collision attacks are easier to find; MD5 is vulnerable to collision attacks (finding two different messages with the same MD5 value) but there is no known pre-image attack against MD5--no one has figured out how to make a file with the MD5 sum 0102030405060708090a0b0c0d0e0f for example. Samboy (talk) 16:41, 10 November 2009 (UTC)
thread_title:  two same things 

message: What is meant by the notation "with flaws" in the table at the end of this article?  I think it means that someone once thought they had a successful attack on the scheme, but they were wrong: their attack does not work.  A non-working attack is not an attack at all.  If I'm understanding correctly, it is highly misleading to include any "with flaws" figures in that table: they should be deleted.  —Preceding unsigned comment added by 128.32.153.194 (talk) 00:34, 6 March 2010 (UTC)
thread_title:  "with flaws" 

message: I'm curious if there is some way to either split a few pages or some method to keep pages with the same content up to date. For instance there is at least: 
Cryptographic_hash_function
Comparison_of_cryptographic_hash_functions
Hash_function_security_summary
They aren't always all in sync with each other and that's not to mention the pages for each hash function. Thoughts?
Quelrod (talk) 19:34, 31 July 2010 (UTC)
thread_title:  Keeping the latest attacks in sync 

message: I'm going to remove the 'binary hashing method' proposed by Daymon Schroeder from this page.
This is an unpublished hash function. It is poorly designed and collisions are almost trivial to find.
E.g. the two strings
"10608939The quick brown fox jumps over the lazy dog" and "10308969The quick brown fox jumps over the lazy dog" both have the
same hash of length 32 "+!Yguf*aNV!P#Hiw*{*[#~*;1NfL+!%%".
I've verified the hash on the web page of the author.  —Preceding unsigned comment added by 85.1.57.131 (talk) 10:25, 28 December 2010 (UTC)
replies: text: Please do not remove comments. If you don't agree with the comment an think BHM should be listed here then write a reply. I.e. the code provided for BHM is of poor quality and not all implementations give the same results. This may be due to rounding errors, since the hash function uses floating point arithmetic. If you think the example above is not a collision, then specify what you would consider a reference implementation. In any case there are alternative strings that seem to give collisions: I.e. take any string longer than the length of the hash and permute the characters at the end. E.g. 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx12' and  'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx21' give the same hash of size 32 with the python implementation. 83.78.157.215 (talk) 10:28, 29 December 2010 (UTC)
thread_title:  Binary hashing method 

message: The present alice-bob illustration appears flawed. For example consider the following scenario: alice creates and stores a meaningless string Call A, sends hash(A) to Bob (under the pretense of the example).
When Bob comes to claim he has achieved the solution Alice simple reveals her nonce as whatever she wants (W) - A. Bob will then (incorrectly) verify Alice had W all along. In this context the hash is useless, Alice is not committed to anything by revealing her hash.
In the context of the example the implications are unclear as it depends on if bob reveals the solution first or not. However we must assume he does not reveal the number before Alice as if he does Alice simply takes W as the solution. Hence the whole nonce and reveal is miss-leading e.g. there is no point at with to reveal it or at least it must be revealed when Bob wants it therefore may as well be excluded.
This could be fixed by by requiring Alice to divulge the hash of the nonce as well as of the sum of the nonce and solution.  — Preceding unsigned comment added by 155.198.75.173 (talk) 14:36, 2 June 2011 (UTC)
thread_title:  Illustration flaw 

message: The hash function table is missing a link to the collision attack against Haval. Perhaps more importantly, it misinterprets the reference to an alleged collision attack against Whirlpool: what is achieved in the paper by Lamberger et al. is a *distinguisher* against Whirlpool, based on a *near-collision* against the underlying *compression function*. It only means one can tell a Whirlpool digest from a random 512-bit string with an effort of 2176 steps (checking the documentation of the system using the hash is likely to yield the same result much faster). This is entirely different from stating that there is a collision attack against the *hash function* itself; the authors of http://www.springerlink.com/content/9711452444u24861/ neither do it nor claim they can do it, contrary to what is claimed on the table in this article as it is currently written.  — Preceding unsigned comment added by 189.38.230.167 (talk) 01:20, 9 December 2011 (UTC)
thread_title:  Meaning of collision attacks 

message: In the table, it says that no variant of RIPEMD has collisions. Yet in the RIPEMD article, there is a reference citing a paper that lists an explicit collision (not sure if it's an old RIPEMD 128 or the new one). And in Comparison of cryptographic hash functions#Cryptanalysis there are collisions cited for RIPEMD 160. Therefore, it's misleading to say that they have no collisions. and obviously the table should be fixed. Since the collisions affect the 128 and the 160 bits versions, how should this be handled? Split into 4 entries? Or merge the ones without collisions together (i.e. 256/320) in one entry? --pgimeno (talk) 23:57, 22 April 2012 (UTC)
replies: text: RIPEMD clearly states that "collision was reported for the original RIPEMD". this is the same collision that appears in the tables in Comparison of cryptographic hash functions#Cryptanalysis and in this article. the entry for RIPEMD-160 is for a reduced-round version with only 48 rounds. since the table in this article only contains attacks against the full-round algorithms, the table is correct and does not need to be modified. --MarioS (talk) 14:07, 23 April 2012 (UTC)
replies: text: My bad, you're right. Apologies. --pgimeno (talk) 19:43, 24 April 2012 (UTC)
thread_title:  RIPEMD table entry wrong 

message: I'm kind of confused... This is my understanding of hashing:
*the computer randomly comes up with a key
*when someone types in a message to be encrypted, it is changed with the key.
**It could just store the stuff in the database, but that would allow a site owner to see a password or something. So, it has to hash it.
*on the other side, the info is un-hashed with that random key. there even the site owner does not know, and it stays private.
Am I right?  — Preceding unsigned comment added by 96.5.166.66 (talk) 20:57, 23 April 2012 (UTC)
thread_title:  wait, what? 

message: This first sentence of this article seems to be an incomplete sentence. The sentence just doesn't make much sense.
:A cryptographic hash function is a hash function, that is, an algorithm that takes an arbitrary block of data and returns a fixed-size bit string, the (cryptographic) hash value, such that an (accidental or intentional) change to the data will (with very high probability) change the hash value.
Khatchad (talk) 21:59, 14 September 2012 (UTC)
thread_title:  First sentence incomplete? 

message: * Can SipHash be added to the list of cryptographic hash function ? it's 64bit output might not fit against other heavy hash function, but SipHash was defined with cryptographic requirement.  — Preceding unsigned comment added by Ydroneaud (talk • contribs) 09:55, 14 December 2012 (UTC)
thread_title:  Other hash functions 

message: The statement that " WEP encryption standard, but an attack was readily discovered which exploited the linearity of the checksum" should have a link on linearity to what meaning of linearity is intended. RJFJR (talk) 18:45, 22 July 2013 (UTC)
thread_title:  Link 

message: Here is what this article gives as the definition of "Pre-image resistance": 
Given a hash h it should be difficult to find any message m such that h = hash(m). This concept is related to that of one-way function. Functions that lack this property are vulnerable to preimage attacks.
As stated, no hash function could be pre-image resistant. Here is a hash h that is very easy to find a pre-image for: h(0^n). What is implied, of course, is something different, namely that for a random hash h it should be difficult to find any message m such that h = hash(m). 
The Wikipedia article on "Preimage attack" gives a better definition: "for essentially all pre-specified outputs, it is computationally infeasible to find any input which hashes to that output, i.e., to find any preimage x given a "y" such that h(x) = y." 
I suggest we use this formulation rather than the "Given a hash h" one.
Snapdragon630 (talk) 02:34, 16 October 2014 (UTC)
thread_title:  Definition of "Pre-image resistance" 

message: I think we can add an extra application of hash functions as used in proof-of-work system such as hashcash. Manoguru (talk) 13:25, 25 January 2015 (UTC)
thread_title:  As proof-of-work

message: I don't know much about this stuff, but it seems to me that a cryptographic hash function is a hash function that is also a trapdoor function. There may be subtleties that make them not exactly the same, but I suggest mention and link should  be made to this connection with trapdoor functions on the introduction to this article.2601:681:4902:31B8:95CC:E49C:E8F:3502 (talk) 03:31, 4 September 2015 (UTC)
thread_title:  trapdoor hash function 

message: The current definition reads: "A cryptographic hash function is a hash function which is considered practically impossible to invert, that is, to recreate the input data from its hash value alone." However, for example, on the MD5 Wiki page, we say that "the MD5 message-digest algorithm is a widely used cryptographic hash function," even though "a collision attack exists that can find collisions within seconds". This raises the question: is this definition suitable in a world where hash functions are DESIGNED to have the "one-way hashing" quality even though later on it loses that quality?
I propose the following new definition:
"A cryptographic hash function is a hash function which is designed to be practically impossible to invert, that is, to recreate the input data from its hash value alone."
I also suggest that we add a sentence or a paragraph explaining the fact that not all "cryptographic hash functions" are in fact secure, due to the fact that circumstances sometimes change in a way that causes the "one-way" aspect of the algorithm to no longer be true.  — Preceding unsigned comment added by 54.240.196.170 (talk) 16:20, 22 October 2015 (UTC)
thread_title:  Ambiguous Definition 

message: The introduction says that an ideal cryptographic hash should be quick to compute. This is actually wrong in one primary application of crypto hashes, which is password/authentication systems. In such systems, the number of hashes to compute is relatively low (once per login, roughly), so it's OK for the hash function to take a long time. However, a brute-force password attacker needs to try every possible hash combination to crack passwords, and this attacker greatly benefits from having a fast hash function versus a slow hash function. 165.134.12.132 (talk) 17:10, 21 September 2016 (UTC)
replies: text: i don't think it is wrong. a general purpose hash function, which the article is about, must be fast, because there are use cases in which performance matters. if we have fast hash functions, it is possible to make high cost special purpose kdfs based on them. so we actually don't need high cost primitives. cost can always be added later. if you look at any high cost scheme, there is a high performance primitive inside. Krisztián Pintér (talk) 22:06, 21 September 2016 (UTC)

text: this is still wrong, here is a reference for clarification: https://www.youtube.com/watch?v=GT_qgImaUS4#t=10m15s - watch until 10m40 - a good hash function should be designed to be sufficiently complex that it cannot be computed quickly. It's not a matter of making it slower later, as someone could just re-implement it efficiently, e.g. in generating a rainbow table.  — Preceding unsigned comment added by 129.234.103.198 (talk) 19:19, 10 October 2017 (UTC)
thread_title:  Incorrect intro 

message: It looks like a successful collision attack against SHA-1 has been run, so this article probably needs an update to the line "Though theoretical weaknesses of SHA-1 exist,[14][15] no collision (or near-collision) has yet been found."
68.116.67.198 (talk) 17:51, 24 February 2017 (UTC)
thread_title:  SHA-1 Collision Attack 

message: Hello fellow Wikipedians,
I have just modified 2 external links on Cryptographic hash function. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
*Added archive https://archive.is/20121208212741/http://wiki.crypto.rub.de/Buch/movies.php to http://wiki.crypto.rub.de/Buch/movies.php
*Added archive https://archive.is/20121206020054/http://www.guardtime.com/educational-series-on-hashes/ to http://www.guardtime.com/educational-series-on-hashes/
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
Cheers.—InternetArchiveBot (Report bug) 02:39, 15 August 2017 (UTC)
thread_title:  External links modified 

message: This article uses the term "one-way function" to mean "a function which is infeasible to invert." This is problematic as the criteria for infeasible, aka intractable, problems are not well-defined while one-way functions have a specific mathematical definition. Furthermore, going by the formal definition of one-way function, it is unknown whether any such functions even exist. It would seem prudent to mention somewhere in the article that when we are referring to one-way functions, we are doing so in an informal manner inconsistent with the precise meaning of the term. Jwuthe2 (talk) 05:40, 12 January 2018 (UTC)
thread_title:  One-way Function 

message: "Collision resistance implies second pre-image resistance, but does not imply pre-image resistance."
According to the provided source collision resistance implies pre-image resistance up to an advantage for the adversary of 2 where n is the hash length and m is the domain size.
Since m is often much larger than n (m >> n) the advantage of the adversary maybe,in many cases, neglectible and the above statement false. Example: domain size is 2n and hash length is n. Advantage is 
1/2.  Dave4422 (talk) 14:17, 31 January 2018 (UTC)
thread_title:  False statement in Properties 

message: Just perfect. 
 --84.118.82.226 (talk) 12:12, 16 April 2018 (UTC)
thread_title:  h(x) := MD5(x) + MD5(x+x) with '+' in the sense of [[concatenation]] 

message: There seems to be a general misconception that the notion of "infeasible" in cryptography is the same as (or related to) the notion of "intractable" from complexity theory.  (The two were linked in the article.)  That is not the case.  Complexity theory looks only at the asymptotic behavior of the cost of computing a function as the size of the input goes to infinity.  When inverting a cryptographic hash function like SHA or MD5, the input has fixed size.  When this is the case, complexity theory says that the problem is trivial, and can be solved in O(1) time.In fact, complexity theory has nothing at all to contribute to practical cryptography.  It cannot prove that functions are practically infeasible to invert.  It cannot even prove that SHA is harder to invert than the function "take the first 256 bits of the message".In fact (as far as I know) there is no mathematical proof that any function is a one-way function.  Cruptographic hash functions are "proved" to be robust only "empirically", by resisting attacks by the most clever cryptographers for decades.--Jorge Stolfi (talk) 06:42, 1 June 2019 (UTC)
thread_title:  Practical infeasibility has NOTHING to do with intractability of complexity theory 

message: Why  to put alongside the three required properties (to quote your source: "The basic (classical) properties a hash function is expected to preserve are: collision resistance, pre-image resistance and 2nd pre-image resistance").  Why stop there and not include, alongside it in the lead,  the five other "desirable properties that hash functions should preferably preserve" listed by your source?  And yes, "statistical correlation" is ill-defined in the context.  Correlation of individual input bits to output bits?  Correlation of input texts with output values?  The source does not define this, does not expand on the statement, nor does it provide a reference.  —Quondum 23:58, 3 July 2019 (UTC)
thread_title:  Let's keep it balanced 

message: We have a couple of paragraphs on the use of cryptographic hashes in hash tables (from this edit ):
One of the main applications of a hash function is to allow the fast look-up of a data in a hash table. Being hash functions of a particular kind, cryptographic hash functions lend themselves well to this application too.
However, compared with standard hash functions, cryptographic hash functions tend to be much more expensive computationally. For this reason, they tend to be used in contexts where it is necessary for users to protect themselves against the possibility of forgery (the creation of data with the same digest as the expected data) by potentially malicious participants.
These are unsourced.  The second paragraph is unclear: what is the 'expected data' in the context of a hash table?  Also, the claim that 'hash functions lend themselves well to this application' is questionable, for the exact reason given in the second paragraph: performance.  Given the claims are questionable, unclear and unsourced, I plan to remove both paragraphs. - Crosbie 02:36, 15 August 2019 (UTC)
thread_title: Use in hash tables