
TLS Symmetric Crypto - conductor
https://imperialviolet.org/2014/02/27/tlssymmetriccrypto.html
======
tptacek
The background you want to understand the TLS 1.2 ciphersuite benefits:

TLS was designed and standardized before cryptography figured out the proper
order of encryption and authentication, or, for that matter, that
authentication was even required. It dates back to an era where designs based
on what were best practices at the time often eschewed authentication (of
plaintext or ciphertext) altogether; instead, designers assumed that because
attackers didn't have crypto keys, they couldn't tamper with ciphertexts,
because their decryptions would result in gibberish.

A few years after SSL3/TLS, it was widely understood that cryptosystems
required authentication (the "gibberish decryption" defense is often just a
speed bump). And then it was mathematically proven that there's a proper order
to the two operations: cryptosystems should encrypt, then they should
authenticate the ciphertext. Doing it this way (among other things) denies
attackers the opportunity to conduct chosen ciphertext attacks, which in turn
closes off a variety of side channels (such as error oracles, which were
introduced in the symmetric crypto literature a few years after this).

The net result is that the old TLS ciphersuites are a mess with regards to
encryption and authentication. They do authenticate, using HMAC (which is
fine) in a generic composition. But they authenticate plaintext, which means
attackers can play games with ciphertexts; one result of this was the Lucky 13
padding oracle attack.

AES-GCM and ChaCha20-Poly1305 are modern authenticated cipher constructions.
They are conceptually very similar. Both are stream ciphers (and, in fact,
both are designs based on the concept of "CTR [counter] mode"). Both use
polynomial MACs instead of cryptographic hash MACs (you can think of a poly
MAC as a thermonuclear CRC algorithm). AES-GCM is very fast in hardware
(because it's a NIST standard that chipset vendors have optimized for).
ChaCha20-Poly1305 was designed to be fast in software as well.

Another bit of backstory you might want to know concerns the italicized "
_very_ difficult" Langley used to describe software AES-GCM. AES-GCM uses a
poly MAC that wants GF(2^n) multiplication and modular reduction. Fast
software implementations of GCM rely heavily on lookup tables. Lookup tables
entries are aggressively cached as they're hit, which makes the timing of
software AES-GCM heavily dependent on specific bit values of secrets, which is
dangerous.

~~~
pbsd
> you can think of a poly MAC as a thermonuclear CRC algorithm

Funny you would put it like that. You _can_ turn the regular CRC algorithm
(which is essentially a polynomial division) into a secure Wegman-Carter
authenticator (like polynomial-evaluation MACs): the secret key key2 would be
an irreducible CRC polynomial, and the scheme would loosely be PRF(nonce,
key1) + CRC(message, key2) (see Shoup [1]).

Wegman-Carter authenticators, unlike hash-based ones, are information-
theoretically secure. This means that they resist an attacker with infinite
resources. In a way, they're the analog of the one-time pad for
authentication. They also predate hash-based authenticators by decades: the
first secure construction of this kind of authenticator goes back to 1974 [2]!

[1]
[http://www.shoup.net/papers/macs.pdf](http://www.shoup.net/papers/macs.pdf)

[2] [http://www3.alcatel-
lucent.com/bstj/vol53-1974/articles/bstj...](http://www3.alcatel-
lucent.com/bstj/vol53-1974/articles/bstj53-3-405.pdf)

------
nly
Reading about djbs primitive making its way in to TLS, and all the hacks being
made to TLS, reminded me of CurveCP[0] and makes me wonder whether its an idea
worth revisiting.

For those interested in playing with Salsa20 & poly1305 authenticated
encryption outside of TLS there's Sodium[1] which has trivial C and C++ APIs
and is based on djbs Nacl[2]

I'd also refer people to Matt Greens post 'How to chose an Authenticated
Encryption mode'[3]. There are some interesting alternatives out there like
OCB (0.7 - 0.8 cycles/byte, free for FOSS despite patents, and more
understandable for mortals).

[0] [http://curvecp.org/](http://curvecp.org/)

[1]
[https://github.com/jedisct1/libsodium](https://github.com/jedisct1/libsodium)

[2] [http://nacl.cace-project.eu/box.html](http://nacl.cace-
project.eu/box.html)

[3] [http://blog.cryptographyengineering.com/2012/05/how-to-
choos...](http://blog.cryptographyengineering.com/2012/05/how-to-choose-
authenticated-encryption.html)

~~~
tptacek
CodesInChaos has documented some problems with the CurveCP key exchange:

[http://codesinchaos.wordpress.com/2012/09/09/curvecp-1/](http://codesinchaos.wordpress.com/2012/09/09/curvecp-1/)

~~~
nly
Yep, this was pointed out to me not so long ago here on HN. Still, ZeroMQ for
example has picked it up (adapted) for CurveZMQ.

[Edit] Oh, I see Peter Hintjens commented on that post re: that.

------
agwa
> The ChaCha20-Poly1305 cipher suites are unlikely to survive the IETF without
> changes so we'll need to respin them at some point

I'm curious - what might the IETF working group want to change?

~~~
agl
In order to make the AEAD construction suitable for IPSec it looks like the
nonce/block counter split needs to be 92/32 rather than 64/64 as I did it.

~~~
tptacek
32 bit block count is gross.

~~~
agl
Why? A 32-bit block counter allows for 256GB messages. As AEAD messages
shouldn't be decrypted in a "streaming" fashion (lest one return
unauthenticated plaintext), that seems more than sufficient.

(We don't have a good spec for composing AEAD operations for chunking large
messages yet, however.)

~~~
tptacek
Yeah, I see why it works in this setting, it's just ugly; it's a parameter
that is only really safe for this algorithm and in this service model.

You started with 64/64 for a reason. :)

------
cm3
The NSS bug
([https://bugzilla.mozilla.org/show_bug.cgi?id=917571](https://bugzilla.mozilla.org/show_bug.cgi?id=917571))
is still NEW. Any idea when it will be finished and included in Firefox?

------
dfc
OpenSSH also supports chacha/poly1305.

[http://blog.djm.net.au/2013/11/chacha20-and-poly1305-in-
open...](http://blog.djm.net.au/2013/11/chacha20-and-poly1305-in-openssh.html)

------
chrismorgan
A side issue for the maintainer of the website: for widths of 800px and below,
the website has no padding at all on the sides, and up to around 880px and
below the article's title is cut off on the left (only part of the S in "»
TLS" is visible—the rest is cut off on the left).

