Is multiple encryption using NaCL and TLS better?

Question

In general, the idea of multiple encryption sounds interesting - for creating stronger cyphers (especially against implementation bugs), one could always get the configuration details wrong and mess it up.

So I wonder: if one starts with NaCL, which is supposed to have a default configuration that's very hard to mess up, and transmits it with TLS with a very good configuration, say from the recommendations at this Security.SE Q&A, does it improve security over TLS? What could go wrong?

Answer 1

Two things to consider: encryption and authentication.

• In general you can only say that a cascade of ciphers is as secure as its weakest link. If the encryption in NaCL had a side-channel attack, it might leak information about the plaintext, whether or not the ciphertext is sent through TLS.

• Authentication, on the other hand, is additive. If you can authenticate the message in both TLS and NaCL, breaking one will not allow an attacker to make forgeries.

However, getting any benefit requires that you have set up long term keys in both. Simply sending a NaCL key over a TLS channel allows a man-in-the-middle attack in case TLS is broken. Also, you have to use independent keys or a key recovery attack on any part of the stack may reveal them all.

In practice, a cascade may not help. If the implementations were perfect, it would likely be stronger, but with more things to implement there is also more potential for bugs and they may affect both. For example, Heartbleed would likely have leaked plaintext and keys even if you used an inner encryption layer (because it allowed random memory dumps).

When considering TLS and NaCL, specifically, you should note that some algorithms are used in both:

• AES (used in Poly1305 and some TLS suites)
• SHA-2 (Curve25519 and at least some TLS suites)

That doesn't matter if you are only concerned about implementation or protocol weaknesses, but means you couldn't claim resistance to one of those being fundamentally broken.