Supported encryption algorithms for IPsec VPNs
Encryption algorithms scramble data, so that it is not viewable while in transit.
| Method | Description |
|---|---|
| AES-128 |
Advanced Encryption Standard (also referred to as Rijndael) with a 128-bit/192-bit/256- bit encryption key. The AES-128 option uses 128-bit keys by default, but accepts stronger 192-bit or 256-bit keys if requested by the other gateway. Most IPsec-compliant VPN devices support one or both key lengths of these methods, and support is becoming more common. Reference: RFC 4309. |
| AES-256 | |
| AES-GCM-128 |
Advanced Encryption Standard (also referred to as Rijndael) in GCM (galois/counter mode), uses a 16-octet ICV (integrity check value). AES-GCM-128 uses a 128-bit encryption key, and AES-GCM-256 uses a 256-bit encryption key. Provides both authentication and encryption. These methods replace the selected message digest algorithm. In high-performance networks, these encryption methods are recommended. Many IPsec compatible VPN devices do not support one or both key lengths of these methods, but support is becoming more common. Reference: RFC 4106. |
| AES-GCM-256 | |
| DES |
Data Encryption Standard (also referred to as the Data Encryption Algorithm, DEA) uses a 56-bit encryption key. Do not use DES if you can avoid it. DES has been largely abandoned because the short key makes it vulnerable to attacks. If you must use DES, make sure that PFS is enabled and that the encryption keys are frequently renegotiated. Many IPsec-compliant VPN devices still support this method, but support is becoming less common. Reference: RFC 2405. |
| Blowfish |
Uses up to 448-bit keys. Policy-based VPNs use 128-bit keys by default, but accept up to 448-bit keys if requested by the other gateway. Many IPsec-compatible VPN devices do not support this method. Reference: RFC 2451. |
| 3DES |
Triple-DES (also referred to as TDES or TDEA, Triple Data Encryption Algorithm), uses 168-bit encryption achieved with three different 56-bit encryption keys. 3DES is processor-intensive compared to the level of protection it offers and is therefore not the most efficient method. It might not be optimal for VPNs that handle large traffic volumes or systems that otherwise have a high load. Most IPsec-compliant VPN devices support this method. Reference: RFC 2451. |
| Null |
No encryption. Traffic is sent as cleartext just like any non-VPN traffic. Anyone who intercepts the VPN traffic in transit can view the traffic. Null encryption is useful only in special cases. Do not select it for any VPN that requires protected data transfer. Most IPsec-compliant VPN devices support this method. Reference: RFC 2410. |