Talk:Collision attack
This is the talk page for discussing improvements to the Collision attack article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
This article is rated Start-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||
|
Ctation needed?
[edit]"When a collision attack is discovered and is found to be faster than a birthday attack, a hash function is often denounced as "broken"." Says who? 93.228.115.74 (talk) 12:41, 25 January 2013 (UTC)
Error
[edit]Mathematically stated, given a prefix p, the attack finds two different appendages m1 and m2 such that hash(p || m1) = hash(p || m2) (where || is the concatenation operation).
I think this should be
Mathematically stated, given a prefix p, the attack finds two different appendages m1 and m2 such that hash(p1 || m1) = hash(p2 || m2) (where || is the concatenation operation). —Preceding unsigned comment added by 89.0.50.93 (talk)
- Oh shit, you're right! How could I make such a blatant error... Thanks for reporting! -- intgr [talk] 12:57, 17 August 2010 (UTC)
- Flame used the variant of collision prefix attack where H(p || m1) = H(p || m2). The authors of flame were only able to change a few fields in Microsoft supplied extensions - prologue and epilogue were not changed. You pretty much got it right two years before we saw a working exploit. Jeffrey Walton 19:58, 5 September 2012 (UTC)
Attack Scenario is Incorrect
[edit]Under attack scenario, it is stated "For example, password hashing and HMACs are not vulnerable [to collisions]." Intuitively, colliding passwords does seem relevant: H(p1) = H(p2) when p1 != p2 is definetly a problem (perhaps p1, p2 have a common prefix or suffix). In addition, when following the citation (provided by the Wayback machine), the Crytpography Research FAQ does not state passwords are not vulnerable. Jeffrey Walton 19:54, 5 September 2012 (UTC)
- Nope. Preimage attacks are relevant to password hashing. A preimage attack is not the same as a collision attack. E.g. NIST still approves SHA-1 for HMACs and PBKDF, but no longer recommends them for digital signatures. 178.195.225.28 (talk) 02:52, 6 September 2012 (UTC)
- Agreed with 178.195.225.28
- > H(p1) = H(p2) when p1 != p2 is definetly a problem
- This equation doesn't explain the whole situation. Under a collision attack, both p1 and p2 must be (partially) chosen by the attacker. And the attacker has no control over what the output hash is -- it's chosen arbitrarily in the collision attack process. Think about it -- if the attacker already knows the password (plaintext), or can specify it themself, then the password authentication system is already broken.
- In a real password hashing attack scenario, the attacker only has hash h and needs to find a plaintext where h=H(p). By definition, a collision attack is not applicable, since it won't help the attacker to find a colliding h, it will only find a pair of colliding p1 and p2.
- If the attacker is able to find a plaintext colliding with the known h, then it's already a preimage attack. -- intgr [talk] 13:21, 6 September 2012 (UTC)
"Near-collision" attacks?
[edit]The SHA-1 page (https://wiki.riteme.site/wiki/SHA-1) mentions a "near-collision attack"; what is that and can it be added to this page? A quick Google search found lots of mentions of them but no definitions that I saw. Bobbozzo (talk) 22:36, 23 October 2014 (UTC)
confusing attack scenario
[edit]The scenario depicted under Digital Signatures did not make sense before the November 7 edit (with three people) and makes even less sense now (with just Alice and Bob). Step 4 says "she sends document B to Bob", but she (Alice) does not have document B at that point. Can somebody clean this up? IOLJeff (talk) 18:36, 8 November 2015 (UTC)
- @IOLJeff: I have reverted the non-constructive edits. I also clarified it by changing "She" in the 4th step to "Mallory". Does it make sense now? -- intgr [talk] 09:21, 9 November 2015 (UTC)
Thanks, Intgr. That is better. I also tried to clarify further. IOLJeff (talk) 19:19, 12 November 2015 (UTC)
External links modified
[edit]Hello fellow Wikipedians,
I have just modified one external link on Collision attack. 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://web.archive.org/web/20100327141611/http://th.informatik.uni-mannheim.de/people/lucks/HashCollisions/ to http://th.informatik.uni-mannheim.de/People/lucks/HashCollisions/
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}}
(last update: 5 June 2024).
- If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
- If you found an error with any archives or the URLs themselves, you can fix them with this tool.
Cheers.—InternetArchiveBot (Report bug) 19:06, 10 August 2017 (UTC)
advance hashing
[edit]hassing is an improvement of collision