Talk:Preimage attack

message: Removed this:
:For example, there is a program called CRC Faker that will generate a file of a user-defined size with the CRC requested.
Because CRC is not a cryptographic hash. It's only good for error detection; compromising data integrity is (almost) trivial. This cannot really be called a preimage attack unless you're stupid enough to use CRC for integrity checking—OTOH, many people are indeed stupid enough to do that, so maybe it should be mentioned with qualification... 82.92.119.11 22:04, 11 January 2006 (UTC)
thread_title:  Removed CRC 

message: I do not agree with the following statement in the article:
: Due to the similarity between these two cases a method for attacking one can normally be applied to attacking the other.
RFC 4270, which is given as reference, makes such a claim but gives no explanation for the claim. 
A well known example for a second preimage attack was an exploit that allowed to change the boot code of the
XBOX (see ).
The attack there based on the fact that TEA is a bad choice for constructing a hash function. I.e.,
the hash function used for the XBOX has the property that the hash result does not change if certain bits
are changed. This allowed a second preimage attack that could be used change the boot code, so that this
change was not detected by the XBOX. It does not seem that this attack can be extended to a first preimage attack.
67.84.116.166 02:39, 12 September 2006 (UTC)
thread_title:  Difficulty of first vs. second preimage attack 

message: I replaced the second paragraph, since the wording of the paragraph can be confusing. It might infer that a hash function to which finding a preimage attack takes in the order of 2n operations is vulnerable and not good. I was especially worried when the page on cryptographic hash functions http://en.wikipedia.org/wiki/Cryptographic_hash_function saying that 'Functions that lack first preimage resistance are vulnerable to first preimage attack'. I wanted to clarify that such complexity applies to even an IDEAL hash function. 
 
I also added some information about the current state of preimage attacks on popular cryptographic hash functions and how they relate to Internet security. I also added a reference on some of these attacks.  —Preceding unsigned comment added by 128.237.246.113 (talk) 17:30, 2 September 2009 (UTC)
thread_title:  Rewording - Update - Reference 

message: I added the link to the random oracle in the "see also" section. I am wondering if it should also be mentioned in the text or would it be to confusing to put so much information in the sentence.  —Preceding unsigned comment added by 89.75.117.235 (talk) 09:35, 25 May 2010 (UTC)
thread_title:  Random oracle 

message: I think the statement "in fact, any hash function which is resistant to first or second preimage attacks is by definition collision-resistant" is not correct or, if it is, it is insufficiently substantiated in text or through reference. The first part of the paragraph also seems to me to contradict this statement: since it is known that MD5 and SHA-1 are not collision resistant, I would expect it to be easy to show how they are also not preimage resistant (because the falsity of the conclusion implies the falsity of the premise). However, the preimage resistance properties of MD5 and SHA-1 are not nearly as badly broken as the collision resistance, therefore it is probably not easy after all to leverage the collision attacks to preimage attacks. 194.203.215.254 (talk) 11:58, 1 October 2010 (UTC)
replies: text: Thanks! You're right, the Handbook of Applied Cryptography explicitly states "collision resistance does not guarantee preimage resistance". The article was recently changed; It's not clear what the earlier statement meant so I removed it entirely. -- intgr [talk] 18:24, 1 October 2010 (UTC)
thread_title:  Does preimage resistance imply collision resistance? 

message: The article says that "[f]or an n-bit hash, [a brute force] attack has a time complexity 2^n". Wouldn't it be more correct to say it has an average time complexity 2^n? Nothing guarantees that no more than 2^n variations of the input are needed to come up with a hash (though that's the expected average number of variations), except if the hash has an input size of n bits, which as far as I know, none does. I'm asking because I'm not sure if the term "time complexity" implies an average. —pgimeno (talk) 19:25, 24 September 2013 (UTC)
thread_title:  Brute force time complexity