OpenThread + DTLS + nrf_crypto question(s)

[Joel H]

The current problem:

Has anyone else experienced that doing nrf_crypto_init() before a (certificate-based) DTLS handshake messes up something with OpenThead, and prevents the handshake from happening? Any pointers for solutions? For us this is true also if we do nrf_crypto_uninit(), which makes it a hard problem to overcome.

Another crypto question:

Is it correct to assume that using the software-only version of mbedtls, through libmbedcrypto.a, there is no way to generate random numbers? It seems both the CC310 and the nRF HW RNG peripheral collides with the use of libmbedcrypto.a.

Some more background:

We have a project where we are programming a nrf52840 to use OpenThread and nRF SDK for Thread and Zigbee (4.1.0). It connects to and through a OT Border Router running on a raspberry pi, with a zolertia firefly as radio stick. On the border router we run a test server based on the example libcoap server.

We were not able to use the included hardware versions of the , so we were given the helpful suggestion to swap in libmbedcrypto.a instead. This partially solved the handshake issue, but, among other issues, caused a lack of random numbers instead.

[Joel H]

Hi! Thanks for the suggestion, we will try for the "pure" random needs. But I don't see how this would solve the problem that several of the advanced crypto functions in nrf_crypto, such as key generation (nrf_crypto_ecc_key_pair_generate), need the RNG to work. Or do you mean the OpenThread RNG could somehow be given as a reference to nrf_crypto?

I feel I'm missing something fundamental in terms on how OpenThread and nrf_crypto are meant to co-exist, and what code behaviours to expect when using your SDK.