• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 2 answers
  • Subscribers 52 subscribers
  • Views 569 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2652R: Initialization vector in cryptography AESCCM

Marco Quintero
Prodigy 140 points
Part Number: CC2652R

Hi, support,

Im receiving by BLE an encrypted data using the algorithm AES CBC.
For that reason, I have to decrypt using your driver AESCCM.
But your AESCCM only use initialization vector with a max length of 13 bytes ("Length of nonce in bytes. Valid nonce lengths are [7, 8, ... 13]")

The libraries in android and IOS that allow working with this algorithm only work with 16 bytes, you can write 13 bytes but they filled with 0x00 hex the rest 3 bytes. Also, the tools online work in the same way.

So my question Is there a workaround to deal with this situation where I can decrypt the algorithm AES CBC with IV = 16 bytes?

Am I missing something here?

Best Regards and thanks for your time

  • 0
    TI__Guru 56590 points

    Hello Marco,

    I might lack understanding in the subject matter, but why can you not use AESCBC?

    http://dev.ti.com/tirex/explore/node?node=AP24VgJ7gbuZWQrdF16tIg__pTTHBmu__LATEST 

  • 0
    TI__Guru 58425 points

    Hi Marco,

    It seems their implementations sends the full IV. This means it will only work together with our driver if the block counter on the Android/IOS side is initially 0. In that case you could just extract the nonce part of the IV (which consist of CCM flags, nonce, counter) and feed it into the driver and it will internally generate the rest of the IV. 

  • 0 in reply to IUsedToBeARealPerson (M-W)
    Prodigy 140 points

    Hi, M-W

    Thanks for your fast reply, I will check the libraries.

    Best Regards

  • 0 in reply to Eirik V
    Prodigy 140 points

    Hi Eirik ,

    Thanks for your fast reply, I appreciated!

    I could use it, but do you have an idea how I could avoid someone take the encrypted package and send it again over BLE to repeat the command?

    I have an idea using time and inserting in the package

    but I will appreciate your opinion on this.

    Best Regards

  • 0 in reply to Marco Quintero
    TI__Guru 58425 points

    Hi Marco,

    The full IV would contain a "block counter" part, which means it updates each encryption. For example, performing multiple CCM encryption on your phone should all yield different IVs as the top part (if i remember correctly) should be the internal counter. Same goes on the device side (as it does not accept you to  specify the block counter as an input) where it will expect the counter part of the IV to match the internal counter.

    If you try to resend the same message again (with the same IV), it should fail as the counter has ticked. 

    This is where the length of nonce part comes into play. The longer nonce the smaller counter. This means that you trade the maximum number of packets you can send with one nonce before needing to change it for being able to send longer messages.

    If you have a smaller nonce, you can fit more counter into the IV and you can send a greater number of messages before it wraps, but you are limited in maximum length of each packet.