- 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