topic sgx_aes_ctr_encrypt counter size in Intel® Software Guard Extensions (Intel® SGX)

sgx_aes_ctr_encrypt counter size

Fredrik_T_ — Mon, 23 May 2016 08:51:12 GMT

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

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

Regarding the counter size, two possibilities seem likely:

The counter size is fixed. The documentation does not mention this.
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:

The encrypt and decrypt functions should have an additional parameter ctr_size
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.

The sgx function, sgx_aes_ctr

Derek_B_Intel — Mon, 23 May 2016 12:59:47 GMT

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

AES in CTR mode does not have

JohnMechalas — Tue, 24 May 2016 20:15:00 GMT

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.

Thank you John for the

Fredrik_T_ — Wed, 25 May 2016 06:51:36 GMT

Thank you John for the detailed explanation!