Supported Cryptographic Operations for CAPI

CADP for C CAPI allows you to implement data privacy, confidentiality, and integrity in a simple, scalable, and secure manner.

The operations supported are as follows:

For FPE in remote mode, only FPE/AES/CARD10 is supported. However, in local mode all the cardinalities are supported.

To encrypt or decrypt with a block algorithm, it must be possible to divide the plaintext value into full blocks of a specific size. (In the case of AES, the block size is sixteen bytes; in the case of DESede and DES, the block size is eight bytes).

If the plaintext length is not a multiple of the algorithm’s block size, padding is used to fill the remainder of the last block. If the length of the plaintext value is a multiple of the block size, padding is used to fill an additional, trailing block.

This additional block is used to indicate that padding is not present in the preceding blocks. The ciphertext is greater than the original plaintext value, regardless of the algorithm used to encrypt the data.

The following table illustrates how this is true for the AES and SEED algorithms.

As mentioned, DESede and DES use a block size of eight bytes. The following table illustrates how padding affects the length of ciphertexts from DES and DESede algorithms.

Asymmetric algorithms, such as RSA, can be up to an order of magnitude slower than symmetric algorithms.

When using RSA keys to encrypt data, the ciphertext is always the size of the key; if your RSA key is 2048 bits (or 256 bytes), then the ciphertext is also 256 bytes. For example, if you use a 2048-bit RSA key, the maximum data size that you can encrypt with that key is 245 bytes.

MaximumAllowedInputSize for Crypto Operation using different padding

The speed and size issues make public key cryptography impractical for encrypting data. Therefore, we recommend that you use symmetric key algorithms to encrypt your data.

Modes of Operation

If you are using a block cipher (AES, DESede, or DES) decide whether you want to use the algorithm in Electronic Code Book (ECB) mode, or Cipher-Block Chaining (CBC) mode.

• In ECB mode, each block is encrypted separately, through the same procedure. Thus, two identical plaintext blocks encrypt to the same ciphertext and any data patterns in the plaintext can be detected in the encrypted data.

• In CBC mode, the first block is XORed with an initialization vector before being encrypted. All subsequent plaintext blocks are XORed with the previous ciphertext block before being encrypted. This dependency makes it more difficult for an attacker to swap blocks, because blocks must be decrypted in the same order in which they were encrypted to produce the original plaintext.
  When the same key and different IVs are used, identical plaintexts are guaranteed to have different ciphertexts.

It is recommended to use CBC mode, unless you have a compelling reason to use ECB mode.

Initialization Vectors

An initialization vector (IV) is a sequence of random bytes appended to the front of the plaintext before encryption. Use of a unique IV eliminates the possibility that the initial ciphertext block is the same for any two encryption operations of the same plaintext that use the same key. In the CipherTrust Manager environment, IVs are only used by block ciphers in CBC mode. The size of the IV depends on the algorithm; AES and SEED use a sixteen byte IV. DESede and DES uses an eight byte IV. The CipherTrust Manager can generate random IVs, or user can supply own IV.

The eight byte IV requires sixteen characters; likewise, a sixteen byte IV requires thirty-two characters. Sometimes, the examples in this documentation show impractical IVs for the sake of simplicity, for example 112233445566.... Make sure that IV is sufficiently complex, and if supplying own IV for anything other than data migration, it is crucial to remember the IV supplied.

To ensure a unique ciphertext during data migration, it is required to apply IVs at the field–level and not the column–level.

In general, it is recommended to use symmetric (one of the following) block ciphers to encrypt data in the CipherTrust Manager environment: AES, FPE, or DESede. Out of the symmetric block ciphers, it is further recommended to use AES because it performs better and is considered to be more secure than others. To preserve the formatting of data, use FPE algorithm.

It is recommended to not to use TDES/DES algorithm as they are known to be a weak algorithm and are supported only for backward compatibility. The algorithms AES, DES, and DESede supports default IV.

FPE requires an IV depending on the variants of FPE, cardinality, and it’s block size. For example, FPE will have a 56 bytes IV having a cardinality 10 when data size is > 56 bytes, 40 bytes IV having a cardinality 26 when data size is > 40 bytes and 32 bytes IV having a cardinality 62 when data size is > 32 bytes.

Supported Content

There are no restrictions on the type of data and content that a CipherTrust Manager can secure. Whether it is a 10-byte string of data, a 10K image, a 1MB text file, a 10MB PDF file, a financial spreadsheet, or a line of code, a CipherTrust Manager can perform all desired cryptographic operations. In short, a CipherTrust Manager can handle any type of data or content.

Supported Algorithms

The CipherTrust Manager supports the following algorithms:

• AES

• AES/GCM

• DES

• DESede

• HMAC-SHA

  • HMAC-SHA1

  • HMAC-SHA256

  • HMAC-SHA384

  • HMAC-SHA512

• RC4

• RSA

• SEED

• EC

Supported proprietary algorithms:

• FPE/AES

• FPE/FF1

• FPE/FF1v2

• FPE/FF3

A proprietary format that utilizes the DES algorithm is also supported.

AES

AES/GCM

DES

DESede

HMAC-SHA

RC4

RSA

SEED

EC

FPE