- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

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*.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

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.

Link Copied

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

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

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

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.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

Thank you John for the detailed explanation!

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page