2013/3/19 Thomas Schilling
Oh, I just realised that this proposal is to include the older version of hashable. In principle, I'm not against that, but I do wonder what the upgrade path is. I don't think the performance problems can be fixed in general -- that's just the price of security. So it becomes critical what the upgrade path looks like. Do users get a slowdown of 2x by default and then have to manually make it faster again if something is not security sensitive? Do users have to explicitly opt in for security (a bad default, IMO)? Do we have any idea how that switch may affect the API?
It seems reasonable for the secure algorithm to be handled with something explicit -- a newtype, a `secureHash' function -- so that a developer has real confidence that it's being used. What if the default changes back? -- Jason Dusek pgp // solidsnack // C1EBC57DC55144F35460C8DF1FD4C6C1FED18A2B