000022413 - What is the output length size of RKM encrypt and HMAC operations?

Document created by RSA Customer Support Employee on Jun 14, 2016Last modified by RSA Customer Support Employee on Apr 22, 2017
Version 2Show Document
  • View in full screen mode

Article Content

Article Number000022413
Applies ToRSA Key Manager (RKM) Client 1.5.x
RSA Key Manager (RKM) Client 2.1.x
IssueWhat 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:

 A BCD
 1  Raw BytesBase64 encoded 
 2 Inputs Plaintext Length  [enter length] 
 3  Key ID Length (max: 10) [1-10] 
 4    
 5 Outputs encrypted data =C3+1+C8+C9 =Ceiling(C5*4/3, 4)
 6  HMAC value =C3+1+C10 =Ceiling(C6*4/3, 4)
 7    
 8  IV 16 
 9 Internal values ciphertext (AES) =Ceiling(C2+1, 16) 
 10  HMAC (SHA-256) 32 


For RKM 2.1.x, things are a bit different (although you can still choose the 1.5.x format for compatibility purposes):

The RKM 2.1.x client R_KM_KEY_encrypt operation produces data of length (in bytes):

2.1.x format:

The 2.1.x client uses a 121 byte header that includes a UUID (KeyID), the IV, etc.

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:

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 RKM 2.1.x client, data can be returned in Base64 format  by calling R_KM_KEY_set_crypto_format with R_KM_DATA_FORMAT_INFO_ID_VER151_BASE64.

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.

NotesThe 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 IDa37783

Attachments

    Outcomes