Posted by Elie Bursztein, Anti-Abuse Research Lead recent attacks against RC4 and CBC also prompted us to make this change.
Better security: ChaCha20 is immune to padding-oracle attacks, such as the Lucky13, which affect CBC mode as used in TLS. By design, ChaCha20 is also immune to timing attacks. Check out a detailed description of TLS ciphersuites weaknesses in our earlier post .
Better performance: ChaCha20 and Poly1305 are very fast on mobile and wearable devices, as their designs are able to leverage common CPU instructions, including ARM vector instructions. Poly1305 also saves network bandwidth, since its output is only 16 bytes compared to HMAC-SHA1, which is 20 bytes. This represents a 16% reduction of the TLS network overhead incurred when using older ciphersuites such as RC4-SHA or AES-SHA. The expected acceleration compared to AES-GCM for various platforms is summarized in the chart below.
greater adoption of this cipher suite, and look forward to seeing other websites deprecate AES-SHA1 and RC4-SHA1 in favor of AES-GCM and ChaCha20-Poly1305 since they offer safer and faster alternatives. IETF draft standards for this cipher suite are available here and here .
Follow
3 則留言 :
No Linux distro seems to ship an OpenSSL with those patches applied yet.
While I am glad to hear that and I know Google has access to the brighest brains, probably even outdoing Microsoft as an employer in this respect: since the NSA revelation by a certain "Russian agent" called Snowdenow we all fret how all of your efforts might be compromised right from the start. Unexpected payloads, undetected trapdoors, man in the middle, anyone?
Well, since Android’s SSH implementation doesn’t have it, it’s rather pointless…
(I use those cyphers on all my servers, and the stupid Android phones can’t handle it.)
張貼留言