The block cipher confidentiality modes in this module comply with Recommendation for Block Cipher Modes of Operation [SP80038A]. To quote from Section 5.3 of that document:
The input to the encryption processes of the CBC, CFB, and OFB modes includes, in addition to the plaintext, a data block called the initialization vector (IV), denoted IV. The IV is used in an initial step in the encryption of a message and in the corresponding decryption of the message.
The IV need not be secret; however, for the CBC and CFB modes, the IV for any particular execution of the encryption process must be unpredictable, and, for the OFB mode, unique IVs must be used for each execution of the encryption process.
In Electronic Codebook (ECB) mode, each block is encrypted independently. In Cipher Block Chaining (CBC) mode, an initialization vector (IV) is added to the first block of plaintext before encryption and the resultant ciphertext is added to the next block of plaintext before encryption, and so on. Decryption is the reverse process. The IV does not need to be kept secret and must be communicated to the receiving party along with the ciphertext.
Block ciphers in ECB or CBC mode require their input to be an exact multiple of the block length. Any odd bytes need to be padded to the next multiple. In general, this is the user's responsibility. However, for encrypting files, CryptoSys API adds a padding string using the convention described in Padding below. For all other encryption functions in this API, it is the user's responsibility to provide and handle appropriate padding where necessary for ECB and CBC modes. See Padding.
Cipher Feedback mode (CFB), Output Feedback mode (OFB) and Counter mode (CTR) do not require padding. We include CFB and OFB modes here for completeness where users may need to communicate with a system that requires it. We recommend using either CBC or CTR modes if you have the choice. CBC mode is supported in most encryption systems.
The CTR mode in this package treats the entire "IV" as a 64- or 128-bit "counter". So if the IV provided
is, say, 0xFFFFFFFFFFFFFFFD for a 64-bit block cipher, then the counter values used will be:
fffffffffffffffd fffffffffffffffe ffffffffffffffff 0000000000000000 0000000000000001 ...
It's up to the programmer to ensure that unique IV or counter values are provided for
each message encrypted with the same key.
Using an IV generated each time with the RNG_NonceData or
RNG_NonceDataHex function should be perfectly adequate
as the odds against producing a duplicate value are billions to one.