Timeline for How can I prevent side-channel attacks against authentication?
Current License: CC BY-SA 4.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 31, 2019 at 5:05 | comment | added | Squeamish Ossifrage | (Spectre is a somewhat different issue about branch prediction and speculative execution: even if your cryptography code has no timing side channels in its logic, other logic in the same address space may leak secrets that you thought only the cryptography logic used. So while it's broadly relevant, and it is a kind of timing attack, it's qualitatively different from the problem in the OP's quoted code that could be solved by a constant-time string comparison.) | |
| Oct 31, 2019 at 5:03 | comment | added | Squeamish Ossifrage | Please don't recommend secret-dependent branches! Even on CPUs without branch prediction or speculative execution, secret-dependent branches are bad news. And please don't recommend randomized delays, which are consistently tempting to people outside cryptography engineering circles but are not actually very effective. | |
| Oct 30, 2019 at 16:02 | comment | added | Conor Mancone | This is more of an implementation detail so not really worth mentioning, but I already started. Adding a random delay only works so long as the "standard deviation" of the delay length is longer than the possible differences in timing. I.e. if branch predictions can add +/- 0.25microseconds but your random delay only adds +/- 0.25 nanoseconds, then it obviously won't help. I know you realize this so I'm not implying you were suggesting an incorrect course of action, but just felt like adding that in to the discussion. And yes, those numbers are non-sensical | |
| Oct 30, 2019 at 15:17 | history | edited | Philipp | CC BY-SA 4.0 |
added 7 characters in body
|
| Oct 30, 2019 at 15:10 | history | edited | Philipp | CC BY-SA 4.0 |
added 393 characters in body
|
| Oct 30, 2019 at 15:04 | history | answered | Philipp | CC BY-SA 4.0 |