### Article Content

Article Number | 000022413 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||

Applies To | RSA Key Manager (RKM) Client 1.5.x RSA Key Manager (RKM) Client 2.1.x | |||||||||||||||||||||||||||||||||||||||||||||||||||||||

Issue | What is the output length of RKM encrypt and HMAC operations? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||

Resolution | The 1.5.x EncryptData operation produces output of length (in bytes): KeyID + null byte + IV + ciphertext KeyID = the length of the Key ID, in bytes. Can be between 1-10 bytes, although most often this is 9 or 10 bytes IV = the Initialization Vector for AES. This is always 16 bytes ciphertext = the AES ciphertext. This is always a multiple of 16 (the block size of AES), and is always the next multiple of 16 after the plaintext length; for example, 15 bytes plaintext produces 16 bytes ciphertext, and 45 bytes plaintext produces 16*3=48 bytes ciphtertext. The 1.5.x HMACData operation produces data of length (in bytes): KeyID + null byte + mac mac = the output produced by the SHA-256 digest, which is always 32 bytes. If you need to store data as printable characters in a database, then you need to Base64 encode the data (which transforms it into printable characters, but increases the size of the data). With the 1.5.x client, if the data is returned in Base64 format (for instance by setting the final parameter of EncryptData to TRUE), then it will be roughly 4/3 the size of what is indicated above. To be exact, Base64 encoding transforms every 6 bits of input data into 8 bits of output, in four byte chunks. So, 3 bytes of input become 4 bytes of output. If an even multiple of 3 bytes of input data is not available, then the result is padded out to the nearest multiple of 4 bytes. The size of the output (4/3 rounded up to a multiple of 4 bytes) is simpler to calculate by rounding the input data up to a multiple of 3 before multiplying by 4/3. For example, when encrypting 20 bytes: Ciphertext = 20 bytes rounded to the next multiple of 16 = 32 KeyID + NULL + IV + Ciphertext = 10 + 1 + 16 + 32 = 59 bytes before Base64 encoding. 59 rounded up to a multiple of 3 is 60. 60 * 4/3 = 80 bytes of output. For the 1.5.x client, this table lists MS Excel formulas that can be used to calculate the length of the output for a given plaintext length:
For The RKM 2.1.x client
The 2.1.x client uses a In the example above, we would have: Encryption Header + ciphertext = 121 + 32 = 153 bytes If this is too large (it is always bigger than 100 bytes), or for compatibility purposes, you may prefer to us the 1.5.x format:
KeyID + null (byte) + IV + ciphertext KeyID = Can be between 1-10 bytes, although most often this is 9 or 10 bytes IV = The Initialization Vector for AES. This is always 16 bytes Ciphertext = The encrypted data. This is always the next multiple of 16 (the AES block size) after the plaintext length; for example, 15 bytes plaintext produces 16 bytes of ciphertext, and 45 bytes plaintext produces 48 bytes of ciphertext.) Plaintext = The data before encryption. For example, when encrypting 20 bytes (with a 10 byte KeyID): Ciphertext = 20 bytes rounded to the next multiple of 16 = 32 KeyID + null + IV + Ciphertext = 10 + 1 + 16 + 32 = 59 bytes You can choose the 1.5.x format with the R_KM_KEY_set_crypto_format command and ID R_KM_DATA_FORMAT_INFO_ID_VER151 or R_KM_DATA_FORMAT_INFO_ID_VER151_BASE64 (for Base64 encoding). In the The RKM 2.1.x client does not currently support a Base64 version of the 2.1.x format. In this case, you would need to perform the Base64 encoding yourself, with another BSAFE cryptography library or other 3rd party library. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||

Notes | The length of the raw cipher text, when using AES (no matter what mode is used) will always be ?the size of the data rounded up to the next 16 bytes boundary. The 1.5 RKM header format will then add 17 bytes to the cipher text. The 2.1 RKM header format will then add 121 bytes to the cipher text when using the 2.1, 2.2 or 2.5 client. The 2.1 RKM header format will then add 170 bytes to the cipher text when using the 2.7 client. The 2.7 RKM header format will then add 202 bytes to the cipher text. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||

Legacy Article ID | a37783 |