[Front page] [Index]

Cipher Algorithms

The following cipher algorithms are supported:

• 3DES

  The 3DES algorithm is part of the distribution as it is common in the first generations of cryptographic co-processors. It is also still part of the IPsec standards. The weakness of the DES cipher has impliciptly obsoleted also the 3DES algorithm and the use of it is not recommended on software-only systems.

• AES

  The AES (Advanced Encryption Standard, also known as Rijndael) is supported using 128, 192 and 256 bit key sizes.

• AES counter mode

  For details, see the RFC 3686 ("Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)") document available at www.ietf.org.

• AES-GCM

  The AES Galois/Counter Mode algorithm is a combined cipher that can only be used alone, i.e. no integrity algorithm is allowed with AES-GCM.

  AES-GCM is applicable to Encapsulating Security Payload (ESP) - not to Authentication Header (AH). Supported key sizes are 128, 192 and 256 bits.

  AES-GCM is designed for fast hardware implementations. It is somewhat slower than the combination of AES-CBC and SHA-1. On the other hand, AES-CBC requires 128 bits for Initialization Vector (IV) and 96 bits for Integrity Check Value (ICV), therefore requiring a little more overhead in the packet than AES-GCM (64 bits + 128 bits).

  AES-GCM cannot be used for IKE. It is recommended to use AES-CBC with the same key length than the desired AES-GCM key length in the IKE negotiation. Depending on the level of integrity protection required and the efficiency desired for pseudo-random function, SHA-1 or SHA-2 are recommended choices for the companion integrity algorithm.

  The AES-GCM algorithm requires a 32-bit random nonce. To ensure the nonce is random and correctly negotiated between the tunnel endpoints, statically keyed AES-GCM tunnels are not supported.

  Currently the IKE initiator cannot simultaneously propose AES-GCM and a combination of cipher and integrity algorithms. Therefore, for most practical purposes, AES-GCM must be used alone in the transform. (This restriction does not apply to IKE responders. For responders, the default behavior is to allow incoming AES-GCM.)

  For details on the AES-GCM algorithm, refer to the RFC 4106 document ("The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)") available at www.ietf.org.

• GMAC-AES

  The GMAC-AES algorithm is a variant of AES-GCM, but does no encryption at all, only integrity verification. GMAC-AES has mostly the same restrictions as AES-GCM, with one significant additional restriction: GMAC-AES can only be negotiated with IKEv2.

  Unlike AES-GCM, GMAC-AES can be used for Authentication Header (AH) as well as Encapsulating Security Payload (ESP). In AH, GMAC-AES is an integrity algorithm, but when used with ESP, GMAC-AES is a combined cipher, and therefore cannot be used with any other cipher or integrity algorithm. Supported GMAC-AES key sizes are 128, 192 and 256 bits.

  For details of the GMAC-AES algorithm, refer to the RFC #4543 document ("The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH") available at www.ietf.org.