VPN Encryption: The Complete Guide

A Virtual Private Network (VPN) encrypts all data as it travels between your computer and a VPN server. In this Complete VPN Encryption Guide, I take a detailed look at what encryption is, and how it is used in VPN connections.

Perhaps most importantly, I will explain the confusing array of encryption terms used by VPN services. This confusion is not helped by the fact that many VPN providers can be slapdash to the point of misleading when describing the encryption they use.

It is my aim that, after reading through this document, you will have a greater understanding of this complex subject. It is also my hope that you will have a much more critical eye when assessing the security claims made by VPN providers.

Grab a secure VPN today

Find a VPN with strong encryption through us

Unlock the internet with a VPN today


If you are unsure about what a VPN is and what one can do for you, please check out my VPNs for Beginners guide. In this article, I use the terms “computer” and “device” interchangeably. In doing so, I refer to any internet enabled device that is capable of running a VPN client. This includes desktop PCs, laptops, iPads, smartphones, and the like.

My aim is to present the key features of VPN encryption in as simple terms as possible. There is no getting away, however, from the fact that encryption is a horribly complex subject. It not for the technically faint of heart!

If even the term “encryption” causes your eyes to start glazing over, but you still want to know what to look out for in a good VPN service, you can jump straight to my summaries.

What Is Encryption?

“Begin at the beginning,” the King said, very gravely, “and go on till you come to the end: then stop.”― Lewis Carroll, Alice in Wonderland.

The simplest analogy is that encryption is a lock. If you have the correct key, then the lock is easy to open. If someone does not have the correct key but wants to access the contents of a strong box (that is, your data) protected by that lock, then they can try to break the lock.

In the same way that the lock securing a bank vault is stronger than the one securing a suitcase, some encryption is stronger than other encryption.

The Basics

When you were a kid, did you play the game in which you created a “secret message” by substituting one letter of the message with another? The substitution was made according to a formula picked by you.

You might, for example, have substituted each letter of the original message with one three letters behind it in the alphabet. If anyone else knew what this formula was, or was able to work it out, then they would be able to read your “secret message.”

In cryptography jargon, what you were doing was “encrypting” the message (data) according to a very simple mathematical algorithm. Cryptographers refer to this algorithm as a “cipher.” To decrypt it you need the key. This is a variable parameter which determines the final output of the cipher. Without this parameter, it is impossibble to decrypt the cipher.

If someone wants to read an encrypted message but does not have the key, then they must try to “crack” the cipher. When the encryption uses a simple letter substitution cipher, cracking it is easy. The encryption can be made more secure, however, by making the mathematical algorithm (the cipher) more complex.

You could, for example, substitute every third letter of the message with a number corresponding to the letter.

Encryption Key Length

Modern computer ciphers are very complex algorithms. Even with the help of supercomputers, these are very difficult to crack, if not impossible for all practical purposes. The crudest way to measure the strength of a cipher is by the complexity of the algorithm used to create it.

The more complex the algorithm, the harder the cipher is to crack using a brute force attack. This very primitive form attack is also known as an exhaustive key search. It basically involves trying every combination of numbers possible until the correct key is found.

As I’m sure we all know, computers perform all calculations using binary numbers:  zeros and ones. The complexity of a cipher is measured by its key size in bits – the raw number of ones and zeros necessary to express its algorithm, where each zero or one is represented by a single bit.

This is known as the key length, and also represents the practical feasibility of successfully performing a brute force attack on any given cipher.

The number of combinations possible (and therefore the difficulty to brute force them) increases exponentially with key size. Using the AES cipher (see later):

Encryption key size cominations

To put this into perspective:

  • In 2011 the fastest supercomputer in the word was the Fujitsu K. This was capable of an Rmax peak speed of 10.51 petaflops. Based on this figure, it would take Fujitsu K 1.02 x 10^18 – around one billion billion (one quintillion) – years to crack a 128-bit AES (Advanced Encryption Standard) key by force. This is older than the age of the universe (13.75 billion years).
  • The most powerful supercomputer in the world now (2017) is the Sunway TaihuLight in China. This beast is capable of a peak speed of 93.02 petaflops. This means that the most powerful computer in the world would still take some 885 quadrillion years to brute force a 128-bit AES key.
  • The number of operations required to brute force a 256-bit cipher is 3.31 x 10^65. This is roughly equal to the number of atoms in the universe!

Want more guides like this?

Sign up to the Newsletter today!

Newsletter sign up

Want more guides like this?

Sign up to the Newsletter today!

We promise never to share your email address, ever.

Computer Ciphers

While encryption key length refers to the amount of raw of numbers involved, ciphers are the mathematics – the actual formulas or algorithms – used to perform the encryption. As we have just seen, brute forcing modern computer ciphers is wildly impractical.

It is weaknesses (sometimes deliberate) in these cipher algorithms that can lead to encryption being broken. This is because no encryption key is completely random. They use pseudo random numbers which are themselves calculated using known algorithms. This creates a reduced set of possible outcomes, which in effect reduces the key length.

The Blowfish cipher, for example, is vulnerable to an attack that exploits the mathematics behind the birthday problem in probability theory. The study of weaknesses in cryptographic algorithms is known as cryptoanalysis.

Longer key lengths compensate for such weaknesses, as they greatly increase the number of possible outcomes.

Cipher Key Length

How strong a cipher is depends on both the mathematics of the cipher itself, plus its key length as expressed in bits. For this reason, ciphers are usually described along with the key length used.

So AES-256 (the AES cipher with a 256-bit key length) is usually considered stronger than AES-128. Note that I say usually because we are dealing with very complex mathematics here (see my notes on AES later).

It is important to note that key length alone is not a good indicator of a cipher’s strength. It is the combination of key length and cipher that matters. Ciphers used for asymmetric encryption, for example, use much longer key sizes than those used for symmetric encryption to provide the equivalent protection.

This table is a little out of date, as it does not take into consideration newer attacks that have been discovered on RSA. It is also worth noting that elliptic curve and Diffie-Hellman variants of RSA are much stronger than traditional ones. But hopefully you get the idea.

One thing to note is that the higher the key length, the more calculation involved, so the more processing power needed. This impacts the speed at which data can be encrypted and decrypted. VPN providers and suchlike must, therefore, decide how best to balance security vs. practical usability when choosing encryption schemes.

I will discuss the main ciphers used by various VPN protocols a little later. By far the most common ciphers that you will likely encounter with regards to VPNs are Blowfish and AES. In addition to this, RSA is used to encrypt and decrypt a cipher’s keys, and SHA-1 or SHA-2 is used as the hash function to authenticate data.

Asymmestric encryption

Asymmetric encryption

Grab a secure VPN today

Find a VPN with strong encryption through us

Unlock the internet with a VPN today

Perfect Forward Secrecy

Perfect Forward Secrecy (PFS) is also referred to as using ephemeral encryption keys, or just Forward Secrecy (FS) by those uncomfortable with using the word “perfect.”

Most modern secure online communication relies on SSL/TLS. It is used by HTTPS websites and the OpenVPN protocol. TLS (Transport Layer Security) is an asymmetric encryption protocol. Using an asymetric cipher means that data is secured using a public key, which is made available to everyone. It can only be decrypted, however, by an intended recipient who holds the correct private key.

This private key must be kept secret. If it is stolen or cracked by an adversary, then that adversary can easily intercept and read any communications secured by it.

Unfortunately, it is common for servers or even entire companies to use just one private encryption key to secure all communications. Why? Because it’s easy. However, if that key is compromised, then the attacker can access all communications encrypted with it.

This private encryption key, therefore, becomes a “master key” that can be used to unlock all communications with a server or company. The NSA is known to have exploited this weakness in order to collect vast reams of supposedly secure data.

The solution is Perfect Forward Secrecy. This is a system whereby a new and unique private encryption key is generated for each session. It is a simple idea, even if the Diffie-Hellman exchange maths is complex. It means that each TLS session has its own set of keys. Hence the term “ephemeral keys” – they are used once and then disappear.

There is, therefore, no “master key” that can be exploited. Even if a session is compromised, it is only that session that is compromised – not all the other sessions anybody has with that server or company!

Although uncommon, it is even possible to refresh PFS keys within a session (for example, every hour). This further limits the amount of data that can be intercepted by an adversary, even if a private key is compromised.

When I wrote this article on the subject a few years ago, use of Perfect Forward Secrecy for both HTTPS websites and OpenVPN connections was woefully rare. Fortunately, this situation has changed somewhat. Although by no means universal, use of ephemeral keys has greatly increased of late.

VPN Encryption

VPN Protocols

A VPN protocol is the set of instructions (mechanism) used to negotiate a secure encrypted connection between two computers. A number of such VPN protocols are commonly supported by commercial VPN services. The most notable of these are PPTP, L2TP/IPSec, OpenVPN, SSTP, and IKEv2.

I look at each of these below, but OpenVPN is now the industry standard VPN protocol used by commercial VPN services – for good reason. It is very secure and can be used on almost all VPN-capable devices. I will, therefore, spend additional digital ink discussing OpenVPN in detail.

Want more guides like this?

Sign up to the Newsletter today!

Newsletter sign up

Want more guides like this?

Sign up to the Newsletter today!

We promise never to share your email address, ever.


  • ProsPROS
  • Client built in to just about all platforms
  • Very easy to set up
  • ConsCONS
  • Very insecure
  • Definitely compromised by the NSA
  • Easily blocked

Point-to-Point Tunneling Protocol (PPTP) was developed by a consortium founded by Microsoft for creating VPN over dial-up networks. As such, PPTP has long been the standard protocol for corporate VPN networks.

It is a VPN protocol only, and relies on various authentication methods to provide security. Among commercial VPN providers, this is almost invariably MS-CHAP v2. The encryption protocol (similar to a standard cipher) used by PPTP is Microsoft Point-to-Point Encryption (MPPE).

PPTP is available as standard on just about every VPN-capable platform and device. It is easy to set up, without the need to install additional software. This ensures that PPTP remains a popular choice both for business VPNs and commercial VPN services.

It also has the advantage of requiring a low computational overhead to implement… so it’s quick!

Unfortunately, PPTP is not secure. At all. Although now usually only found using 128-bit encryption keys, in the years since it was first bundled with Windows 95 OSR2 back in 1999, a number of security vulnerabilities have come to light.

The most serious of these is the possibility of un-encapsulated MS-CHAP v2 Authentication. Using this exploit, PPTP has been cracked within two days. Microsoft has patched the flaw, but has itself issued a recommendation to use L2TP/IPsec or SSTP instead.

It should therefore come as no surprise that the NSA almost certainly decrypts PPTP encrypted communications as standard. Even more worrying is that the NSA collected vast amounts of older data that was encrypted back when PPTP was considered secure. It can almost certainly decrypt this legacy data as well.

PPTP requires both TCP port 1723 and the GRE protocol. It is easy to firewall GRE, which makes it easy to block PPTP connections.

Summary: Avoid. Only use if absolutely necessary for compatibility.


  • ProsPROS
  • Usually considered secure (but see Cons)
  • Easy to set up
  • Available on all modern platforms
  • Faster than OpenVPN (maybe)
  • ConsCONS
  • May be compromised by the NSA (unproven)
  • Likely deliberately weakened by the NSA (unproven)
  • Can struggle with restrictive firewalls
  • Often implemented badly

Layer 2 Tunneling Protocol (L2TP) is built in to almost all modern operating systems and VPN-capable devices. It is therefore just as easy and quick to set up as PPTP.

On its own, L2TP does not provide any encryption or confidentiality to traffic that passes through it, so it is usually implemented with the IPsec authentication suite (L2TP/IPsec). Even if a provider only refers to either L2TP or IPsec (as some do), it almost certainly actually means L2TP/IPSec.

L2TP/IPsec can use either the 3DES or AES ciphers. 3DES is vulnerable to Meet-in-the-middle and Sweet32 collision attacks, so in practice you are unlikely to encounter it these days.

Problems can arise because the L2TP/IPSec protocol uses only a limited number of ports. This can this cause complications when used behind NAT firewalls. This reliance on fixed ports also makes the protocol fairly easy to block.

L2TP/IPsec encapsulates data twice, which slows things down. This is offset by the fact that encryption/decryption occurs in the kernel and L2TP/IPsec allows multi-threading. OpenVPN does not. The result is that L2TP/IPsec is theoretically faster than OpenVPN.

L2TP/IPsec using the AES cipher has no major known vulnerabilities, and if properly implemented may still be secure. However, Edward Snowden’s revelations have strongly hinted at the standard being compromised by the NSA.

John Gilmore is a security specialist and founding member of the Electronic Frontier Foundation. As he explains in this post, it is likely that IPSec was deliberately weakened during its design phase.

An arguably much bigger problem is that many VPN services implement L2TP/IPsec poorly. Specifically, they use pre-shared keys (PSKs) that can be freely downloaded from their websites.

These PSKs are only used to authenticate the connection, so even if compromised, the data remains securely encrypted using AES. An attacker could, however, use the pre-shared key to impersonate a VPN server. It could then eavesdrop on encrypted traffic, or even inject malicious data into the connection.

Summary: Despite some largely theoretical issues, L2TP/IPsec is generally regarded as being secure if openly published pre-shared keys are not used. Its built-in compatibility with a great many devices can make it a very good choice.


  • ProsPROS
  • Very secure
  • Completely integrated into Windows
  • Microsoft support
  • Can bypass most firewalls
  • ConsCONS
  • Proprietary standard owned by Microsoft

Secure Socket Tunneling Protocol (SSTP) was introduced by Microsoft in Windows Vista SP1. Although it is now available for Linux, and even Mac OS X, it is still primarily a Windows-only platform.

SSTP uses SSL 3.0, and therefore offers similar advantages to OpenVPN. This includes the ability to use to TCP port 443 to evade censorship. Tight integration with Windows can make it easier to use and more stable than OpenVPN on that platform.

Unlike OpenVPN, however, SSTP is a proprietary standard owned by Microsoft. This means that the code is not open to public scrutiny. Microsoft’s history of cooperating with the NSA, and speculation about possible backdoors built in to the Windows operating system, do not inspire confidence in the standard.

Another issue is that SSL v3.0 is vulnerable to what is known as the POODLE attack, and now therefore not recommended. Whether this issue also affects SSTP is unclear, but again, hardly inspires confidence.

Summary: On paper, SSTP offers many of the advantages of OpenVPN. Being a proprietary Microsoft standard, however, badly undermines its credibility.


  • ProsPROS
  • Fast
  • Stable – especially when switching network or reconnecting after a lost internet connection
  • Secure (if AES is used)
  • Easy to set up (at least at the user-end!)
  • Protocol is supported on Blackberry devices
  • ConsCONS
  • Not supported on many platforms
  • Implementing IKEv2 at the server-end is tricky, which is something that could potentially result in issues developing
  • Only trust open source implementations

Internet Key Exchange version 2 (IKEv2) was jointly developed by Microsoft and Cisco. It is natively supported by Windows 7+, Blackberry, and iOS devices.

Independently developed compatible versions of IKEv2 have been developed for Linux and other operating systems. Many of these iterations are open source. As always, I suggest being wary of anything developed by Microsoft. Open source versions of IKEv2, however, should have no issues.

Strictly speaking, IKEv2 is a tunneling protocol only. It only becomes a VPN protocol when paired with an authentication suite such as IPSec. This could best be described as IKEv2/IPsec… but never is.

Dubbed VPN Connect by Microsoft, IKEv2 is particularly good at automatically re-establishing a VPN connection when users temporarily lose their internet connections. For example when entering or leaving a train tunnel.

Because of its support for the Mobility and Multihoming (MOBIKE) protocol, IKEv2 is also highly resilient to changing networks. This makes IKEv2 a great choice for cell phone users who regularly switch between home WiFi and mobile connections, or who regularly move between hotspots.

IKEv2 is not as common as L2TP/IPSec, as it is supported on many fewer platforms. It is, however, considered at least as good as, if not superior to, L2TP/IPsec in terms of security, performance (speed), stability and the ability to establish (and re-establish) a connection.

Grab a secure VPN today

Find a VPN with strong encryption through us

Unlock the internet with a VPN today

Summary: IKEv2 is a secure and fast protocol. Mobile users may even prefer it to OpenVPN thanks to its improved ability to reconnect when an internet connection is interrupted. For Blackberry users, it is pretty much the only option available. Open source iterations are to be preferred.


  • ProsPROS
  • Very secure (if PFS is used)
  • Highly configurable
  • Open source
  • Can bypass firewalls
  • ConsCONS
  • Needs third party software

OpenVPN is an open source technology that uses the OpenSSL library and TLS protocols, along with an amalgam of other technologies, to provide a strong and reliable VPN solution. It is now the industry standard VPN protocol used by commercial VPN services – for good reason.

One of OpenVPN’s major strengths is that it is highly configurable. It is natively supported by no platform, but is available on most platforms via third party software. Custom OpenVPN clients and apps are often available from individual VPN providers, but the core open source code is developed by the OpenVPN project.

Many developers and contributors to the OpenVPN project also work for OpenVPN Technologies Inc., which overseas the project.

OpenVPN runs best on a UDP port, but it can be set to run on any port (see notes later). This includes TCP port 443, which is used by regular HTTPS traffic. Running OpenVPN over TCP port 443 makes it hard to tell VPN connections apart from the kind of secure connections used by banks, email services, and online retailers. This makes OpenVPN very hard to block.

Another advantage of OpenVPN is that the OpenSSL library used to provide encryption supports a number of ciphers. In practice, however, only Blowfish and AES are commonly used by commercial VPN services. I discuss these below.

In light of information obtained from Edward Snowden, it seems that as long as Perfect Forward Secrecy is used, then OpenVPN has not been compromised or weakened by the NSA.

A recent crowdsourced audit of OpenVPN is now complete, as is another one funded by Private Internet Access. No serious vulnerabilities that affect the privacy of users were discovered. A couple of vulnerabilities were discovered that made OpenVPN servers potentially open to a Denial of Service (DoS) attack, but these have been patched in OpenVPN 2.4.2.

OpenVPN is usually regarded as the most secure VPN protocol available and is widely supported across the VPN industry. I will, therefore, discuss OpenVPN encryption in detail below.

Summary: If implemented well, OpenVPN is arguably the most secure and versatile VPN protocol available. My general recommendation is to use OpenVPN whenever possible.

OpenVPN Encryption

OpenVPN encryption comprises two parts – data channel encryption and control channel encryption.

Data channel encryption is used to secure your data. Control channel encryption secures the connection between your computer and the VPN server.

As an analogy, think of a VPN connection as a road that connects your device to the VPN server. Along this road travel cars (packets of data) which are each protected by a layer of armor. This armor is the data channel encryption.

In addition to this, the entire road runs through a tunnel which is also armored. This outer layer of armor is the control channel encryption. This means that to access your data, an adversary would first have to compromise the control channel encryption (break into the tunnel). He or she would then have to crack the data channel encryption (the armor round each car).

Data encryption is therefore a second line of defense. Strong control channel encryption should, in theory, make it impossible to even get to the data encryption. For maximum security, both the data and control channel encryption should be as strong as possible.

However, the stronger the encryption used, the slower the connection will be. Many VPN providers therefore use strong control channel encryption, but less strong data channel encryption. I regard this as an acceptable security/performance compromise.

OpenVPN Ecryption

Control channel encryption is also called TLS encryption because TLS is the technology used to securely negotiate the connection between your computer and the VPN server. This is the same technology used by your browser to securely negotiate a connection to an HTTPS-encrypted website.

  • Control channel encryption consists of a cipher (the tunnel armor in the above analogy), handshake encryption and hash authentication.
  • Data channel encryption consists of a cipher (car armor) and hash authentication.

OpenVPN Encryption
Data Auth
Control Auth
Forward Secrecy
Logs & Legal

VPN providers often use the same level of encryption for both control and data channels. In our reviews and “traffic light” tables, we only list them separately if different values are used for each channel.

If we state that a provider uses an AES-256 cipher, this means that an AES-256 cipher is used for both the control and data channels.*

(*This should be the case, at least. Some legacy reviews do not meet our current guidelines, but these should be phased out in time).

Want more guides like this?

Sign up to the Newsletter today!

Newsletter sign up

Want more guides like this?

Sign up to the Newsletter today!

We promise never to share your email address, ever.


OpenVPN can use a number of symmetric-key ciphers in order to secure data on both control and data channels. In practice, the only ones used by commercial VPN providers are Blowfish, AES, and (very rarely) Camellia.


Blowfish-128 is the default cipher used by OpenVPN. Key sizes can in theory range from 32 bits to 448 bits, but Blowfish-128 is the only version you are likely to encounter in the wild.

Blowfish is often considered secure enough for casual purposes, but has known weaknesses. It was created by renowned cryptographer Bruce Schneier, who in 2007 said, “at this point, though, I’m amazed it’s still being used.”

In my view, use of Blowfish-128 is acceptable as a second line of defense on the OpenVPN data channel. It should not, however, be considered secure when used on the control channel.


AES has become the VPN industry-wide “gold standard” symmetric-key cipher. AES is NIST-certified and is almost universally considered very secure. AES-256 is used by the US government for protecting “secure” data.

The fact that it has a 128-bit block size rather than Blowfish’s 64-bit block size also means that it can handle larger files (over 4 GB) better than Blowfish. In addition to this, the AES instruction set benefits from built-in hardware acceleration on most platforms.

AES is usually available in 128-bit and 256-bit key sizes (192-bit AES also exists). AES-128 remains secure as far as anyone is aware. Given what we now know about the extent of the NSA’s assault on encryption standards, however, most experts agree that AES-256 provides a higher security margin.

Just to ensure that no-one ever finds this subject too easy, though, there is some debate on this issue. AES-128 has a stronger key schedule than AES-256, which leads some very eminent experts to argue that AES-128 is actually stronger than AES-256.

The general consensus, however, is that AES-256 is stronger.


Camellia is a modern secure cipher and is at least as secure and quick as AES. It is available in key sizes of 128, 192 and 256 bits. Thanks to NIST certification and its use by the US government, however, AES is almost always used instead of Camellia.

But as I discuss below, there are reasons to not trust NIST-certified ciphers. The fact that Camellia is a non-NIST cipher is the main reason to choose it over AES. This option is only rarely available, however.

It is also worth noting that Camellia is not nearly as well-tested for weakness as AES.

Handshake Encryption

In order to securely negotiate a connection between your device and a VPN server, OpenVPN uses a TLS handshake. This allows the OpenVPN client and VPN server to establish the secret keys with which they communicate.

To protect this handshake, TLS usually uses the RSA public-key cryptosystem. This is an encryption and digital signature algorithm used to identify TLS/SSL certificates. It can, however, also use a Diffie-Hellman or ECDH key exchange instead.


RSA is an asymmetric encryption system – a public key is used to encrypt the data, but a different private key is used to decrypt it. It has been the basis for security on the internet for the last 20 years or so.

It is now well-established that RSA with a key length of 1024-bits (RSA-1024) or less is not secure, and has almost certainly been cracked by the NSA. There has consequently been a concerted move among internet companies to migrate away from RSA-1024.

Unfortunately, we still that find some VPN services continue to use RSA-1024 to protect handshakes. This is not good.

RSA-2048 and higher is still considered secure. On its own, RSA does not provide Perfect Forward Secrecy (PFS). This can, however, be implemented by including a Diffie-Hellman (DH) or Elliptic curve Diffie-Hellman (ECDH) key exchange in its cipher suite.

In this case, the strength of the DH or ECDH key does not matter as it is being used only to provide Perfect Forward Secrecy. The connection is secured using RSA.

Because it can cause confusion, I’ll also note that the RSA cryptosystem has nothing to do with the disgraced US tech firm RSA Security LLC. This company deliberately weakened its flagship BSAFE encryption products after being bribed $10 million by the NSA.

Diffie-Hellman and ECDH

An alternative (rival) handshake encryption that is sometimes used by OpenVPN is the Diffie-Hellman (DH) cryptographic key exchange. This has a minimum key length of 4096-bits.

The main advantage of a Diffie-Hellman handshake over RSA is that it natively provides Perfect Forward Secrecy. As already noted, however, simply adding a DH key exchange to an RSA handshake achieves a similar end.

Diffie-Hellman has caused huge controversy over its re-use of a limited set of prime numbers. This makes it vulnerable to being cracked by a powerful adversary, such as the NSA. Diffie-Hellman on its own, therefore, does not make for secure handshake encryption. It is fine, however, when used as part of an RSA cipher suite.

Elliptic curve Diffie-Hellman (ECDH) is a newer form of cryptography that is not vulnerable to this attack. This is because it uses the properties of a particular type of algebraic curve instead of large prime numbers to encrypt connections.

ECDH can be used as part of an RSA handshake to provide Perfect Forward Secrecy, or can securely encrypt a handshake on its own (with an ECDSA signature). This also provides PFS.

ECDH key length starts at 384-bits. This is considered secure, but when used on its own to secure a TLS handshake, the longer the better (in terms of security, anyway).

Grab a secure VPN today

Find a VPN with strong encryption through us

Unlock the internet with a VPN today

SHA Hash Authentication

This is also referred to as data authentication or hash message authentication code (HMAC).

Secure Hash Algorithm (SHA) is a cryptographic hash function used (among other things) to authenticate data and SSL/TLS connections. This includes OpenVPN connections.

It creates a unique fingerprint of a valid TLS certificate, which can be validated by any OpenVPN client. Even the tiniest change is detectable. If the certificate is tampered with, this will immediately be detected and the connection refused.

This is important in preventing a Man-in-the-middle (MitM) attack, where an adversary attempts to divert your OpenVPN connection to one of its own servers instead of your VPN provider’s. It could do this, for example, by hacking your router.

If an adversary can crack the hash of your provider’s genuine TLS certificate, it can reverse the hash to create a forged certificate. Your Open VPN software would then authenticate the connection as genuine.

Is SHA Secure?

When used to protect HTTPS websites, SHA-1 is broken. This has been known about for some time. SHA-1 websites can still be found, but are being phased out. Most browsers will now issue a warning when you try to connect to a website secured with SHA-1.

SHA-2 and SHA-3 hash functions are now recommended instead, and are secure. SHA-2 includes SHA-256, SHA-384, and SHA-512. However…

OpenVPN only uses SHA for HMAC. I don’t think it useful to go into too much detail here, but SHA hash authentication is only one component of the HMAC algorithm. Indeed, to even get to the SHA-1 hash function you would first need to launch a successful attack on HMAC itself.

In other words, HMAC SHA-1 as used by OpenVPN is considered secure. Mathematical proof of this is available here. Of course, HMAC SHA-2 and HMAC SHA-3 are even more secure! Indeed, the recent OpenVPN audit recognizes that HMAC SHA-1 is secure, but nevertheless recommends transitioning to HMAC SHA-2 or HMAC SHA-3 instead.



AES, RSA, SHA-1 and SHA-2 were all developed and/or certified by the United States National Institute of Standards and Technology (NIST). This is a body that by its own admission works closely with the NSA in the development of its ciphers.

Given what we now know of the NSA’s systematic efforts to weaken or build backdoors into international encryption standards, there is every reason to question the integrity of NIST algorithms.

NIST, of course, strongly refutes such allegations:

NIST would not deliberately weaken a cryptographic standard.

It has also invited public participation in a number of upcoming proposed encryption standards, in a move designed to bolster public confidence.

The New York Times, however, accused the NSA of circumventing NIST-approved encryption standards by either introducing undetectable backdoors or subverting the public development process to weaken the algorithms.

This distrust was further bolstered when RSA Security (a division of EMC) privately told customers to stop using an encryption algorithm that reportedly contains a flaw engineered by the NSA. This algorithm had also been endorsed by NIST.

Furthermore, Dual_EC_DRBG (Dual Elliptic Curve Deterministic Random Bit Generator) is an encryption standard engineered by NIST. It has been known to be insecure for years.

In 2006 the Eindhoven University of Technology in the Netherlands noted that an attack against it was easy enough to launch on “an ordinary PC.” Microsoft engineers also flagged up a suspected backdoor in the algorithm.

Despite these concerns, where NIST leads, the industry follows. Microsoft, Cisco, Symantec, and RSA all include the algorithm in their product’s cryptographic libraries. This is in large part due to the fact that compliance with NIST standards is a prerequisite to obtaining US government contracts.

NIST-certified cryptographic standards are pretty much ubiquitous worldwide, throughout all areas of industry and business that rely on privacy. This makes the whole situation rather chilling.

Perhaps precisely because so much relies on these standards, cryptography experts have been unwilling to face up to the problem.

Block Cipher Mode (CBC)

Pretty much all commercial VPN providers use the Cipher Block Chaining (CBC) block cipher mode for OpenVPN ciphers. You may, for example, see something like AES-256-CBC.

Although CBC may theoretically have some vulnerabilities, the general consensus is that CBC is secure. CBC is, indeed, recommended in the OpenVPN manual.

As you are unlikely to encounter any other block cipher mode anyway, CBC is not something really worth worrying about.


OpenVPN can run over TCP (Transmission Control Protocol) or UDP (User Datagram Protocol).

  • TCP = reliable. Whenever a computer sends a network packet using TCP, it waits for confirmation that the packet has arrived before sending the next packet. If no confirmation is received, it will resend the packet. This is known as error-correction. There is “guaranteed delivery” of all data, but it can be quite slow.
  • UDP = fast. Using UDP, no such error correction is performed. Packets are simply sent and received with no acknowledgments or retries. This makes UDP much faster than TCP, but less reliable.

If given the choice, I suggest using the faster UDP protocol unless you experience connection problems. This is the default strategy adopted by most VPN providers.

Defeat Censorship with OpenVPN on TCP Port 443

One of the great advantages of OpenVPN is that it can be run over any port, including TCP port 443. This is the port used by HTTPS, the encrypted protocol that secures all secure websites.

Without HTTPS, no form of online commerce, such as shopping or banking, would be possible. It is therefore very rare for this port to be blocked.

As an added bonus, VPN traffic on TCP port 443 is routed inside the TLS encryption used by HTTPS. This makes it much harder to spot using advanced Deep Packet Inspection techniques. TCP port 443 is therefore the favored port for evading VPN blocks.

Many VPN providers offer the ability to change the port number used by OpenVPN using their custom software.

Even if yours does not, many VPN providers do actually support OpenVPN using TCP port 443 at the server level. You can switch to it with a simple edit to your OpenVPN configuration (.ovpn) file. It is, therefore, worth asking your VPN provider about this.

SSTP uses TCP port 443 by default.


VPN Protocols

  • PPTP is very insecure and should be avoided. While its ease of setup and cross-platform compatibility are attractive, L2TP/IPsec has the same advantages and is much more secure.
  • L2TP/IPsec is a good VPN solution for non-critical use. This is especially true on legacy devices that do not support OpenVPN. It has, however, been severely compromised by the NSA.
  • SSTP offers most of the advantages of OpenVPN, but is primarily only a Windows protocol. This does mean that it is better integrated into the OS, but it is poorly supported by VPN providers thanks to this limitation. In addition to this, its proprietary nature and the fact that is was created by Microsoft mean that I, for one, don’t trust it.
  • IKEv2 is a very good (secure and fast) protocol. Mobile users, in particular, may even prefer it to OpenVPN due to its improved ability to reconnect when an internet connection is interrupted. For Blackberry users, it is pretty much the only option available. Use open source versions where possible.
  • OpenVPN is the recommended VPN protocol under most circumstances. It is fast, reliable, secure, and open source. It has no real downsides, per se., but to be truly secure it is important that it is implemented well. This means use of strong encryption with Perfect Forward Secrecy.

OpenVPN Encryption

When it comes to encryption, the devil is in the detail. It is common to see VPNs providers say they use “ultra-strong 256-bit” AES OpenVPN encryption, but this does not, in reality, tell us very much. AES-256 is indeed a strong cipher, but if other aspects of the encryption suite used are weak, then your data will not be secure.

  • Cipher – this protects your actual data. AES-256 is now the industry standard, and is recommended.
  • Handshake – this secures your connection to the VPN server. RSA-2048+ or ECDH-384+ are secure. Importantly RSA-1024 and Diffie-Hellman handshakes are not.
  • Hash authentication – creates a unique fingerprint, which is used to validate data and TLS certificates (that is, to check that the server you are connecting to really is the one you think you are connecting to). HMAC SHA-1 is absolutely fine, but HMAC SHA-2 (SHA-256, SHA-384, and SHA-512) and HMAC SHA-3 are even more secure!
  • Perfect Forward Secrecy (PFS) – this ensures that new encryption keys are created for each session. OpenVPN should not be considered secure unless PFS is implemented. This can be done either by including a Diffie-Hellman or ECDH key exchange in an RSA handshake, or a DH or ECDH handshake.
  • Control channel encryption is more important than data channel encryption because to get to the data channel, the control channel encryption must be compromised first.
  • Using higher bit lengths for ciphers and keys is almost always more secure, but this comes at a cost in speed.

OpenVPN will negotiate ciphers between client and server at will. Unless very specific parameters are defined OpenVPN may default to weak settings. At minimum, OpenVPN will default to Blowfish-128 cipher, RSA-1024 handshake with no PFS, and HMAC SHA-1 hash authentication.

Want more guides like this?

Sign up to the Newsletter today!

Newsletter sign up

Want more guides like this?

Sign up to the Newsletter today!

We promise never to share your email address, ever.


Whew! Hopefully you now have a better understanding of what makes for a secure VPN connection. When it comes to properly configuring a VPN, however, encryption is only half the story. The other half is ensuring that no traffic enters or leaves your computer outside of the VPN connection.

To learn more about this, please check out my Complete Guide to IP Leaks.

Douglas Crawford I am a freelance writer, technology enthusiast, and lover of life who enjoys spinning words and sharing knowledge for a living. You can now follow me on Twitter - @douglasjcrawf.

Related Coverage

18 responses to “VPN Encryption: The Complete Guide

  1. Thanks Guys, jonah84’s question and follow up’s answered my main worries about a vpn too. A lot of info to absorb at once for sure. I get where he was coming from as I have some dated technical savvy/mind. Might be valuable to dumb this down for the average user in a paragraph.
    Thanks HEAPS for the info Douglas .. I’ll be giving this link to a lot of my friends.

  2. Hello. Great article. AES-GCM is “common” since the upgrades to OpenVPN 2.4. From a 2 year old Asus router with the latest Merlin firmware to an Android smartphone with OpenVPN for Android to a commercial VPN service from ProtonVPN. Its all around me in just over a month now. Sounds like it accomplishes the same as AES-CBC with less load on resources along the way. Making it a useful addition in resource tight environments like smartphones and cpu limited routers. So if you have time to update the article some day it would be a welcome addition. Many thanks for a great job on a difficult topic.

    A good follow on article might explain what options exist for obfuscating VPN traffic generated in Android or Windows environments and carrying VOIP and also browser traffic from deep packet inspection at run of the mill free hotspots operated by chain stores. I have notice that in recent months it has become more common to attempt to block VPN traffic that carries VOIP traffic than it was say a year ago while allowing browser traffic. Perhaps this is due to the sudden availability of more sophisticated DPI equipment?

    1. Hi Edward,

      Ha ha. Fair enough. I am taking an extended summer break soon, but will update this article with info GCM when I return. DPI and VoIP specifically is an interesting subject, and one that is a great article recommendation. For the time being you may be interested in checking out How to Bypass VPN Blocks – A Guide, which at least partially covers this topic.

  3. Hi Douglas,

    Your section on Encryption Key Length discusses brute force techniques to crack encryption, detailing e.g. 1 quintillion years to crack AES-128 with current tech.

    However, with the advent of quantum computers, experts suggest that these keys will be cracked with ease, in minimal timeframes.

    More info:

    Just sayin.

    1. Hi Joanna,

      It is indeed widely speculated that quantum computers will be able to effortlessly decrypt almost all modern encryption algorithms. And this is a big problem. I decided not to mention it in this article because quantum computers capable of doing this on any useful scale do not yet exist – and when they do, pretty much all bets are off when it comes to encryption. Post-quantum cryptography is such a new field of study that I did not think it useful to discuss here (I will think on this, and may at least add a paragraph mentioning the issue).

      Interestingly, according to Wikipedia, “In contrast to the threat quantum computing poses to current public-key algorithms, most current symmetric cryptographic algorithms and hash functions are considered to be relatively secure against attacks by quantum computers.” This suggests that while the TLS key exchange used by, for example, OpenVPN, will be vulnerable to quantum decryption, the AES cipher (a symmetric cipher) and SHA2 and 3 may remain secure.

  4. Hi Douglas,
    Let me if i may, get straight to the point. This is a hypothetical situation, but i am having some difficulty in understanding exactly what is happening.
    1)Lets say, i pay for and install an OpenVPN client from a reputed VPN provider, like PIA.
    2)I have it configured properly, with recommended encryption, using the UDP protocol, and this client app then connects over port 1197 (or 1194) to the VPN server, lets say located in Sweden.
    3)Now, i want to download a linux distro, like an Ubuntu ISO from an online filehosting site, like, and the size of the file is 900MB.
    4)So, when i make the get request from my browser to connect to rapidgators servers say in Germany, the file is requested over normal http from the server in Sweden on my behalf, and the rapidgator server in Germany proceeds to send the data back to the PIA Swedish server in http.
    5)Then my VPN server sends off the file to my IP say in Delhi via the secure encrypted tunnel between my home and the Sweden server, making it undecipherable to my ISP and/or anyone wanting to do a MITM attack.
    6)My ISP of course knows how much data traversed encrypted from the Sweden server to my home IP, but doesnt know the contents (although it could guess its not text files!)
    7)DPI probably is of little use along the way from the VPN server to me the client, because the data to and from the VPN server to me is AES256 bit encrypted.
    8)My question is, if someone is watching passively from outside at the VPN server, is seeing all of PIA’s clients connected to it in Sweden, and lets say i am 1 out of 500 others.
    9)Now this entity watching the traffic, sees that a ACK request from rapidgator german server is coming in, and then sees encrypted traffic from this Sweden server heading out (to my destination).
    10)If there are 11 hops between my real physical location IP and my Virtual Private IP, can this entity sniffing at the PIA sweden server see the end destination, that is my IP? Or does it just see the first hop out to get to me, and not the final destination on my PC?
    11) Because if the entity is seeing my IP at the end, then i would think that defeats the purpose, if indeed such traffic analysis is possible where the MITM entity can isolate my traffic out of the remaining 499 connected users, and also follow the data trail from rapidgators servers to my PC.
    Is this a reasonable capability for someone like the NSA, or does the math of the encryption, data authentication and strong RSA handshake make it not a candidate for passive decryption?

    I am sorry for taking up so much of your time making you read all this, but it was a question that i thought you certainly can shed some light on.

    Warm regards,

    1. Hi Jonah,

      Traffic analysis (also known as an end-to-end timing attack) of the kind you describe is possible, but is hard. It does, however, require a very targeted and time consuming operation to perform. You would therefore have to be of very specific interest to a powerful organization such as the NSA for this to be a significant threat.

      If this is your threat model (for I hope purely theoretical purposes), then you may wish to consider combining VPN with Tor for further obfuscation.

      Most importantly, an adversary would probably need to already suspect you, and know your real IP address for this to work. Note that use of shared IPs makes it very difficult (if not impossible) for an adversary to prove anything using such techniques, although they can be used to provide supporting evidence in court.

      I should also note that I am only talking about connecting your data with the first router hop in the chain you mention. I don’t really understand how this 10 hop router chain you describe works, so cannot comment on how easy it would be to trace data through the chain. You may, however, find Tor a better solution here.

    2. Thanks for the prompt reply Douglas and your thoughtful response.
      Yes my imagined threat model is the NSA that i keep reading about everywhere from arstechnica to der spiegel, just as a fun and educational scenario nothing more.
      Im a layman when it comes to understanding how the internet works, so my question is more of trying to understand how this OpenVPN technology functions to keep its users safe, although the more technical details are over my head.

      As far as the “hops” i mentioned, so you know how when we do a tracert to for example, how those intermediary routers come up as hops till you finally reach the server/s hosting, thats what i meant with that.

      Essentially, the routers along the way, passing along my encrypted packets from the swedish PIA server to my destination in say Mumbai, are they able to see my real IP address?
      As i understand the theory, Layer 2 is what the routers see and send on the packet to the next router in the path to the destination, but they dont change layer 3 which is where the 2 endpoints, ie my ip and the swedish server ip rests.

      What stops the routers in the route to me, to observe the layer 3 aka network layer and see that all these encrypted packets are destined to me?

      1. Hi jonah84,

        Please bear in mind that I not a network engineer. It is my understanding that yes- in order to deliver a packet to the correct destination, an iPv4 or IPv6 packet payload contains both the source IP and the destination IP. These are read by each successive router (host/remote node) in the route (path) in order to deliver the packet where it is supposed to go. Using OpenVPN does nothing to hide the route of you data between your computer and the VPN server. Your ISP, for example, can clearly see that you are connected to VPN specific server.

        Using a VPN, however, hides the content of you data. And if using shared IP addresses, it makes it very difficult to tie what the content of that data is with any specific activity on the internet. So for example, if I visit while connected to my VPN service, the NSA would easily work out that I am using a VPN service. They could then try to try find me by monitoring all users who connect to that server’s IP address, and matching the times I connect to the times that I am detected accessing

        But lots of people are using that ip – connecting and disconnecting to it all the time, so this is difficult. It is also made all the more so by the fact that I connect to my VPN as a matter of routine -so correlating the times I connect to the VPN and when I visit will be very hard. And assuming that others VPN users sharing that ip do the same thing, proving anything becomes very arduous.

    3. I do understand a little more now Douglas, thanks! Basically, these days in the era of ubiquitous encryption, traffic analysis is where the genius of the NSA/Intelligence agency is at, because its no longer feasible to simply break the encryption i suppose.
      On stackexchange and other forums you frequently read about security experts advising the advantages of a downloading a reputable commercial VPN client instead of setting up your own instance of a VPS simply for the reasons you mentioned. Since you are the only one on the VPS instance from the hosting site, anyone observing simply sees you connected to it, so they dont need to break encryption etc, because even if the trarric between you and the hosting server is encrypted,
      continuing on from the VPS and out on the internet the http traffic is going out in the clear haha. So since you are the only IP connected to your VPS, its you!

      So the benefit of shared IP’s on a commercial VPN client is that it is that much more easy to obfuscate your specific traffic from the rest of the clients that are sharing that IP along with you.
      Plus, i suppose while with the VPS you have only 1 server location to tunnel through, with a VPN you have plenty of countries to choose from which to connect.

      1. Hi jonah84,

        > Basically, these days in the era of ubiquitous encryption, traffic analysis is where the genius of the NSA/Intelligence agency is at, because its no longer feasible to simply break the encryption i suppose.

        Indeed, although other options include hacking into VPN servers to access the data before or after it is encrypted, subpoena-ing the VPN provider (or similar – including convincing whatever the local authority is to do this when outside jurisdiction), or even threatening the VPN provider’s staff with violence if they don’t cooperate… If I provider keeps no logs it has nothing to hand over retrospectively in such situations, but realtime logs always exist, and VPN provider can always start to keep these (or can be monitored if the server has been hacked).

        You have hit the nail on the head re. running you own VPN server vs using a commercial VPN service. With your own VPN, internet activity passes through a VPS rented by you and used only by you, so it is very easy to tie that internet activity to you. With a commercial VPN service your internet activity is mixed in with that of possibly hundreds of other users, which make it very hard to pin to any individual user.

  5. proofing:
    “of raw of numbers” extra ‘of’
    “ECDH key length starts at 386-bits” 384?
    good article.
    mention GCM? (vs CBC)

    1. Hi Proof Reader,

      Thanks for the proofing! It should indeed be 384. Now corrected.
      I’m glad you like it! 🙂
      I am open to the idea of discussing GCM vs CBC, but I don’t think I have ever encountered GCM mode “in the wild” (and certainly not within a VPN context). Reasons for this include complexity of implementation and lack of platform support . As GCM is not something that VPN users are ever likely to encounter, my current feelings are that this is a subject best left out of this guide. But as I say, I am open to discussion on the matter.

      1. Hi Jeff,

        I must admit that I tend to concentrate on OpenVPN, as in my view there is little reason to use anything else under most circumstances. Indeed, the detailed breakdown of encryption in this article deals exclusively with OpenVPN. I am aware that AES-GCM is now available for OpenVPN, but as noted in the article, I have yet to come across it. That said, if I do come encounter it, or if enough interest is shown here, I’ll be happy to add a discussion on GCM to this article.

Leave a Reply

Your email address will not be published. Required fields are marked *