Re: [GHC] #7634: MD5 collision could lead to SafeHaskell violation

#7634: MD5 collision could lead to SafeHaskell violation -------------------------------------+------------------------------------- Reporter: shachaf | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Core Libraries | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ekmett): * cc: core-libraries-committee@… (added) * milestone: 7.12.1 => ⊥ Comment: Acknowledging that this probably won't get addressed in the foreseeable future by pushing it out to _|_. Given that the two strings would have to be legal UTF-32 encodings of text that can actually be entered you wind up with a '''huge''' number of fixed bits in the strings on either side, which very quickly raises the cost of an attempted birthday attack and also forbids a number of birthday attack generation techniques. That said, saying a cryptographic attack isn't possible for hand-wavy reasons doesn't have a great track record for success. :) Techniques for finding small single block collisions via random walks, like https://eprint.iacr.org/2014/871.pdf are probably the most likely source of such a vulnerability. Notice how similar the colliding document pair are. In theory you could prune the walk to keep the paths always within the space of valid inputs. I lack a few weeks (months?) of HPC cluster time to test this hypothesis, however. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/7634#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC