Cipher algorithms

The PingDirectory server supports encryption cipher suites that are compliant with the Java Virtual Machine (JVM) on which the server is running. When configuring encryption, you must specify the cipher using a key length in bits and either a cipher algorithm name, such as AES, or a full cipher transformation that explicitly specifies the mode and padding to use for the encryption, such as AES/CBC/ PKCS5Padding. If only a cipher algorithm is given, then the default mode and padding for that algorithm are automatically selected.

The following cipher algorithms and key lengths have been tested using the Oracle JVM.

Cipher algorithms and key length
Cipher Algorithm Key Length (bits)

AES

128

Blowfish

128

DES

64

DESede

192

RC4

128
Tip:

Although the server supports all of the cipher algorithms listed in the table, using any algorithm other than AES is discouraged. The DES and RC4 algorithms have known vulnerabilities, and there are no meaningful advantages in using Blowfish or DESede instead of AES.

By default, some JVM implementations come with limited encryption strength, which might restrict the usable key lengths. For example, the Oracle JVM does not allow AES with 192-bit or 256-bit keys unless you download and install the unlimited encryption strength policy files.

Cipher modes indicate how the cipher algorithm should be recurrently applied to portions of the data to produce the final result. Supported cipher transformation modes include:

CBC
The Cipher Block Chaining mode uses an initialization vector to introduce randomness into the encryption process. This ensures that encrypted outputs are always unique even when the input data is identical.
GCM
The Galois/Counter mode provides better data integrity protection to ensure that ciphertexts are not altered. Like the CBC mode, GCM uses an initialization vector to introduce randomness into the output.
ECB
The Electronic Codebook mode encrypts each block of data separately without using any randomness. Because of the lack of randomness, this mode is susceptible to plain-text attacks.

Padding is important when using a block cipher because these ciphers can only encrypt a fixed amount of data at a given time. If the amount of data to be encrypted is not a multiple of the block size, then extra bytes must be added to the plain text before encrypting it. It must also be possible to remove these extra bytes when decrypting. Supported padding algorithms in a cipher transformation include:

PKCS5Padding
This is a standard padding algorithm described in the PKCS #7 specification in RFC 5652. You should use this padding algorithm when using a block cipher like AES with the CBC or ECB modes. Optionally, you can also use this algorithm when using the AES block cipher with the GCM mode.
NoPadding
This algorithm indicates that no padding is needed and should be used with stream ciphers rather than block ciphers.
Note:

AES can act as a stream cipher when using the GCM mode.

For specific reference information about the algorithms and transformations available in all compliant JVM implementations, see the Java Cryptography Architecture Reference Guide and Java Cryptography Architecture Standard Algorithm Name Documentation documentation.

Cipher stream providers

By default, setup generates a strong, random passphrase and writes it to a file. The server then uses a file-based cipher stream provider to read the passphrase and generate a key for encrypting the contents of the encryption settings database. However, the server supports additional cipher stream providers that use alternative means for unlocking the encryption settings database. Options include:

  • Require a passphrase to be interactively provided when the server is started or any time an external process needs access to the encryption settings database.
  • Use a key stored in the Amazon Key Management Service (KMS).
  • Use a key stored in a HashiCorp Vault instance.
  • Use a key generated from a passphrase stored in the Amazon Secrets Manager service.
  • Use a key generated from a passphrase stored in the Azure Key Vault service.
  • Use a key generated from a passphrase stored in a CyberArk Conjur instance.
  • Use a key generated from a certificate stored in a PKCS #11 token.

For more information, see Configuring cipher stream providers.