Supported Services & Operations
Services
The CADP for .NET Core provider offers the following services:
KeyGenerators
AES | HMAC (SHA1, SHA256, SHA384, and SHA512) |
DESede | ECDSA |
KeyPairGenerator
RSA | EC |
Ciphers
AES/CBC/None | AES/CBC/PKCS7Padding |
ES/ECB/None | AES/ECB/PKCS7Padding |
AES/GCM | RSA |
DESede/CBC/None | DESede/CBC/PKCS7Padding |
FPE/AES/CARD10 | FPE/AES/CARD26 |
FPE/AES/CARD62 | FPE/AES/UNICODE |
FPE/FF1v2/CARD10 | FPE/FF1v2/CARD26 |
FPE/FF1v2/CARD62 | FPE/FF1v2/UNICODE |
FPE/FF3/CARD10 | FPE/FF3/CARD26 |
FPE/FF3/CARD62 | FPE/FF3/UNICODE |
FPE/FF3-1/CARD10 | FPE/FF3-1/CARD26 |
FPE/FF3-1/CARD62 | FPE/FF3-1/UNICODE |
MAC
SHA1 | SHA256 |
SHA384 | SHA512 |
Operations
CADP for .NET Core allows you to implement data privacy, confidentiality and integrity in a simple, scalable and secure manner.
The operations supported are as follows:
Security Provided | Algorithm | Functions Supported |
---|---|---|
Data Privacy and Confidentiality (Symmetric) | — AES — AES/GCM — DESede — FPE/AES/CARD10 — FPE/AES/CARD26 — FPE/AES/CARD62 — FPE/AES/UNICODE — FPE/FF1v2/CARD10 — FPE/FF1v2/CARD26 — FPE/FF1v2/CARD62 — FPE/FF1v2/UNICODE — FPE/FF3/CARD10 — FPE/FF3/CARD26 — FPE/FF3/CARD62 — FPE/FF3/UNICODE — FPE/FF3-1/CARD10 — FPE/FF3-1/CARD26 — FPE/FF3-1/CARD62 — FPE/FF3-1/UNICODE | Encrypt/Decrypt |
Data Privacy and Confidentiality (Asymmetric) | RSA | Encrypt/Decrypt |
Data Integrity | — HmacSHA1 — HmacSHA256 — HmacSHA384 — HmacSHA512 | MAC/MAC Verify |
Data Signatures | — SHA1withRSA — SHA256withRSA — SHA384withRSA — SHA512withRSA — SHA1withRSA/PSSPadding — SHA256withRSA/PSSPadding — SHA384withRSA/PSSPadding — SHA512withRSA/PSSPadding — SHA1withECDSA — SHA256withECDSA — SHA384withECDSA — SHA512withECDSA | Sign/Sign Verify |
Note
SHA-1 must not be used to hash a message for signature purpose.
To encrypt or decrypt with a block algorithm, divide the plaintext value into full blocks of a specific size. (For AES, the block size is sixteen (16) bytes; for DESede, the block size is eight (8) 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 algorithm.
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 algorithm.
Plaintext Size (in bytes) | Ciphertext Size (in bytes) |
---|---|
7 | 8 |
8 | 16 |
9 | 19 |
95 | 96 |
96 | 104 |
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.
The speed and size issues make public key cryptography impractical for encrypting data. Therefore, it is recommended that you use symmetric key algorithms to encrypt your data.
Modes of Operation
If you are using a block cipher (AES or DESede), decide whether you want to use the algorithm in electronic codebook (ECB) mode, or cipher-block chaining (CBC) mode.
In general, it is recommended to use symmetric (AES, FPE, or DESede) block ciphers to encrypt data in the CipherTrust Manager environment. 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.
Following are the modes supported by CADP for
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.
Tip
It is recommended that you 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 uses a sixteen byte IV. FPE uses an IV depending on 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. DESede uses an eight byte IV. The CipherTrust Manager can generate random IVs, or user can supply own IV.
Important Notes
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.
When the same key and different IVs are used, identical plaintexts are guaranteed to have different ciphertexts.
Note
The algorithms AES and DESede support default IV.
IV must not be re-used.
It is recommended not to use TDES algorithm as they are known to be weak algorithms and are supported only for backward compatibility.