First a small disclaimer: SCRAM is secure, but it's not finalized and we might make tweaks. We're going to be playing around with SCRAM on some experimental datasets and seeing what effect some tweaks have on performance.
-
Show this thread
-
TLDR: SCRAM 1/ adds protection against applications that either forget to authenticate plaintext, or intentionally look at plaintext before it's been authenticated, and 2/ integrates message padding directly into the AEAD layer.
1 reply 0 retweets 0 likesShow this thread -
Probably obvious by now that SCRAM is an AEAD algorithm, like AES-GCM, or ChaCha20-Poly1305, which means that it both encrypts data, and authenticates it (along with any additional data you want to authenticate, but not encrypt). Don't AEAD algs already defend against corruption?
1 reply 0 retweets 0 likesShow this thread -
Most cryptographic libraries implement 'in place' encryption; which means that the decrypted plaintext is available in application memory before it's authenticated (this happens only at the end).
1 reply 0 retweets 0 likesShow this thread -
Sometimes application developers just forget to check the return code of the authentication check. This is a serious security issue, but it's very hard to test for; normal data will decrypt just fine, you need a test case with a corrupt encrypted input.
1 reply 0 retweets 1 likeShow this thread -
Sometimes application developers intentionally look at plaintext before it's been authenticated, as in "EFAIL". They think that getting a "head start" on the data is worth it and that canceling or undoing the work if the auth fails is sufficient. Bad bad!
1 reply 0 retweets 0 likesShow this thread -
SCRAM prevents looking at plaintext prior to authentication cryptographically, not just with pinky promises. The MAC *has* to be computed to release the encryption key. If the application doesn't do this correctly, it won't decrypt, the application will just always get garbage.
2 replies 0 retweets 3 likesShow this thread -
Next up: SCRAM integrates padding! Traffic analysis is by far the most practical attack on modern encryption. By looking at message sizes, attackers can guess content, or decipher a voice call, and more. Very practical.
1 reply 0 retweets 2 likesShow this thread -
Many application developers don't appreciate how practical traffic analysis is, or if they do, they don't know how to implement message padding correctly. For example: many think that randomizing message sizes is a good idea (it is not).
1 reply 0 retweets 2 likesShow this thread -
SCRAM integrates padding directly; both to abstract away a problem that application developers mess up, and to signal to application and protocol designers, with the API, that padding is an important consideration.
1 reply 0 retweets 1 likeShow this thread
That's SCRAM! It's designed by Shay Gueron (AWS and University of Haifa), me (AWS), and Alex Weibel (AWS). Check it out at https://github.com/awslabs/s2n/tree/master/scram …, feedback is very welcome, we'll be publishing everything with our security proofs once finalized.
-
-
Bonus tweet: SCRAM uses the same underlying primitives as AES-GCM, so it still gets to use existing hardware acceleration!
0 replies 0 retweets 5 likesShow this threadThanks. Twitter will use this to make your timeline better. UndoUndo
-
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.