On Tue, Jun 09, 2020 at 11:48:42AM +0200, Tim Duesterhus wrote: > > I think that instead it could be done slightly differently, by using > > CRYPTO_memcmp() when openssl is present or memcmp() when not, and > > documenting that the constant time is enforced when haproxy is compiled > > I don't think that's a good thing, because it can easily result in an > accidental loss of "security".
I thought about it as well, though I don't think it's a big deal in such a case, but that's indeed a point. > Also the behavior would change, because with > OpenSSL you would only get back a true or false and without you would also get > an ordering. Not necessarily, that's just a matter of how it's implemented. As long as both only return foo_memcmp() == 0 that's similar. > > with openssl. Otherwise, maybe create two converters, memcmp() and maybe > > secure_memcmp() or whatever, the latter being only available with openssl, > > and promising constant time. But quite frankly I don't think there's much > > interest in constant time in environments where openssl is not built in. > > A regular memcmp can already be simulated by hex encoding both values and then > using the strcmp converter. Hex encoding preserves the ordering of the byte > values, thus I believe this should be equivalent if someone needs to know the > ordering. Sure but that's ugly :-) Anyway I'd expect that if really needed someeone can easily start this way then implement memcmp(). > I think I'll just rename the converter to `secure_memcmp` and in fact did so > for the attached patch. OK that's fine for me, now applied. Thanks! Willy
