Encryption and Decryption with Symmetric Keys
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, then, uses a key, secret, or code to transform ciphertext into something readable. Because you can derive the original plaintext data from the ciphertext (provided, of course, that you have the correct key), encryption is a reversible operation. Encryption and decryption are, by far, the most common cryptographic requests made by NAE clients.
The vast majority of encrypt and decrypt operations performed in the Key Manager environment are with symmetric key algorithms. Symmetric key algorithms can be divided into stream ciphers and block ciphers. Stream ciphers process data bit-by-bit, while block ciphers process fixed-size blocks of data. For a variety of reasons, we discourage the use of stream ciphers.
How it Works
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 (let’s call it 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.
For AES, ARIA, and SEED, the block size is sixteen bytes
For 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. 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, ARIA, and SEED algorithms.
Plaintext Size in bytes | Ciphertext Size in bytes |
---|---|
15 | 16 |
16 | 32 |
17 | 32 |
127 | 128 |
128 | 144 |
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.
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, DESede, SEED, ARIA or DES), decide whether you want to use the algorithm in electronic codebook (ECB) mode, cipher-block chaining (CBC) mode, or counter mode (CTR mode only supported in AES algorithm).
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.
In CTR mode, a block cipher is turned into a stream cipher. It generates the next keystream block by encrypting successive values of a counter. CTR mode is well suited to operate on a multi-processor machine where blocks can be encrypted in parallel.
We recommend you to use CBC mode, unless you have a compelling reason to use ECB or CTR mode.
Note
PKCS#11 does not support ECB mode with PKCS5Padding.
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 Key Manager environment, IVs are only used by block ciphers in CBC mode. The size of the IV depends on the algorithm; AES, ARIA and SEED use a sixteen byte IV, while DESede and DES uses an eight byte IV. The Key Manager can generate random IVs for you, 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 your supplied.
Supported algorithms
Supported Algorithms | Supported Algorithms |
---|---|
AES | FPE/AES |
FPE/FF1 | FPE/FF1v2 |
FPE/FF3 | DES (Supported only with KeySecure Classic) |
DESede (triple DES) | SEED |
RC4 (Supported only with KeySecure Classic) | ARIA |
AES/GCM/NoPadding | Date2 |