VPN encryption terms explained (AES vs RSA vs SHA etc.)

Encryption is not an easy subject. Really, it isn’t! When it comes to understanding the terminology used to describe how secure a VPN connection is, things can get very confusing very quickly (a situation not helped by the fact that many VPN providers can be slapdash to the point of misleading when describing the encryption they use).

This guide, then is aimed at untangling the various terms used to describe VPN encryption, and serves as a companion piece to our article on PPTP vs L2TP vs OpenVPN vs SSTP vs IKEv2.

VPN protocol

A VPN protocol is the set of instructions (mechanism) used to negotiate a secure encrypted connection between two computers.

We look at the different VPN encryption protocols in our article on PPTP vs L2TP vs OpenVPN vs SSTP vs IKEv2. Note that the VPN protocol is separate from encryption and authentication methods used, which vary depending on the protocol.

PPTP, for example, uses MS-CHAP v2 (which is very insecure), while L2TP almost always uses the IPSec authentication suite, hence you will often see the term L2TP/IPSec. In fact, even if a provider only refers to either LT2P or IPSec (as some do), it almost certainly actually means L2TP/IPSec.

OpenVPN is now the industry standard VPN protocol used by commercial VPN services, and for good reason. It is very secure, and can be used on almost all VPN capable devices (with the notable exception of Blackberry devices).

We therefore recommend using OpenVPN wherever possible, and the rest of this article is primary concerned with OpenVPN*.

* OpenVPN uses the OpenSSL encryption library extensively, as well as the SSLv3/TLS protocol. SSTP provides a mechanism to transport PPP or L2TP traffic through an SSLv3 channel. Thanks to its use of SSL, many of the points made about OpenVPN below also apply to SSTP.

RSA Handshake

(also referred to as key encryption or certificate encryption)

In order to securely negotiate a VPN connection, SSL (and therefore OpenVPN and SSTP) usually uses the RSA asymmetric public-key cryptosystem (asymmetric because a public key is used to encrypt the data, but a different private key is used to decrypt it).

RSA acts as an encryption and digital signature algorithm used to identify TLS/SSL certificates, and has been the basis for security on the internet for the last 20 years or so.

However, it has been demonstrated as of 2010 that 1024-bit RSA (RSA-1024) private key encryption can be cracked (and probably has been by the NSA), leading Google in 2013 to upgrade all of its SSL certificates to the much secure 2048-bit RSA key length, a move copied by most of the security industry.

RSA-2048 key encryption is considered secure, although a case can be made for choosing even stronger 3072-bit or 4096-bit RSA encryption. RSA-2048 is now the minimum standard for commercial VPN providers.

An alternative (rival) handshake that is sometimes used by OpenVPN is the Diffie-Hellman cryptographic key exchange, but this has recently caused huge controversy over its re-use of a limited set of prime numbers, which make it vulnerable to being cracked by a powerful adversary such as the NSA.

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

One advantage that any Diffie-Hellman key exchange has over RSA is that it allows Perfect Forward Secrecy (PFS) to be used. This means that for each new SSL connection made, a new set of keys is generated (and are therefore referred to as ephemeral keys). This makes the job of an adversary much more arduous, as it would have to crack a new key each time a new SSL connection is made.

However, although RSA does not allow for PFS, OpenVPN does (if implemented). This the major reason why OpenVPN is still considered secure against even the NSA.

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

SHA hash authentication

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

A Secure Hash Algorithm (SHA) is a cryptographic hash function used (among other things) to authenticate SSL connections, including OpenVPN connections.

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

This is important in preventing a Man-in-the-middle (MitM) attack, where an adversary may attempt to divert your OpenVPN connection to one of its own servers instead of that of your VPN provider (for example by hacking your router). If an adversary can crack the hash of your provider’s genuine SSL certificate, it can reverse the hash to create a forged certificate, so VPN software would authenticate the connection as genuine.

The most common version of SHA used on the internet is SHA-1 (160-bit), underpinning more than 28 percent of existing digital certificates (including those used by many VPN providers.) Unfortunately, SHA1 is broken.

This has been known for some time, and Microsoft, Google and Mozilla have all announced that their respective browsers will stop accepting SHA-1 SSL certificates by 2017. However, a new research paper suggests that it may be possible to crack SHA-1 before this cut-off date.

In August this year NIST announced that SHA-3 was the new hash standard, after flirting with SHA-2 since 2010. Although no successful attacks against SHA-2 have been recorded, its algorithmic similarity to SHA-1 make SHA-3 the preferred standard.

It is a shame, then, that OpenVPN only supports SHA-1 and SHA-2 (up to SHA-384), not SHA-3. As of the time of writing this article (November 2015), SHA-1 is probably still secure (although who knows what the NSA is capable of). It really is time, however, that VPN providers moved on to SHA-2 (SHA-256 or SHA-384) instead.*

It would also be great if OpenVPN and OpenSSL updated to include SHA-3 (or even Whirlpool and/or Tiger hash authentication,) but we are aware of no current plans to do so.

*After in-depth discussions with AirVPN, I now understand that as long as packet authentication is enabled, use of HMAC SHA1 for OpenVPN authentication is not a weakness, as HMAC SHA1 is much less vulnerable to collision attacks than standard SHA1 hashes (for example, you would need to  break HMAC in order to reach the underlying hash in order to start  collisions attempts on it). Mathematical proof of this is available in this paper.

OpenVPN Ciphers

(also referred to as data encryption)

The VPN protocol, handshake, and data authentication are all designed to ensure that your VPN connection to the VPN server is secure. Your actual data, however, is encrypted using a cipher.

By default, OpenVPN uses the 128-bit Blowfish cipher, which is considered secure for most casual purposes, but it does have known weaknesses, and even its creator was quoted in 2007 as saying ‘at this point, though, I’m amazed it’s still being used. If people ask, I recommend Twofish instead’.

Unfortunately, Twofish is not supported by OpenVPN, so the NIST-approved AES cipher has become the industry-wide “gold standard” for encryption. AES-256 is used by the US government for protecting ‘secure’ data, and is considered very secure. 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 (over 1 GB) files better than Blowfish.

Some VPN providers have flirted with using non-NIST ciphers supported by OpenVPN, such as Camellia, but for whatever reason, little has really come of this. As such, AES remains king when it comes to VPN ciphers (although if OpenVPN ever gets around to supporting Twofish or Threefish, things may be different).

AES is usually available in 128-bit and 256-bit versions (192-bit AES also exists, but we hardly ever see it in the wild!).

AES-128 remains secure as far as anyone is aware, but given what we now know about the extent of the NSA’s assault on encryption standards, most experts agree that AES-256 provides a higher security margin (although there is some debate about this, as AES-128 has a stronger key schedule than AES-256.)

Other considerations / notes


All versions of SHA, RSA, and AES were developed and/or certified by the United States National Institute of Standards and Technology (NIST), 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 built back doors into international encryption standards, there is every reason to question the integrity of NIST algorithms.

Unfortunately, at this point in time, VPN users have little choice but to use NIST approved standards, but it is worth bearing in mind our unease at this situation.  We discuss our beef with NIST in greater detail in our PPTP vs L2TP vs OpenVPN vs SSTP vs IKEv2 article.

Encryption comes at a cost

Encrypting and decrypting data takes processing power, and encryption increases the amount of data transmitted over the internet. This means that the higher the encryption settings used by you or your VPN provider, the slower your internet connection will be.

This will not usually make a bit difference, but sometimes it can. This is particularly the case with smaller providers who servers can struggle to cope with limited bandwidth and large numbers of users, which is certainly not helped by increasing the required computational overhead!

Block Cipher Mode

When reviewing  VPN providers’ descriptions of the encryption they use (or when inspecting an OpenVPN config file) you may come across the term “CBC cipher block mode”, or see “CBC” appended to the cipher entry (e.g. AES-256-CBC).

This refers to the Block cipher mode of operation, which is a very complex and highly technical subject. The good news for this article is that Cipher Block Chaining (CBC) is the only block cipher mode we have seen supported by commercial VPN providers (to see a full list of ciphers supported by OpenVPN, enter “openvpn –show-ciphers” in a Command prompt/Terminal window).

Although CBC may theoretically have some vulnerabilities, the general consensus is that CBC is secure (and is recommended in the OpenVPN manual). Our basic advice, therefore, is that CBC is fine, and given that you are unlikely to encounter any other Block cipher mode, is not worth worrying about anyway.


VPN protocol (PPTP, L2TP/IPSec, OpenVPN, SSTP, IKv2) – the set of instructions used to secure a VPN network

Handshake (RSA-1024, RSA-2048, RSA-3072, RSA-4096, EEC, ECDH) – used to securely negotiate a VPN connection

Hash authentication (SHA-1, SHA256, SHA-3) – creates a unique fingerprint used to authenticate an SSL connection

OpenVPN cipher (Blowfish-126, AES-128, AES-192, AES-256, Camellia128, Camellia-192, Camellia-256) – the encryption algorithm used to protect your actual data.

As a point of reference, the minimum default settings for the OpenVPN protocol are:

Handshake: RSA-2048
Hash authentication:  SHA-1
Cipher: Blowfish-128

So what constitutes “secure” settings for a VPN connection? Well, that is a little like asking “how long is a piece of string,” and depends heavily on your threat model (who you are worried about being secure against). That said, our minimum recommendation for a “secure” VPN connection that should be resistant against any known form of attack for the foreseeable future is:

VPN Protocol: OpenVPN with Perfect Forward Secrecy enabled
Handshake: RSA-2048
Hash authentication: SHA1
Cipher: AES-256

Douglas Crawford I am a freelance writer, technology enthusiast, and lover of life who enjoys spinning words and sharing knowledge for a living. Find me on Google+

Related Coverage

8 responses to “VPN encryption terms explained (AES vs RSA vs SHA etc.)

  1. Hi Douglas,

    This is a great article! Thank you for putting this together. After reading your article a couple of times, two questions arised:

    1) Why should one use an OpenVPN Cipher (e.g. AES-256), if RSA-2048 can be used to encrypt (the actual) data as well? For example, gpg2 allows you to create a public/private key pair, which can be used to encrypt data with the pubic key, and decrypt it with the private key. After I subscribed to my VPN provider, they send me, if I am not mistaken, a certificate, which is a type of public key. So, the data sent over the connection can be encrypted and decrypted with RSA-2048. Why not use this cryptosystem, instead of AES-256? I am afraid the use of cipher and key encryption is not yet clear to me.

    2) For administrative purposes, I use the remote communication protocol SSH to connect to my server. One article mentioned about hardening security to put the following parameter in the config file: “MACs: hmac-ripemd160”. You haven’t mentioned this hash authentication, so I wonder, is this hash authentication better than SHA-1 perhaps?

    Thank you in advance.

    1. Hi Vincent,


      1. – The OpenVPN certificate you were sent is basically an SSL cert – a public key signed by a trusted third party. PGP also uses SSL certs in a similar way.
      – RSA is not used to encrypt data – it is used to encrypt/decrypt that public key and verify the cert (again this applies to both OpenVPN and PGP).
      – PGP encrypts data using PGP (PGP is itself an encryption algorithm). This is why there is no need for PGP to use the AES-256 cipher.

      2. ripemd160 is a cryptographic hash function that, according to Wikipedia, is “similar in performance to the more popular SHA-1”. You likely saw it recommended because SHA-1 is broken as a straight hash function (as you can see in this article, I initially make a similar mistake). As discussed in the article, however, this weakness in SHA-1 is does not really affect HMAC. I therefore cannot see an advantage to using ripemd160 over SHA-1 for HMAC message authentication.

      I hope that all helps! By the way, you may be interested in this fantastic (and detailed) explanation of how PGP works –

  2. Great post, but i have a question:

    This is a configuration for Best Privacy:

    “VPN Protocol: OpenVPN with Perfect Forward Secrecy enabled
    Handshake: RSA-2048
    Hash authentication: SHA256
    Cipher: AES-256”

    What is the best vpn to setup with these settings?

    1. Hi ernuober60,

      Of the top of my head (i.e this is in no way an exhaustive list), AirVPN, BolehVPN, Private Internet Access (using custom settings in its client), ExpressVPN, and Mullvad all meet or exceed these settings

  3. Great website, discovered it 10 months ago and check-it regularly, I have learned heaps, thanks for that.

    I have 2 questions. At what point does my ISP not know where I’m headed to? When I launch my VPN application and click ‘connect’ to.., lets’s say my VPN’s server in Russia. I know the ISP can know that I’m using a VPN, but do they know that I’m connected to a server in ‘Russia’ or that I’m connected to my VPN’s server ‘somewhere in an unknown country’?

    I currently have 3 VPN’s installed on my PC running windows 8.1, PIA(paid sub), Tiger VPN(paid sub, couldn’t resist the $29 LIFETIME MEMBERSHIP!!) and VyperVPN(full feature free membership limited to 500MB/month). My 2nd question is, can I run 2 VPN’s at the same time? All 3 can co-exist at the same time, you need to install VyperVPN 1st, then PIA and finally Tiger with the generic OpenVPN program. I couldn’t run 2 Openvpn based apps at the same time. I then created a L2TP and PPTP but the OpenVpn seems to overpower them and only the OpenVPN connects outside.

    Have anyone tried running 2 VPNs at the same time? What’s the correct order or trick?
    Thanks Douglas

    1. Hi Rick,

      Your ISP will know that you are connected to a server in Russia, but will not be able to “see” your internet traffic because it is encrypted. It will also not be able to see what websites you visit (only that you are connected to a server in Russia.)

      The only way I know of to run two VPNs at the same time is to run a virtual machine (VM), with one VPN running on the VM, which connects to the internet though the host machine’s internet connection (also running a VPN.) This means that the VM VPN will effectively run inside the host machine VPN for twice the protection (but also twice the performance hit.) Edit: A similar effect can be acheived by running one VPN on your router, plus running a software VPN client on your computer.

      1. Hi Douglas.
        About that..
        What you say about NordVPN:
        They say: ”’Double data encryption

        NordVPN’s Double VPN technology encrypts data not once, but twice. It’s the tightest security in the industry, and it’s only available on NordVPN.”

        It is like use two VPNs at the same time too?

        1. Hi Yuri,

          NordVPN’s “Double VPN” system passes data through 2 separate VPN servers, with it being re-encrypted using AES-256 as it leaves each server. This is not the same as running 2 VPNs at the same time. The double-jump would make tracing an internet user more difficult, but as both servers are run by NordVPN (which claims to keep no logs anyway), I am not sure whether any extra security benefits are gained. Similarly, re-encrypting the data twice will indeed make it more secure, but as AES-256 should be secure against even the NSA anyway, I am dubious about the extra benefits this brings. Please note that the quote you have provided was written by another BestVPN staff member (who sometimes edit the summaries on my 5 Best lists). I personally do not consider NordVPN to have “the tightest security in the industry” (although it is pretty good).

Leave a Reply

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