
Technical developments in Cryptography: 2016 in Review - shleemies
https://www.eff.org/deeplinks/2016/12/what-happened-crypto-2016
======
tptacek
It's a pretty good roundup. Some additional notes:

1\. _TLS 1.3_ : The biggest news regarding TLS 1.3 is that the RSA-based
handshake has, at last, been evicted from TLS. This despite industry
complaints that eliminating TLS RSA would cause problems, especially in the
finance industry, for companies that need the ability to monitor the plaintext
of TLS connections on their networks. The kerfluffle led to one of the all-
time great exchanges on the TLS working group:

[https://www.ietf.org/mail-
archive/web/tls/current/msg21278.h...](https://www.ietf.org/mail-
archive/web/tls/current/msg21278.html)

TLS 1.3 is the first of what I think will be many steps towards the eventual
deprecation of RSA in most applications. It's difficult to implement and
deploy RSA safely, compared to the elliptic curve alternatives, and because
we've come to demand forward secrecy from our protocols, RSA's ability to
easily encrypt directly as well as sign has lost its luster.

2\. _PQ_ : I don't have much to say about this (I'm a QC skeptic, though I try
to keep up with the underlying algorithms here), but would note that Google
has since withdrawn the CECPQ1 experimental handshake from Chrome (not for any
deficiencies, but simply because it was a temporary experiment). I guess I'd
say: don't deploy new PQ crypto in new designs yet.

3\. _Backdoored Diffie-Hellman_ : The next two subjects in the round-up really
read more like one section. Both the papers Bonneau cites are great and worth
reading directly. The RFC 5114 thing seems like one of those "don't attribute
to malice what can better be attributed to incompetence" sort of deals,
particularly in light of the DH survey paper --- it's hard to blame NSA for
implementations that don't check incoming public keys for validity. The tables
in the middle of the paper give a good sense for how infrequent the attack
they're talking about occurs on real hosts on the Internet, but, be that as it
may, it's embarrassing that things like Exim were not only using the DSA DH
parameters but also not checking incoming keys. For what it's worth: these
attacks are in both Set 5 and, in a setting much closer to what the DH survey
paper did, Set 8 of the cryptopals challenges. It's a neat attack, and also
very applicable to ECDH.

4\. I can't make myself care about DKIM.

5\. Bonneau has a great list of practical attacks here; in particular, if you
haven't read the DROWN paper, you're really missing out. If you've done set 6
of the crypto challenges ---
[http://cryptopals.com/sets/6](http://cryptopals.com/sets/6) \--- this is like
Stunt Bleichenbacher, exploiting the malleability of RSA ciphertexts in
multiple ways to get handshake material to function simultaneously in two very
different protocols.

6\. _TLS /HTTPS_: It took an insane, absurd amount of time to get Curve25519
standardized, especially relative to the benefits of having a fast,
trustworthy curve that doesn't (in TLS) require point validation (mitigating
the ECDH version of the attack against Diffie Hellman described above). The
IETF basically ran an Olympic-level event in bikeshedding, this time. Crypto
standards groups are evil, intrinsically, and should be avoided.

~~~
bogomipz
>"This despite industry complaints that eliminating TLS RSA would cause
problems, especially in the finance industry, for companies that need the
ability to monitor the plaintext of TLS connections on their networks"

How do they monitor plaintext of TLS? Do they "man in the middle" this
traffic? Can you elaborate? Is this a compliance issue or sorts?

~~~
wolf550e
Since they have the key for their own certificate, they can man in the middle
forward secret connections too (these days, ECDHE). By supporting only non-PFS
RSA key exchange with TLS 1.2, they had the ability to retroactively decrypt
traffic without doing full man in the middle. Maybe they mirror a port on a
switch and run an IDS/antivirus that decrypts the traffic and analyzes it.
Maybe they log all traffic for a while and want to decrypt it only if needed.

In any way, the solution someone came up with was to do Diffie Hellman but
reuse the ephemeral key (make it static) and share it with the decryption box.
This turns (EC)DHE into not forward secure key exchange. The client can notice
this happens because the server will reuse the DH key. I didn't hear about any
browser planning to warn the user about this. The ssllabs tester will
complain.

