1. Messages
  2. bluetooth mesh on nrf51822-16kb tinycrypt-ecc

Re: bluetooth mesh on nrf51822-16kb tinycrypt-ecc

laczenJMS
 

Hi Johan,

Thanks for the reply. It is clearly not possible to reduce the stack
usage of tinycrypt.

Regarding the coexisting of network state and provisioning state,
would it be possible to use the concept of memory slabs/memory pools
to allocate and free the respective states ? This might be easier then
to overlay.

Kind regards,

Jehudi

2017-10-20 16:51 GMT+02:00 Johan Hedberg <johan.hedberg@intel.com>:

Hi Jehudi,

On Fri, Oct 20, 2017, Laczen JMS wrote:
On a zephyr device with bluetooth mesh tinycrypt-ecc is used to
generate the ecdh key. Tinycrypt uses a stack of 1kb which is quite
large on small ram (16kb) devices. Is it possible to precalculate the
keys and to include them instead of generating on the device ?
The large stack footprint of TinyCrypt is one of my pet peeves with it
as well. You could pre-generate the public-private keypair, but then
you're still left with calculating the DHKey when you receive the remote
public key. That's not something that you can do in advance and it also
consumes roughly the same amount of stack with TinyCrypt.

There could however be other places where there's potential to slim
things down a bit further. One such place is the provisioning state in
prov.c. A node is either provisioned or unprovisioned, so the network
state and the provisioning state never need to coexist in memory. This
means we could save some memory if we find a way to overlay them (using
a union or some linker magic). This task is actually listed in the
subsys/bluetooth/host/mesh/TODO file.

Johan
Join devel@lists.zephyrproject.org to automatically receive all group messages.