The "additional data" is just any other data you might want to "prove" the sender has, but not send; like say some meta-data that establishes a permission. It's often left empty.
-
Show this thread
-
Now you can still screw up with AEAD. If you re-use the same IV, that's bad!! There are attempts to make this better, my colleague Shay has been working on a cool scheme called SIV, and it adds a measure of protection against that too.
1 reply 0 retweets 2 likesShow this thread -
If you do use unique IVs, modern encryption is really robust. In general, you could publish some encrypted text in the New York Times, and no-one will be able to crack it. This Is true even if /some/ of the text is known. For example ...
1 reply 0 retweets 2 likesShow this thread -
In internet protocols a lot of the text is known, a HTTP server always responds the same way and the first few bytes are known and totally guessable. This doesn't matter at all - doesn't help an attacker figure anything else out even one bit. We've come a long way from WWII.
1 reply 0 retweets 3 likesShow this thread -
But there are attacks that do work! If you're sending this data over a network, and someone can see the timing and size of message. This opens us up to traffic analysis.pic.twitter.com/8qeI9A3Ozp
2 replies 0 retweets 3 likesShow this thread -
Let's look at length first. O.k. so the length is obviously not hidden. That's fine if you're trying to protect your password or credit card number in the middle of a response. No big deal. But it does mean that someone might be able to fingerprint the content you're sending.
1 reply 0 retweets 1 likeShow this thread -
Simple example: if you send a gif over a messaging app, if the size of that gif is unique, someone in the middle can probably guess what gif you just sent. There are more sophisticated versions of this for Google Maps, Netflix, WikiPedia, and so on.
1 reply 0 retweets 2 likesShow this thread -
The way we protect against this is to "pad" messages, to make large numbers of messages appear to be the same size no matter what. Military grade network encryption actually pads all traffic all the time, so it's always the same!
1 reply 0 retweets 4 likesShow this thread -
Another problem with length is that if you're using compression, and let attackers control any of the content on a page that a user sees, that can let the attackers figure out even small secrets. Look up the "CRIME" attacks. It's awesome, and scary.
3 replies 0 retweets 7 likesShow this thread -
Replying to @colmmacc
This thread is amazing, if even for just this tweet. Colm, quick question while I search for the answer online: is the CRIME vulnerability viable because of the use of compression on messages that include cipher texts, or because TLS encrypts compressed data?
1 reply 0 retweets 0 likes
CRIME is viable when you compress attacker-controlled "guess" data AND victim-valuable secret data. Both in the plaintext that's compressed, then encrypted. If the attackers guess overlaps with the secret, the overall size will be smaller, and the size isn't hidden by encryption.
-
-
Thanks. 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.