
Speeding up and strengthening HTTPS connections for Chrome on Android - helper
http://googleonlinesecurity.blogspot.com/2014/04/speeding-up-and-strengthening-https.html
======
tptacek
This 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).

------
agl
Details:
[https://www.imperialviolet.org/2014/02/27/tlssymmetriccrypto...](https://www.imperialviolet.org/2014/02/27/tlssymmetriccrypto.html)

~~~
Lx1oG-AWb6h_ZG0
Damn, 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
It 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)

------
Scaevolus
"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?

~~~
userbinator
> 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?

~~~
tptacek
Simpler security proof, higher guaranteed security with a shorter MAC.

~~~
riffraff
could explain this in a longer way?

Considering the HMAC subset of MAC, the final value of the function should be
of the same length of the base hash function.

So i.e. hmac-sha256 would be longer than hmac-sha1, but I don't understand why
the latter would be simpler to check and of higher security.

Or do you mean that Poly1305 is all three (simpler, more secure, shorter mac)
compared to the HMAC family?

------
jcampbell1
Does 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.

~~~
riffraff
they do offer the pagespeed proxy.

~~~
puzzlingcaptcha
Also pagespeed nginx module.

------
awda
> 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
If you wanted a slower, less secure MAC, yes.

~~~
awda
Is 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
I 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
On 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
Halfway through the tag space of a 160-bit tag is 2^159. You're looking for an
exact match, not just a collision.

------
mrsaint
I'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
It seems no major distro builds their OpenSSL with the Salsa20+Poly1305
patches yet.

