Supported Key Algorithms

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

• Cryptography Overview

• Supported Algorithms

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.

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

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

• AES

• DESede (triple DES)

• ARIA

• SEED

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

• RSA

• EC

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

• HMAC-SHA1

• HMAC-SHA256

• HMAC-SHA384

• HMAC-SHA512

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

• RSA

• EC

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.

Supported Algorithms

The CipherTrust Manager appliance supports the following public algorithms:

• AES

• DESede

• HMAC-SHA1

• HMAC-SHA256

• HMAC-SHA384

• HMAC-SHA512

• RSA

• EC

• ARIA

• SEED

Note

PKCS#11 does not support ECB mode with PKCS5Padding.

AES

DESede

HMAC-SHA1

HMAC-SHA256

HMAC-SHA384

HMAC-SHA512

RSA

EC

ARIA

SEED