Christian Grothoff: > 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.
If we believe that MD5 is not secure, we should not use it. That others use it is not a strong reason to use it. Everyone should stop using MD5 - especially truncated MD5. :) > > 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 think that is a fine reason at submission time but this should not be the default state for very long. > I don't see the point in having a sysctl, as applications have to > explicitly request it anyway. To have it supported and to have it enabled in the kernel are not exactly the same thing. It would be nice if it was available to everyone by default (likely with some CAP) and to enable it on a systemwide basis, one could simply flip a sysctl. One also needs to use it in an application, obviously. All the best, Jacob -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
