+1 on awesome research here that is advancing the state of the art, and since it mentions Amazon s2n I am encouraged by our friendly support team to make clear that there's no issue and AWS customers don't need to do anything 
Let's dive in ...https://twitter.com/tqbf/status/1166788853300105216 …
-
-
At a high level: the attacker usually meddles with good input in interesting ways, observes how the system responds, and gradually learns information about the input.
Show this thread -
Handling the information in a completely consistent way, regardless of the input values is one mitigation. Modern cryptography uses this approach for a lot of algorithms, but it's not always practical.
Show this thread -
Another way to protect against these problems is to authenticate encrypted data before even trying to decrypt it. This is Encrypt-then-MAC / MAC-then-Decrypt.
Show this thread -
What the research gets at is new ways to analyze code and encryption formats, using SMT solvers, to see where there might be interesting differences in how inputs are handled.
Show this thread -
The researchers use the Amazon s2n TLS ticket encryption format as an example. But there's not much special about this format, it's basically the same as every TLS ticket encryption format.
Show this thread -
They show that if an attacker could forge messages, then the format handling might be able to be used to decrypt information. It turns a forgery kind of attack into a secrecy breaking one, which is an advance of the art. But ...
Show this thread -
We use Encrypt-then-MAC to protect the messages from forgery in the first place, with AES-GCM, so the attacker can't get to any of this. If AES-GCM could be bypassed, there's gobs of these kinds of issues in higher level software, like web servers.
Show this thread -
The paper points out that AES-GCM has a well-known problem that messages can be forged if the same key and nonce are ever repeated. In s2n, we rotate ticket encryption keys every hour! Well well well well within conservative limits.
Show this thread -
Quite a bit of work went into how s2n rotates and phases keys in/out for this. You can get a sense from the API:https://github.com/awslabs/s2n/blob/master/docs/USAGE-GUIDE.md#session-resumption-related-calls …
Show this thread -
We've been looking at using AES-GCM-SIV here too, a change that BoringSSL made, which can help make things even more defensive. We're working too on yet another SIV mode, specifically for 0RTT, which is even more defensive for this exact kind of issue.
Show this thread -
But like, remember, we're talking about going from astronomical levels of protection to "even more just because we can".
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.