Reference Guide

46 Chapter 5: Cryptographic API Changes
RSA BSAFE Crypto-C Micro Edition 3.x to 4.1.4 Migration Guide
Example IV Generation Resource List for Crypto-C ME 4.0 through 4.1.3
R_RES_ITEM list[] =
{
…
R_CR_IV_GEN,
R_CR_DIGEST_SHA256,
…
};
Example IV Generation Resource List for Crypto-C ME 4.1.4 - Normal Use
R_RES_ITEM list[] =
{
…
R_CR_IV_GEN,
R_CR_RANDOM_GENERATOR,
…
};
Example IV Generation Resource List for Crypto-C ME 4.1.4 - AES GCM with
TLS
R_RES_ITEM list[] =
{
…
R_CR_IV_GEN,
R_TIME_RES_MI,
…
};
AES-XTS
AES in XTS mode now enforces a single data unit length for a cryptographic object.
The cryptographic object does not define a default data unit length so the length must
be set by the application using a call to
R_CR_set_info() with the information
identifier,
R_CR_INFO_ID_CIPHER_BLOCK_SIZE.
A call to
R_CR_encrypt() or R_CR_encrypt_update() (or the corresponding
decryption APIs) with a large input buffer, will internally process the data in multiple
segments, each of a single data unit length.
Legacy implementations assumed that the application performed the data
segmentation and passed a buffer of a single data unit in length to each call of the API.
That is, legacy implementations accept the length of the input data as the definition of
the data unit length.
By default AES in XTS mode does not buffer input data that is a fractional number of
data units in length. The application enables buffering explicitly using a call to
R_CR_set_info() with the information identifier,
R_CR_INFO_ID_CIPHER_BUFFERING. When buffering is enabled the
cryptographic object will allocate internal buffers that use multiple data unit lengths of
memory. Note that buffering is not required when the input data has a length of a
whole number of data units to the API.