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.
> 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
> "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.
Best regards
Rouven