7 ms·
Speeding up and strengthening HTTPS connections for Chrome on Android
- agl 12y agoDetails: https://www.imperialviolet.org/2014/02/27/tlssymmetriccrypto.html https://www.imperialviolet.org/2014/02/27/tlssymmetriccrypto...
- higherpurpose 12y agoCould ChaCha20 be implemented in hardware, too, and would that provide significant speed improvements still? Intel, AMD and ARM should probably consider it for their future chip designs, if so.
- Lx1oG-AWb6h_ZG0 12y agoDamn, that is an impressive writeup. I'm staggered by the amount of work needed to enable a new crypto suite, and amazed it got done so quickly. The scale at which Google operates is genuinely mindblowing.
- self 12y agoIt looks like it's pretty painful to add stuff to OpenSSL: https://plus.google.com/+ElieBursztein/posts/c99W3fGsuKx https://plus.google.com/+ElieBursztein/posts/c99W3fGsuKx
- jfindley 12y agoAre there any public docs on the details of how you've implemented the equal preference cipher suites at the server end? Is this simply an extension to the server's cipher selection, or do you use NPN/ALPN for this?
- tptacek 12y agoThis is great news. ChaCha20 is a refinement of Salsa20, which is probably Bernstein's best-known crypto design (it survived the eSTREAM contest to become one of the final portfolio ciphers). Bernstein wrote an extremely readable design paper on Salsa20: http://cr.yp.to/snuffle/salsafamily-20071225.pdf http://cr.yp.to/snuffle/salsafamily-20071225.pdf Salsa20 is essentially a fast hash function run in a carefully designed counter mode. If you don't care about speed, you can turn any secure hash function into a stream cipher by, for instance, running the HMAC of that hash in counter mode. Here, Bernstein has designed the Formula 1 car of hash cores to run quickly in software without side channels as the basis for a counter-mode stream cipher. Poly1305 is, like the GHASH construction from GCM, a "polynomial MAC", which is the modern way to say "cryptographic CRC". Poly1305 was designed more carefully for software performance than GHASH. In particular, because it's based on binary fields, for competitive performance GHASH requires either hardware support (such as the Intel CLMUL instructions) or a table-based implementation that potentially leaks secrets from cache timing. Poly1305 is based on prime fields and is fast in software on platforms without instructions tailored to it. It is also mercifully easier to code (though maybe I'm just irrationally biased against binary field polynomial math).
- deleted 12y ago[deleted]
- Scaevolus 12y ago"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." Does that mean 25B->21B per-packet overhead? What percentage overhead are TLS headers?
- agl 12y agoYes, vs RC4-SHA. There's always five bytes of record header: the record type, u16 length and u16 version. (The version is basically a waste.) For AES-CBC there's an average of 8 bytes of padding (half the block size). For AES-GCM there's eight bytes of wasted nonce because of FIPS concerns that appear to have been groundless. Then there's the MAC: 20 bytes for HMAC-SHA1 or 16 for GCM or Poly1305.
- tptacek 12y agoIf you were designing a new transport to replace TLS, would you build a flexible record layer protocol to run it on top of, in the sense that TLS provides?
- agl 12y agoI'd likely say that the records are AEAD ciphertext and let the AEAD decide on what that means. But as for allowing handshake messages, alert messages etc to mix with application data, no. (See the QUIC design as an example: https://docs.google.com/document/d/1g5nIXAIkN_Y-7XJW5K45IblHd_L2f5LTaDUDwvZ5L6g/edit https://docs.google.com/document/d/1g5nIXAIkN_Y-7XJW5K45IblH...)
- userbinator 12y ago> Poly1305 also saves network bandwidth, since its output is only 16 bytes compared to HMAC-SHA1, which is 20 bytes I'm puzzled why a shorter MAC would be considered a good thing in a security application - because theoretically, a 20-byte MAC gives roughly 4 billion times the space of a 16-byte one. It's like shortening an encryption key - hasn't the trend been toward making them longer and thus more resistant to attack?
- awda 12y ago> Poly1305 also saves network bandwidth, since its output is only 16 bytes compared to HMAC-SHA1, which is 20 bytes. You could also just truncate HMAC-SHA1 to 16 bytes, right?
- tptacek 12y agoIf you wanted a slower, less secure MAC, yes.
- awda 12y agoIs 16-byte Poly1305 more secure than 16-byte HMAC-SHA1? (Actually curious. Citation: I've done all the matasano crypto challenges, and all of the stripe µctf stuff :).)
- tptacek 12y agoI believe so? Isn't there a 2^80 attack on SHA1? I think the bigger issue is that the security proof for a polynomial MAC is much clearer (and the MAC itself is much faster).
- userbinator 12y agoOn average a bruteforce attack will find a match halfway through the keyspace, so that would be 2^80 for SHA1... and only 2^64 for Poly1305 and anything else with a 128-bit width (that isn't broken in some other manner.)
- tveita 12y agoHalfway through the tag space of a 160-bit tag is 2^159. You're looking for an exact match, not just a collision.
- tveita 12y agoThe collision attack on SHA-1 should not threaten HMAC-SHA1. Even HMAC-MD5 hasn't been successfully attacked yet, AFAIK. Poly1305 is arguably less misuse-resistant, since it requires a nonce.
- jcampbell1 12y agoDoes anyone know why google doesn't offer a webserver? I want SPDY, QUIC, and whatever cypher ordering magic is required to make my service faster on android. Unfortunately I probably won't be able to deploy this for at least a year because I have to wait on nginx and openSSL. By the time I could reasonably deploy this, shipping android phones will have the hardware to make this irrelevant. Maybe google sees their in house webserver as a competitive advantage. Maybe their own internal infrastructure is too complicated to pull out a simple useful webserver.
- wmf 12y agoI guess that's kind of the point of App Engine.
- riffraff 12y agothey do offer the pagespeed proxy.
- puzzlingcaptcha 12y agoAlso pagespeed nginx module.
- self 12y agonginx has ngx_http_spdy_module and Google gives away mod_spdy for Apache 2.2. QUIC's server is in Chromium's code base; they haven't broken it out into a separate project (the protocol is still not stable). I've used mod_spdy on Ubuntu 12.04 for several months now, and it seems to work pretty well.
- mrsaint 12y agoI'd love to offer ChaCha20 server-side, but I am currently using the default package of OpenSSL from Debian Wheezy which doesn't support the cipher. Are there already official OpenSSL builds available with ChaCha20 enabled, or does it still require running the patch from the Chromium team? If available, it'd be nice if someone could backport it.
- DiabloD3 12y agoIt seems no major distro builds their OpenSSL with the Salsa20+Poly1305 patches yet.