I've been getting a few questions about the recent "PortSmash" vulnerability announcement. Short answer: This is not something you need to worry about. If your code is vulnerable to it, you were already vulnerable to other (easier) attacks.
It would be nice to have such a tool, but it isn't essential. If you talk to the developers of many crypto/security projects that have secret-dependent branches, they are well aware of (almost all of) them. Just fixing them is a relatively low priority until PoC is published.
-
-
LuckyMinus20 changed my mind on that. The branch free code fixes for Lucky13 went through a lot of review, loads of eyes, and patched a vulnerability. But then it unintentionally regressed within 18 months.
-
How would a `secret` modifier have helped With LuckyMinus20? IIUC, the LuckyMinus20 was a logic problem, not a side-channel.
-
The LuckyMinus20 was a logic error, and worse than the Lucky13 side-channel (IMO), at least for TLS (not DTLS). That's what I mean when I say it's too hard to write this kind of code without risking worse problems.
-
http://www0.cs.ucl.ac.uk/staff/b.cook/VSSTE18_sidetrail.pdf … can catch the LuckyMinus20 regression, we actually used it as a target case. It needs more than the secret modifier, it also needs to know the entry and exit points, but since the logic error is data-dependent, it can catch it too.
-
I wonder if Lucky13/LuckyMinus20 is an anomaly in how tricky it is, though. Most of the timing side-channels I know about (especially in OpenSSL) are much more straightforward than that, in terms of implementation.
-
Also, the constant-time "fix" for Lucky13/LuckyMinus20 is really only a partial mitigation. To the extent it is a serious issue for an application, one should avoid CBC cipher suites in TLS and more generally avoid bad uses of CBC mode like that. (The *ring* approach, so far.)
-
(The application should avoid the CBC cipher suites completely because generally it can't assume the peer it is communicating with even bothered to fix Lucky13 or BEAST or any other issue related to CBC cipher suites in TLS.)
-
We're about to take CBC out of s2n's default set, it's finally, finally, small enough a percentage of traffic to be viable. Curiously RC4 and 3DES each went much faster.
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.