Re: little request :)

Hi, On Thu, Feb 6, 2014 at 8:06 AM, Rouven Weßling <me@rouvenwessling.de> wrote: > Hi everyone, > hi Alex > On 05.02.2014, at 11:20, Pierre Joye <pierre.php@gmail.com> wrote: > > > About the timing attack RFC, I have asked for some review and advice > > and here is a useful one already, thanks Alex :) > > > > Please keep him as CC as I do not know if he is on this list. > > First, thanks for getting that review. The more people who know their > stuff look at this, the better. > > > I think a function like this is needed, but you're right: it'd need to > > be let's say more solid, and it should be specified which properties are > > guaranteed and to what extent (tricky!) > > > > As it is, it tries to hide the length of known_str, but it fails to do > > so at least because integer division is commonly not constant time. > > I may just be blind, because it's getting late. I don't see any integer > division occurring. Only bitwise operations which, from my understanding, > should all be constant time. > Both modulo and division share the same opcode, namely divl; the quotient is stored in eax and the remainder in edx. A division may internally be faster if, say, it divides by a power of two; I'm not saying that this optimization actually takes place, but it's plausible. > > Does zend_parse_parameters() figure out the string lengths in constant > > time? I hope so. > > As stas has already mentioned, yes it does. Strings are stored together > with their length. > > > Is MAX() implemented without branching? Hardly. > > It's not (for reference the code is below). I think the impact of this is > reduced by the fact, that unless the length is 0 always the same branch is > used. > > #ifndef MAX > # define MAX(a,b) ((a)<(b)?(b):(a)) > #endif > Depending on the compiler this may be written in a branch like: if (a < b) yield b; else yield a; But yes, in nearly all cases only one branch is used. > > "Do not optimize this for speed." - this is merely a source code > > comment, and while it might work on humans, it won't work on C > > compilers, which may indeed try to optimize the code in various ways. > > Currently, C compilers are not known to optimize this specific construct > > in a dangerous way, but there's nothing preventing them from doing so. > > The comment is directed at humans, who might want to touch it in > undesirable ways in time to come. > > As for C compilers, that's true. But I think that's an impossible problem > to solve. We could of course ship assembler versions, but I'm willing to > bet we'll never cover all platforms. > > > Hiding a string length is really tricky, and only possible to a more > > limited extent than hiding byte value differences. > > That's probably a good conclusion. I think we should just document this as > potentially leaking information about the length. If we do find ways to > reduce this, by all means, we should take them. > It would be nice if there's benchmark software to test various scenarios and have those tested on a few different platforms. Btw, could we use the name hash_equals() instead? This function returns a boolean whereas a standard comparison functions return -1, 0, 1. > > Best regards > Rouven > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- -- Tjerk