Hi,
On Thu, Feb 6, 2014 at 8:06 AM, Rouven Weßling <[email protected]> wrote:
> Hi everyone,
> hi Alex
> On 05.02.2014, at 11:20, Pierre Joye <[email protected]> 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