tls-enc: Forward Secrecy and quantum computing

janspambox

Currently, users have to choose between static key encryption or TLS.

If you choose static key, you have no forward secrecy - if the key gets compromised, anyone can read your past traffic. Also, just connecting to a server is enough to make it divulge some of your network traffic in encrypted form, no authentication needed. However, if your key does not get compromised, even a quantum attacker will be unable to read your traffic.

If you choose TLS, you have forward secrecy against regular adversaries if your key gets leaked, but you also have the guarantee that all your traffic will eventually be readable by anyone who is willing to store the encrypted form until they get a quantum computer. There is tls-auth, which will protect against attacks like Heartbleed by authenticating the TLS packets with HMAC, but it doesn't stop this attack (as the hardening page correctly points out).

To protect against this, I would like to propose tls-enc, which would encrypt the TLS traffic with a static key, just like tls-auth authenticates it. I think this idea was shot down as unnecessary in the past, but given the Snowden disclosures, the NSA announcing a soon-to-come push for quantum safe crypto, and the fact that this issue will disclose past traffic, I think this would be a valuable addition.

Like tls-auth, an implementation should not require replay protection, as this would be covered by the TLS layer, but there may be a risk that an attacker could use the server as an oracle to decrypt captured packets if there is a way for an attacker to reorder/replay packets that get fed into the TLS layer and elicit distinct responses depending on the content. I'm not sure if the OpenVPN protocol would allow that though.

The overhead should be minimal - since this only affects connection establishment, adding 8-16 bytes for an IV to each packet won't be too expensive, and tls-enc with AES-GCM could replace the HMAC in tls-auth, making it no more expensive than the status quo in terms of CPU.

Who is the right group/person to make the decision whether this is something that OpenVPN would like to implement, or whether this is something that OpenVPN would accept a patch for?

Traffic

janspambox wroteif your key does not get compromised, even a quantum attacker will be unable to read your traffic

As I understand it, a Quantum computer would be able to break any key as it considers all possible solutions ..
that is if you believe in fairy stories ..

janspambox

Nope. For symmetric crypto, they likely get an improvement that effectively halves the keylength, but won't break it completely.

janspambox

Filed in Trac as a feature wish, #633.

Traffic

janspambox wroteNope. For symmetric crypto, they likely get an improvement that effectively halves the keylength, but won't break it

my2c .. Don't exist: https://en.wikipedia.org/wiki/Quantum_computing