On 12/12/2013 11:19 AM, Jacob Appelbaum wrote: > I think that generally, I would prefer if the code didn't use MD5 but > otherwise, I don't see any real risk of adding an exploitable hole. It > seems silly to disable it by default though - ideally, I'd like a sysctl > to ensure that Tor could use this without making the user recompile > their kernel. That is more of a pain than running a userspace helper, I > think. > > All the best, > Jacob
Given that the output is truncated to 32 bits and that performance (SYN flood) is also a concern, AND that the original TCP SQN generation is also MD5-based (and we want to look the same), what disadvantage do you see over MD5? Given the truncation to 32 bits, I don't think a stronger hash would do anything for us. As for it being disabled by default, we did this with respect to kernel submission guidelines which we understood said that features should _initially_ always be submitted with disabled-by-default (presumably so that until they have stabilized, nobody is harmed unless they explicitly activate the code). I don't see the point in having a sysctl, as applications have to explicitly request it anyway. -Christian
0x48426C7E.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
