The defence against PortSmash is exactly the same as the defence against microarchitectural side channel attacks from 2005: Make sure that the cryptographic key you're using does not affect the sequence of instructions or memory accesses performed by your code.
-
Show this thread
-
Replying to @cperciva
Not just the key, the secret data too! This is the right advice, but it's very unsatisfying. It's still too hard to write and verify this kind of code, and sometimes coding mistakes there are bigger problems than the side channels they were designed to fix.
1 reply 0 retweets 1 like -
Replying to @colmmacc
Keys are generally more sensitive than data; but yes, it should all be kept secure. I've been asking compiler authors for 13 years to give us better tools, e.g. to mark variables as "cannot be used in control flow or address computation". Alas, no progress yet...
2 replies 1 retweet 2 likes -
Maybe Amazon can find some smart compiler people and get them to do this? It would help everybody's security. ;-)
2 replies 0 retweets 0 likes -
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.
1 reply 0 retweets 0 likes -
Replying to @BRIAN_____ @cperciva
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.
1 reply 0 retweets 0 likes -
How would a `secret` modifier have helped With LuckyMinus20? IIUC, the LuckyMinus20 was a logic problem, not a side-channel.
1 reply 0 retweets 0 likes -
Replying to @BRIAN_____ @cperciva
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.
2 replies 0 retweets 1 like -
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.
1 reply 0 retweets 2 likes -
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.
1 reply 0 retweets 1 like
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.)
1 reply 1 retweet 1 like -
Replying to @BRIAN_____ @cperciva
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.
0 replies 0 retweets 2 likes
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.