Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Fredrik_T_
Beginner
476 Views

sgx_aes_ctr_encrypt counter size

Jump to solution

The aes_ctr encrypt and decrypt functions expect the following counter parameters:

  1. uint8_t *p_ctr: Pointer to the counter block
  2. const uint32_t ctr_inc_bits: Number of bits in counter to be incremented

Regarding the counter size, two possibilities seem likely:

  1. The counter size is fixed. The documentation does not mention this.
  2. ctr_inc_bits is used both for the number of bits to increment, and as the ctr_len (i.e. all bits are incremented)

Regarding possibility 2, NIST SP 800-38A mentions methods of constructing counter blocks in which ctr_inc_bits
is not equal to ctr_len. For example in scenario 2, counter blocks with ctr_size=b are generated by using a random
nonce as the b/2 most significant bits, and incrementing only the b/2 least significant bits (ctr_inc_bits=b/2).

I think the following is necessary:

  1. The encrypt and decrypt functions should have an additional parameter ctr_size
  2. The documentation has to mention which ctr_inc_bits bits of the counter are incremented (most or least significant)

Sidenote: sgx_rijndael128GCM_encrypt also recieves an iv_len in addition to p_iv.

0 Kudos

Accepted Solutions
John_M_Intel
Employee
476 Views

AES in CTR mode does not have a variable length nonce. It must equal the block size, which in this case is 128 bits. The nonce and the counter are combined in this block. Since the block size is fixed at 128 bits, specifying the size of the counter is sufficient.

The counter bits incremented by sgx_aes_ctr_encrypt() are the least significant bits, so if you pass the following vector as the nonce/counter block:

f0f1f2f3f4f5f6f7f8f9fafbfcfdfeff

what you receive back (assuming you set ctr_inc_bits large enough, in this case, at least 16) will be:

f0f1f2f3f4f5f6f7f8f9fafbfcfdff00

If you were to set ctr_inc_bits to 8, you'd get this, instead:

f0f1f2f3f4f5f6f7f8f9fafbfcfdfe00

The reason sgx_rijndael128GCM_encrypt() has an IV_len parameter is because the nonce/IV length for GCM encryption truly is variable. The IV can literally be any size. A 96-bit (12-byte) IV is most common, however, because other sizes require additional calculations. But since the IV length is truly variable and up to the developer/user, the function needs to know how long of an IV you are sending it.

 

View solution in original post

3 Replies
Derek_B_Intel
Employee
476 Views

The sgx function, sgx_aes_ctr_encrypt, is a wrapper for the Intel IPP Cryptography library ippsAESEncrypt functions.  Please refer to IPP documentation for additional details and questions on AES Ctr Mode Encryption. 
    https://software.intel.com/en-us/node/502801

 

 

John_M_Intel
Employee
477 Views

AES in CTR mode does not have a variable length nonce. It must equal the block size, which in this case is 128 bits. The nonce and the counter are combined in this block. Since the block size is fixed at 128 bits, specifying the size of the counter is sufficient.

The counter bits incremented by sgx_aes_ctr_encrypt() are the least significant bits, so if you pass the following vector as the nonce/counter block:

f0f1f2f3f4f5f6f7f8f9fafbfcfdfeff

what you receive back (assuming you set ctr_inc_bits large enough, in this case, at least 16) will be:

f0f1f2f3f4f5f6f7f8f9fafbfcfdff00

If you were to set ctr_inc_bits to 8, you'd get this, instead:

f0f1f2f3f4f5f6f7f8f9fafbfcfdfe00

The reason sgx_rijndael128GCM_encrypt() has an IV_len parameter is because the nonce/IV length for GCM encryption truly is variable. The IV can literally be any size. A 96-bit (12-byte) IV is most common, however, because other sizes require additional calculations. But since the IV length is truly variable and up to the developer/user, the function needs to know how long of an IV you are sending it.

 

View solution in original post

Fredrik_T_
Beginner
476 Views

Thank you John for the detailed explanation!