On Fri, Jun 20, 2014 at 13:53, Damien Miller wrote: > On Thu, 19 Jun 2014, Ted Unangst wrote: > >> Always explicitly compare memcmp with 0. I find this adds clarity. > > If you don't care which way a different comparison points, then why > not use bcmp?
There are a couple points here. 1. we have a timingsafe_memcmp function that is a drop in replacement for memcmp. maybe a little slower, but behaviorly compatible. 2. i would like for more people to use constant time functions, even when there is not a proven side channel. currently the state of the art appears to be people publish papers exploiting timing, and then people fix bugs. comparisions are only a subset of side channels, but i think we can get ahead of the curve by using such functions even without proof of attack. 3. bcmp has a slightly difference interface, making it not always a drop in replacement. this means people have to think about their conversions, which i think interferes with point 2. Basically, I would like people to experiment with ideas such as compiling their code with -Dmemcmp=timingsafe_memcmp. Doing the same with timingsafe_bcmp would be a disaster, however, for software that depends on the ordering. If we use timingsafe_bcmp widely (safe as that may be), it's very hard to convey the idea that there are circumstances when it is not safe. Using timingsafe_memcmp raises its awareness and will make it other developers' default choice.