Popular culture, as in the movie The Imitation Game (2014), would have it that Alan Turing cracked the Enigma code almost singlehandedly, with the help of his computing machine, Christopher. As usual the truth is a little more complex, and the credit rather more distributed. Among the important breakthroughs which enabled the cracking was the capture of a set of encryption keys.

Sophisticated forms of encryption do not use a user-readable password, but generate from that (or other sources) an encryption key. Just as keeping passwords secret is a fundamental requirement for effective encryption, so keeping the key(s) secret is vital.

This is difficult enough when you want to encrypt files for local storage, but when you use encrypted communications – such as HTTPS or VPN – it becomes even more fraught. In these, the sender needs to tell the receiver the key to use for decryption, something which cannot be pre-arranged.

If, as part of the routine for making a VPN connection, your Mac sent the remote server the encryption key, then all that an eavesdropper would need to do would be to listen in during that initial key exchange, and they would be able to decrypt all subsequent traffic. Clearly key exchange is a process which needs to be rendered completely secure if encryption is going to be worthwhile.

Back in 1976, Whitfield Diffie and Martin Hellman, building on earlier work by Ralph Merkle, described a method of securely exchanging keys over a public network such as the Internet, and this is now known as Diffie-Hellman key exchange in their honour. It has become the standard technique, and is the basis of most encrypted communications schemes used by computers such as those in HTTPS and VPN.

I will not bore you with an account of the details of this key exchange (links provided give explicit information), but point out that it doesn’t actually involve sending any keys as such. Instead the systems send a sequence of numbers which are used to generate the keys. The properties of these numbers and the precise exchange ensure that anyone eavesdropping does not have sufficient information to generate their own key, but that the systems involved do.

Over the last nearly forty years, Diffie-Hellman key exchange has undergone intense analysis by many of the brightest minds in the world, and has stood up to their attacks. Although, like most things in cryptography, it can be cracked, the effort involved in doing so is great. So great that to all intents and purposes, when properly implemented, the technique is just not worth trying to break.

Some of the more puzzling claims made by Edward Snowden have been those about intelligence agencies such as the US NSA and the UK GCHQ being able to decrypt much encrypted communications on the Internet. However, the publication earlier this year of a paper by David Adrian and many others provided an explanation: Diffie-Hellman key exchange had not been cracked, as such, but weaknesses had been found in many implementations of it which could enable an eavesdropper to recover keys very quickly indeed – often in real time.

You can find an excellent and detailed explanation of this issue on Martijn Grooten’s Lapsed Ordinary blog. This account is so clear that it has been published in Ars Technica.

The upshot is that, earlier this year, nearly 20% of the most commonly used HTTPS servers and around 66% of VPN servers used vulnerable implementations of key exchange which could be cracked almost instantly. This became known by some as the Logjam vulnerability. Since then, many have been patched to fix Logjam, and should now be much more secure again.

As with a lot of things in intelligence, surveillance, and spying, this is a cat-and-mouse game. There are some very robust ways to implement key exchange, which are much more likely to require impractically large resources and long periods of time to crack. There are also some which are so vulnerable that they are now within reach of a well-prepared hacker.

For example, if your HTTPS or VPN is implemented using OpenSSL, using versions of OpenSSL prior to 1.0.2b or 1.0.1n is likely to expose this vulnerability. Apple has patched these successively during 2015, so that fully up to date installations of El Capitan should now be using OpenSSL 1.0.2d. You can check whether your browser uses HTTPS which is vulnerable by opening this page using that browser.

It is more difficult to check whether VPN connections made with a remote server are vulnerable to Logjam and related problems. If you are worried, then it is probably best to check with the VPN service provider: their support Q&A may already provide such information.

Even if you are running old software, or connecting to an unpatched server, it is still much safer to use HTTPS, VPN, or another means of encrypting your Internet traffic, which will prevent the casual eavesdropper from being able to capture bank account or other details from plain text packets.

If you want to protect yourself from attacks by organised criminals, then you should ensure that both ends – your Mac and the remote server – are using HTTPS, VPN and other encrypted protocols based on a robust key exchange, and free from Logjam, etc. This will also ensure that government intelligence agencies should find it much harder to discover the keys and decrypt your traffic.