1 Topic by cxdinter (edited by cxdinter 2017-08-03 03:09:42)

  • Registered: 2016-08-14
  • Posts: 47

Topic: [SOLVED] one problem from wc_CmacFinal() function

Hi,
   In this function, there is one judgment which list below:
   

if (outSz != NULL && *outSz < AES_BLOCK_SIZE)
        return BUFFER_E;

   Why here muse adjust *outSz  should great than AES_BLOCK_SIZE??
   Normally, if define one variable for store output CMAC size, and initialzie it as 0. then call this function, it will return FAIL ! (BUFFER_E)

  actually, at the end of this function, function will put real CMAC output szie to *outSz, so I can't understand why we need to adjust *outSz must great than AES_BLOCK_SIZE???
  maybe, the author want caller to assign a actual output CMAC size, but I don't think it is necessary. Because AES key size will decide the output CMAC size (like 128 or 256).

  what's your opion??

Share

  • From: Bozeman
  • Registered: 2014-05-09
  • Posts: 777

Re: [SOLVED] one problem from wc_CmacFinal() function

Hi cxdinter,

It has been awhile since we heard from you! December of 2016 I believe, how are things?

Anyway, I can see where the confusion might come in given the lack of "commentary" in that function. Since the output buffer being passed in is a pass by reference (pointer) we also need a way of controlling memory access beyond the call to this function. We accomplish that by setting outSz to the result length of the CMAC operation.

Typically we would expect a user to call

wc_AesCmacGenerate(out, outSz, in, inSz, key, keySz);

Now imagine the user did the following:

byte buf[4096] = {... some data ...};
int bufSz = sizeof(buf);
byte out[4096] = {0};
int outSz = sizeof(out);
byte key[KEY_LEN] = { .... some key ... };
int keySz = sizeof(key);
int ret;

ret = wc_AesCmacGenerate(out, outSz, in, inSz, key, keySz);
if (ret == 0)
    do something interesting with "out" based on outSz **ALERT**

If we did not adjust outSz to the fixed length of the resulting CmacFinal operation then the user would be accessing bad data, sure they would get their CMAC tag at the beginning of the buffer but they would be accessing 4096 - AES_BLOCK_SIZE data that they didn't need here. That is why we set it explicitly on exiting the function successfully.

    if (outSz != NULL)                                                           
         *outSz = AES_BLOCK_SIZE;

Also this sanity check protects against the case where the buffer being used is too small to store the result of the operation:

if (outSz != NULL && *outSz < AES_BLOCK_SIZE)
    return BUFFER_E;

Does that make sense? Let me know if you have any other questions on this.


Warm Regards,

Kaleb

Kaleb J. Himes's Website

Share

  • Registered: 2016-08-14
  • Posts: 47

Re: [SOLVED] one problem from wc_CmacFinal() function

Kaleb J. Himes wrote:

Hi cxdinter,

It has been awhile since we heard from you! December of 2016 I believe, how are things?

Anyway, I can see where the confusion might come in given the lack of "commentary" in that function. Since the output buffer being passed in is a pass by reference (pointer) we also need a way of controlling memory access beyond the call to this function. We accomplish that by setting outSz to the result length of the CMAC operation.

Typically we would expect a user to call

wc_AesCmacGenerate(out, outSz, in, inSz, key, keySz);

Now imagine the user did the following:

byte buf[4096] = {... some data ...};
int bufSz = sizeof(buf);
byte out[4096] = {0};
int outSz = sizeof(out);
byte key[KEY_LEN] = { .... some key ... };
int keySz = sizeof(key);
int ret;

ret = wc_AesCmacGenerate(out, outSz, in, inSz, key, keySz);
if (ret == 0)
    do something interesting with "out" based on outSz **ALERT**

If we did not adjust outSz to the fixed length of the resulting CmacFinal operation then the user would be accessing bad data, sure they would get their CMAC tag at the beginning of the buffer but they would be accessing 4096 - AES_BLOCK_SIZE data that they didn't need here. That is why we set it explicitly on exiting the function successfully.

    if (outSz != NULL)                                                           
         *outSz = AES_BLOCK_SIZE;

Also this sanity check protects against the case where the buffer being used is too small to store the result of the operation:

if (outSz != NULL && *outSz < AES_BLOCK_SIZE)
    return BUFFER_E;

Does that make sense? Let me know if you have any other questions on this.


Warm Regards,

Kaleb

Hi Kaleb,
    Nice meet you again:)

    Actually, I haven't left wolfSSL forum. Somtetimes, I will log in and learn from some topics.
    Now, our project are running with wolfSSL commercial version which ported by your collegue Garske, and your collegue Rich also visted our commpany in April. Now, we are partners.

   OK. back to this topic. I understood your scruple. But actually, If some user use so big buffer to store CMAC tag, that means he doesn't know what CMAC is, and he also doesn't know the relationship between AES algorithm and CMAC rule. If any project manager use these guys to develop security features, it is a tragedy.
   Anyway, stand on crypto library developer side, it's correct. We need to avoid any unexpect risk.

    Thank you. Please close this topic.

Share