Advertisement and encryption performance

RE: Advertisement and encryption performance

Ole Bauck — Mon, 03 Oct 2016 10:33:15 GMT

Recommend to take a look at this blogpost: devzone.nordicsemi.com/.../

Amit Chahar — Sat, 01 Oct 2016 13:06:30 GMT

sd_ecb_block_encrypt() uses aes-ecb but I want aes-ccm. Using aes-ccm hardware will be more efficient instead of implementing it in software.

RK — Sat, 01 Oct 2016 12:53:03 GMT

Does sd_ecb_block_encrypt() not do what you want?

Amit Chahar — Sat, 01 Oct 2016 12:49:02 GMT

Regarding 4th point. But How can I use aes-ccm peripheral without using timeslot api, since aes-ccm peripheral is restricted by softdevice ?

RK — Sat, 01 Oct 2016 11:24:15 GMT

if you get an error - set it to 1, you don't really care anyway, it's just a little bit of RAM (I would expect zero to work however)
using the softdevice is going to be much much much much easier, so unless you are totally resource constrained for some reason, use the softdevice.
It's possible to encrypt the payload data, obviously the actual packet itself is unencrypted, that's the BTLE standard.
You don't need to encrypt with the timeslot API, you can just encrypt and then set the advertising data into the packet. So I would start with softdevice and just encrypting the payload before setting it. If that doesn't perform well enough then start optimising then.