# Supported Key Algorithms

This section describes the key algorithms supported by the CipherTrust Manager. It covers the following information:

## Cryptography Overview

When people think of cryptography, they often think of encrypting and decrypting information, but cryptography goes beyond encryption and decryption. Using the CipherTrust Manager appliance you can encrypt or decrypt data, create a MAC, create a digital signature, and generate random numbers. These topics are described in the following sections:

- Encryption and Decryption with Symmetric Keys
- Encryption and Decryption with Asymmetric Keys
- Message Authentication Codes (MACs)
- Digital Signatures

### Encryption and Decryption with Symmetric Keys

The vast majority of encrypt and decrypt operations performed in the CipherTrust Manager environment are with symmetric key algorithms. In turn, encryption and decryption are, by far, the most common cryptographic requests made by NAE clients. Encryption is the process of obscuring information (plaintext data) to make it unreadable (ciphertext) to anyone who does not possess a key, secret, or code. Decryption, uses a key, secret, or code to transform ciphertext into readable plaintext.

Encryption and decryption with symmetric keys is quite simple. The following example illustrates this exchange:

Bob wants to send a message to Alice, and Bob wants to be sure that no one else can read that message, so Alice and Bob agree on a shared secret key, Key1.

The message Bob wants to send Alice is

`This is a super secret message from Bob.`

Bob encrypts that message using Key1 and sends Alice the ciphertext (`6QNKMgUDJcE....`

).Alice decrypts the ciphertext with Key1 and is now able to read Bob's message.

In this way, Alice and Bob can continue communicating over a network while preventing potential eavesdroppers from understanding their messages. If Alice wants to indicate to Bob that she received his message, she can encrypt her message with Key1 and send Bob the ciphertext, which Bob can then decrypt with Key1.

#### Block Ciphers

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 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. Whichever algorithm is used to encrypt data, the ciphertext is larger than the original plaintext value. The following table illustrates how this is true for the AES and SEED algorithms.

Plaintext Size in Bytes | Ciphertext Size in Bytes |
---|---|

15 | 16 |

16 | 32 |

17 | 32 |

127 | 128 |

128 | 144 |

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

Plaintext Size in Bytes | Ciphertext Size in Bytes |
---|---|

7 | 8 |

8 | 16 |

9 | 16 |

95 | 96 |

96 | 104 |

##### Modes of Operation

If you are using a block cipher (AES and DESede), decide whether you want to use the algorithm in electronic codebook (ECB) mode, or cipher-block chaining (CBC) mode. AES also supports Galois Counter Mode (GCM).

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. We recommend that you avoid using ECB mode unless you have a compelling reason to do so.

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.

Galois Counter Mode (GCM) is available for AES. Refer to the NIST 800-38D publication for full information and recommendations about GCM. GCM provides confidentiality via data encryption, and authenticity by creating an authentication tag for the entire length of the data. The authentication tag created allows message receivers to verify message integrity and authenticity. You can optionally specify additional authenticated data (AAD), sent in the same format as the payload data. AAD is not encrypted, and is associated with the authentication tag. As the AAD is not returned in the CryptoRequest, you must bind the AAD and the encrypted ciphertext on the client side for proper decryption. You can send AAD without any plaintext, in which case AES/GCM performs no encryption, but generates an authentication tag.

##### 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 or GCM, or by FPE when the data segment exceeds the maximum size for one block of data. The size of the IV depends on the algorithm. AES/CBC and SEED use a 16 byte IV. DESede uses an 8 byte IV. AES/GCM uses an IV between 1 and 16 bytes; the preferred value is 12 bytes. You can use the XML protocol's random number generation request (RandGenRequest) to create IVs, or you can supply your own.

When supplying your own IV for data migration, it is important to note that IVs must be specified in hexadecimal (base 16 encoded) characters. As such, an 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 your IV is sufficiently complex, and if you are supplying your own IV for anything other than data migration, it is crucial that you remember the IV you supplied.

Note

To ensure a unique ciphertext during data migration, you would have to apply IVs at the field-level and not the column-level.

##### Block Chaining Mode

FPE operates in a CBC-like mode when encrypting or decrypting a data segment that exceeds the maximum size for a single block of data. For FPE/AES/CARD10, the maximum size for one block of data is 56 bytes.

The first data block is 56 bytes long. The next block is up to 56 bytes long. Unlike a block cipher, FPE does not pad blocks, nor add a trailing block. If a data block is fewer than 56 bytes long, the resulting ciphertext block retains the original length. For example, a 5 byte plaintext block becomes a 5 byte ciphertext block.

##### Initialization Vector

AES/CARD10 uses an 56 byte IV. An IV is required for data segments larger than 56 bytes, the maximum block size. If you use an IV for AES/CARD10, you must supply your own.

#### Supported Algorithms

Of the above symmetric block ciphers, we recommend AES because it performs better and is considered to be more secure than the others.

### Encryption and Decryption with Asymmetric Keys

While symmetric key encryption utilizes a shared secret key, public key cryptography (crypto operations performed with asymmetric keys) typically utilizes a pair of keys: one public, the other private. This allows users to communicate securely without having prior access to a shared secret key. All public keys are published and therefore available to anyone, while all private keys remain with the user. Keys are related mathematically, such that each key allows you to reverse the operations performed with the other key. In other words, you can encrypt with the public key and decrypt with the private key. This method of encryption is extremely slow compared to symmetric ciphers.

The following example illustrates the exchange:

Bob and Alice each generate public/private key pairs and publish their public keys.

Alice looks up Bob's public key, encrypts her message with it, and send Bob her message.

Bob gets Alice's message and decrypts it with his private key.

Bob looks up Alice's public key, encrypts his reply with it, and sends it to Alice.

Alice can then decrypt Bob's message with her private key.

In this way, Alice and Bob can continue communicating over a network while preventing potential eavesdroppers from understanding their messages.

#### Supported Algorithms

Asymmetric algorithms, such as RSA and EC, 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 2048 bits (or 256 bytes). Since RSA encryption supports wide variety of paddings so the maximum data bytes that can be encrypted depends upon the padding being used.

For example, with PKCS#1 padding if you use a 2048-bits (256 bytes) RSA key, the maximum data size that you can encrypt with that key is 245 bytes (key size less eleven).

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.

### Message Authentication Codes (MACs)

A cryptographic hash is a one-way (non-reversible) algorithm that applies a hash function and a secret key to any amount of input and returns a fixed-size output (the MAC). A MAC, short for Message Authentication Code, can be thought of as a keyed hash or checksum. Only if you hold the secret key used to calculate the MAC can you verify the MAC. MACs are used to ensure data integrity and authenticity.

The following example illustrates the exchange:

Bob wants to send a message to Alice, and Bob wants Alice to be able to trust that the message she receives is from Bob and that it has not been modified in any way. So Bob decides to create a MAC of the message that he wants to send Alice. Bob has already given Alice a copy of the HMAC key that Bob uses to compute the MAC.

Bob composes the following plaintext message:

`This is indeed a message from Bob, and it has not been altered.`

Bob uses his HMAC key to compute the MAC of his message text. The MAC value for this particular key and text is:

`k8vifJC1F4sgg6pbeSpp9iMRfQ4r2hMD`

.Bob sends the plaintext message along with the MAC value he computed to Alice.

Once she receives the message, Alice uses the HMAC key Bob gave her to compute the MAC value on the plaintext message Bob sent her.

When the MAC value Alice computes matches the MAC value Bob sent her, she can be confident that the message Bob sent her has not been altered (integrity), and Bob is the sender of the message (authenticity).

#### Supported Algorithms

If you have an interest in storing passwords securely, you might think about creating a MAC at the application level (using one of the Cryptographic Providers) on your passwords and storing the MAC values instead of the plaintext passwords. That way you minimize the amount of time that passwords are in plaintext in your network

MACs can be created through the XML interface and all of the Cryptographic Providers.

The same plaintext value, MACed with the same key, always yields the same output.

By unreversible, it is meant that you cannot apply a reverse function to the MAC value to derive the original plaintext message.

### Digital Signatures

Digital signatures rely on the use of public key cryptography, which generally allows users to communicate securely without having prior access to a shared secret key. Digital signatures can be used to ensure the authenticity of a sender. For example, Bob can encrypt a message with his private key and send it to Alice. If Alice can successfully decrypt it using the corresponding public key, this provides assurance to Alice that Bob (and no one else) sent it.

Digital signatures can be created through all of the Cryptographic Providers except for the .NET Provider. You can also create MACs through the XML interface.

#### Supported Algorithms

### Summary

In summary, you can use the CipherTrust Manager appliance to perform a variety of cryptographic operations. The following table lists the cryptographic algorithms supported by the CipherTrust Manager appliance. Each algorithm is discussed in Supported Algorithms.

Note

Not all algorithms are supported by all client software.

Algorithm | Supported Operations | Description | Function |
---|---|---|---|

AES | • Encrypt • Decrypt | Symmetric key block cipher | Highly secure algorithm; recommended for most environments. |

DESede | • Encrypt • Decrypt | Symmetric key block cipher | Not as secure as AES; can be used in many environments. |

HMAC-SHA1 | • MAC • MAC Verify | Keyed hash function | Used to protect integrity and authenticity. Strength is determined by key size. |

RSA | • Encrypt • Decrypt • Sign • Sign Verify | Public key algorithm | Used to encrypt data and create digital signatures; not the recommended encryption algorithm. |

EC | • Encrypt • Decrypt • Sign • Sign Verify | Public key algorithm | Used to create digital signatures. |

SEED | • Encrypt • Decrypt | Symmetric key block cipher | National standard encryption algorithm in the Republic of Korea. |

ARIA | • Encrypt • Decrypt | Symmetric key block cipher | National standard encryption algorithm in the Republic of Korea. |

## Supported Algorithms

The CipherTrust Manager appliance supports the following public algorithms:

Note

PKCS#11 does not support ECB mode with PKCS5Padding.

### AES

Element | Description |
---|---|

Block Size | 16 bytes |

Supported Modes | ECB (default) CBC GCM |

Padding Schemes | PKCS5Padding NoPadding - When using AES/CBC or AES/ECB in NoPadding mode, you must supply ciphertext in multiples of 16 bytes. GCM does not support padding. |

IV | IV is not allowed in ECB mode. CBC mode requires a 16 byte IV. GCM mode requires an IV between 1 and 16 bytes. An IV of 12 bytes is recommended. Follow the guidelines from NIST's special publication 800-38D. |

Key Size (in bits) | 128 (default) 192 256 NOTE: CTE supports AES-128 and AES-256 keys. |

Identifier Strings | AES/CBC/NoPadding AES/CBC/PKCS5Padding AES/ECB/NoPadding AES/ECB/PKCS5Padding AES/GCM AES - This is equivalent to AES/ECB/PKCS5Padding. |

Additional Notes | When using AES/CBC keys with NoPadding, or AES/ECB, you must supply data (both ciphertext for decryption and plaintext for encryption) in multiples of 16 bytes. |

### DESede

Element | Description |
---|---|

Block Size | 8 bytes |

Supported Modes | ECB (default) CBC |

Padding Schemes | PKCS5Padding (default) NoPadding |

IV | CBC mode requires an 8 byte IV. ECB mode does not allow an IV. |

Key Size | Supported key sizes are 168 (default) and 112 bits. Each key contains an extra 8 bits of parity. Thus, when you create a key of 112 bits, the actual key size is 128 bits; when you crete a key of 168 bits, the actual key size is 192 bits. A key size of 168 bits refers to three-key triple DES. The sequence of operations in three-key triple DES is: Encrypt with Key1 Decrypt with Key2 Encrypt with Key3 |

Identifier Strings | DESede/CBC/NoPadding - Uses outer CBC mode DESede/CBC/PKCS5Padding - Uses outer CBC mode DESede/CBC DESede/ECB/NoPadding DESede/ECB/PKCS5Padding DESede - This is equivalent to DESede/ECB/PKCS5Padding. |

Additional Notes | When using DESede keys with NoPadding, or in ECB mode, you must supply data (both ciphertext for decryption and plaintext for encryption) in multiples of 8 bytes. |

### HMAC-SHA1

Element | Description |
---|---|

Supported Hash Function | SHA-1 |

Padding Schemes | Uses padding from SHA-1 algorithm. No additional padding. |

IV | No IV is required. |

Key Size | Keys can be between 128 and 256 bits. We recommend that the key size be at least 160 bits, and sets the default at 160. The HMAC keys you generate should be a multiple of 8 bytes. On some platforms, HMAC keys that are not a multiple of 8 bytes might yield incorrect results when generating MACs. |

Identifier String | HmacSHA1 |

Additional Notes | HMAC is a stream cipher. HMAC keys are bitstreams of multiples of 8 bits. |

## HMAC-SHA256

Element | Description |
---|---|

Supported Hash Functions | SHA-2 |

Padding Schemes | Uses padding from SHA-2 algorithm. No additional padding. |

IV | No IV is required |

Key Size | Keys can be 128, 192, or 256 bits. The default is 256. The HMAC keys you generate should be a multiple of 8 bytes. On some platforms, HMAC keys that are not a multiple of 8 bytes might yield incorrect results when generating MACs. |

Identifier String | HmacSHA256 |

Additional Notes | HMAC is a stream cipher. HMAC keys are bitstreams of multiples of 8 bits. |

### HMAC-SHA384

Element | Description |
---|---|

Hash Function | SHA-2 |

Padding Schemes | Uses padding from SHA-2 algorithm. No additional padding. |

IV | No IV is required. |

Key Size | Keys can be 192, 288, or 384 bits. The default is 384. The HMAC keys you generate should be a multiple of 8 bytes. On some platforms, HMAC keys that are not a multiple of 8 bytes might yield incorrect results when generating MACs. |

Identifier String | HmacSHA384 |

Additional Notes | HMAC is a stream cipher. HMAC keys are bitstreams of multiples of 8 bits. |

### HMAC-SHA512

Element | Description |
---|---|

Hash Function | SHA-2 |

Padding Schemes | Uses padding from SHA-2 algorithm. No additional padding. |

IV | No IV is required. |

Key Size | Keys can be 256, 384, or 512 bits. The default is 512. The HMAC keys you generate should be a multiple of 8 bytes. On some platforms, HMAC keys that are not a multiple of 8 bytes might yield incorrect results when generating MACs. |

Identifier String | HmacSHA512 |

Additional Notes | HMAC is a stream cipher. HMAC keys are bitstreams of multiples of 8 bits. |

### RSA

Element | Description |
---|---|

IV | No IV is required. |

Key Size | 512 1024 (default) 2048 3072 4096 |

Identifier Strings | For signingSHA1withRSA SHA256withRSA SHA384withRSA SHA512withRSA RSA (Signing data should be pre-calculated hash). SHA1withRSA/PSSPadding SHA256withRSA/PSSPadding SHA384withRSA/PSSPadding SHA512withRSA/PSSPadding NOTE: The SIGN/Verify operation is not supported with SHA384withRSA/PSSPadding and SHA512withRSA/PSSPadding for RSA-512 key size.For encryptionRSA - This is equivalent to RSA/PKCS1Padding. RSA/PKCS1Padding RSA/PKCS1OAEPPadding RSA/PKCS1OAEPPaddingSHA256 RSA/PKCS1OAEPPaddingSHA384 RSA/PKCS1OAEPPaddingSHA512 For Wrap formatPKCS1v2.1/RSAOAEP-SHA1 PKCS1v2.1/RSAOAEP-SHA256 PKCS1v2.1/RSAOAEP-SHA384 PKCS1v2.1/RSAOAEP-SHA512 |

Additional Notes | The ciphertext is always the size of the RSA key. If your RSA key is 2048 bits (256 bytes), then the ciphertext is 2048 bits (256 bytes). Because RSA encryption supports wide variety of paddings so the maximum data size that can be encrypted depends upon the padding scheme being used. For example, with PKCS#1 padding, the maximum data size that you can encrypt is 11 bytes less than the size of the key. Another example, with PKCS#2.1 RSA OAEP Encryption Scheme, the length of data follows the formula: `length of data <= (rsa key size - 2*hashlen -2 )` |

### EC

Element | Description |
---|---|

IV | No IV is required. |

Curve id and Key Size | secp224k1-225 secp224r1- 224 secp256k1-256 secp384r1-384 secp521r1-521 prime256v1-256 brainpoolP224r1-224 brainpoolP224t1-224 brainpoolP256r1-256 brainpoolP256t1-256 brainpoolP384r1-384 brainpoolP384t1-384 brainpoolP512r1-512 brainpoolP512t1-512 |

Identifier Strings | SigningECDSA (Signing data should be pre calculated hash). SHA1withECDSA SHA256withECDSA SHA384withECDSA SHA512withECDSA Encrypt/DecryptECIES, ECIESwith<Hash Algo>/<Symmetric Algo>/<Mode>/<Padding> Symmetric Algo : AES, DESede Mode : CBC Hash Algo : SHA1, SHA224, SHA256, SHA384, SHA512 (for mac, KDF) Padding :PKCS5Padding, NoPadding |

Additional Notes | Prime size may differ from the key size. SEC1 key format is default key format for EC. Although some of the curves have multiple names chosen by different standards organizations, as described in RFC 4492, CipherTrust Manager only supports the Curve IDs listed above. |

### ARIA

Element | Description |
---|---|

Block Size | 16 bytes |

Supported Modes | ECB (default) CBC |

Padding Schemes | PKCS5Padding NoPadding - When using ARIA is NoPadding mode, you must supply ciphertext in multiples of 16 bytes. |

IV | CBC mode requires a 16 byte IV. ECB mode does not allow an IV. |

Key Size (in bits) | 128 (default) 192 256 NOTE: CTE supports AES-128 and AES-256 keys. |

Identifier Strings | ARIA/CBC/NoPadding ARIA/CBC/PKCS5Padding ARIA/ECB/NoPadding ARIA/ECB/PKCS5Padding ARIA - This is equivalent to ARIA/ECB/PKCS5Padding. |

Additional Notes | When using ARIA keys with NoPadding, or in ECB mode, you must supply data (both ciphertext for decryption and plaintext for encryption) in multiples of 16 bytes. |

### SEED

Element | Description |
---|---|

Block Size | 16 bytes |

Supported Modes | ECB CBC |

Padding Schemes | PKCS5Padding NoPadding |

IV | CBC mode requires a 16 byte IV. ECB mode does not allow an IV. |

Key Size | Supported key size is 128 bits. |

Identifier Strings | SEED/ECB/NoPadding SEED/ECB/PKCS5Padding SEED/CBC/NoPadding SEED/CBC/PKCS5Padding SEED – This is equivalent to SEED/ECB/PKCS5Padding. |

Additional Notes | Both server and client must be running version 4.3 or later. |