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.
1 reply 0 retweets 2 likesShow 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.
1 reply 0 retweets 1 likeShow 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.
1 reply 0 retweets 6 likesShow 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.
1 reply 0 retweets 2 likesShow 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 ...
1 reply 0 retweets 2 likesShow 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.
1 reply 0 retweets 3 likesShow 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.
1 reply 1 retweet 1 likeShow 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 …
2 replies 0 retweets 4 likesShow 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.
1 reply 0 retweets 4 likesShow this thread
But like, remember, we're talking about going from astronomical levels of protection to "even more just because we can".
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.