3 ms·
Is there a chance this could be vulnerable to timing attacks ? Is comparing two integers fixed time ? It may be pure hazard, but in the following two calls,
by fooyc 13y ago
Is there a chance this could be vulnerable to timing attacks ? Is comparing two integers fixed time ?
It may be pure hazard, but in the following two calls,
E(0x000000FE);
E(0xC0000000);
The second one is significantly slower: http://jsperf.com/qsmflkjtest http://jsperf.com/qsmflkjtest
- russellsprouts 13y agoI get the same thing. On my machine it's 80% slower. One solution is to use a string comparison. The high number is only 7% slower in that case. http://jsperf.com/qsmflkjtest/2 http://jsperf.com/qsmflkjtest/2
- tlrobinson 13y agoHow do you defend against side channels? A: We only focus on semantic language safety, and if you use the translation to ProVerif, the correctness of the protocol implementation. There are many side channels available to a same-origin attacker - the most obvious ones being time and memory. In SJCL, we sometimes try to mitigate those channels - for instance, in CCM tag validation. However, we do not have any formal proof of robustness against any side-channel attacker - furthermore, user-written DJS code must also take into account this risk. For instance, use the AES.ctEq function for constant time string comparison.