Mini-thread on this latest Lucky13 research which includes two issues found in our Open Source Amazon s2n implementation of SSL/TLS ...https://twitter.com/IACRePrint/status/1030417029747146753 …
The overwhelming majority of clients, browsers, the SDK and so on, use AES-GCM and are not even theoretically impacted. For the remaining small percent using AES-CBC, based on our guidelines, we classed the issue as "LOW" impact for s2n. But again, there's actually no AWS impact.
-
-
Our "fix" for this issue is most-likely going to be just not implementing AES-CBC any more. It's now increasingly less common, and we can use KTLS and BoringSSL's implementations where we need it.
Show this thread -
As the paper calls out: s2n's approach to implementing AES-CBC has been to use pseudo-constant-time code, rather than fully constant time. Our reasons for using PCT code is that it far easier to audit and we must worry about introducing much worse bugs by having a lot of CT code.
Show this thread -
I hope that topic gets more research! It's a hard trade-off to balance. OpenSSL's CT approach also broke, leading to LuckyMinus20, arguably a more serious issue than the one it was meant to fix. The real answer is to use algorithms designed for CT! Thankfully AES-GCM is better.
Show this thread -
Last tweet for now! PR for our SHA384 changes:https://github.com/awslabs/s2n/pull/824 …
Show this thread
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.