2 ms·

[replacing a somewhat rambling and distracted response with a "never mind..." ...Or not; it appears my edit to this overlapped a response, so I'm putting my ra

[replacing a somewhat rambling and distracted response with a "never mind..." ...Or not; it appears my edit to this overlapped a response, so I'm putting my rambling comment back, below] ---- Checking now, it looks as if, as of today at least, Facebook is also using/preferring AES_128_GCM. Again, I don't have a specific note-to-self to refer to, and my memory's a bit fuzzy, but I seem to recall that until recently they were using AES_128_CBC, or something else other than GCM. If you've time to answer, are you familiar with this use and change (am I right, specifically?) and if so might I impose for a sentence or two on what improvement the change to GCM brings? Regardless, thanks for the description and qualification in your parent comment. P.S. Upon reflection, I think I recall Facebook using AES_128_GCM for some time now, although I seem to recall -- perhaps incorrectly -- their using something else at some point after they switched to ECDHE_RSA. I mostly look at the certificate chains as a check against obvious man in the middle situations. Again, I'm not claiming any kind of expertise, but I do have a certain degree of curiosity. P.P.S. So maybe I shouldn't have asked/imposed my follow-up. Or maybe a better question would be, how is Facebook doing / regarded with respect to this aspect of security, these days?

tptacek 13y ago
AES-GCM is quite nice. It's a "modern" construction that both runs AES in a stream cipher mode and integrates it tightly with a fast message authentication code. The "GCM" in "AES-GCM" mostly alludes to GHASH, the MAC function, which is a fast polynomial universal hashing MAC, in roughly the same family as Daniel Bernstein's Poly1305. What's especially nice about AES-GCM is that the "mode" itself takes care of guaranteeing both message confidentiality and integrity. The TLS working group does not need to do much joinery and decisionmaking to make GCM work; the mode itself is standardized to provide those capabilities. The less you ask of the TLS working group, the more you put on the fundamental crypto, the better off you are. (As it happens, the very little decisionmaking latitude the TLS WG actually had for AES-GCM resulted in a weakness! Though not an especially meaningful one.) Facebook also has a good security team. Google has the advantage/beneficence of running an important browser project that is itself committed to moving the ball forward on TLS, which is an advantage Facebook lacks.
- tptacek 13y ago
  "Meaningful" was the wrong word here, FWIW.

tptacek 13y ago

AES-GCM is quite nice. It's a "modern" construction that both runs AES in a stream cipher mode and integrates it tightly with a fast message authentication code. The "GCM" in "AES-GCM" mostly alludes to GHASH, the MAC function, which is a fast polynomial universal hashing MAC, in roughly the same family as Daniel Bernstein's Poly1305. What's especially nice about AES-GCM is that the "mode" itself takes care of guaranteeing both message confidentiality and integrity. The TLS working group does not need to do much joinery and decisionmaking to make GCM work; the mode itself is standardized to provide those capabilities. The less you ask of the TLS working group, the more you put on the fundamental crypto, the better off you are. (As it happens, the very little decisionmaking latitude the TLS WG actually had for AES-GCM resulted in a weakness! Though not an especially meaningful one.) Facebook also has a good security team. Google has the advantage/beneficence of running an important browser project that is itself committed to moving the ball forward on TLS, which is an advantage Facebook lacks.

tptacek 13y ago
"Meaningful" was the wrong word here, FWIW.