This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Failed to use curve25519 in M52810

Hi,

I am testing curve25519 in M52810.

The following is snippet.

nrf_crypto_ecc_curve25519_private_key_t       bob_private_key;
nrf_crypto_ecc_curve25519_public_key_t        bob_public_key;

nrf_crypto_ecc_key_pair_generate( NULL,
(nrf_crypto_ecc_curve_info_t*)&g_nrf_crypto_ecc_curve25519_curve_info,
(nrf_crypto_ecc_private_key_t*)&bob_private_key,
(nrf_crypto_ecc_public_key_t*)&bob_public_key );

Build is successful. When run the program, a fatal error occurred when I tried to generate key pair.

How to cope with the issue?

Thanks,

Jianxuan

Parents Reply Children
  • In nRF5_SDK_15.2.0\external\mbedtls\include\mbedtls\bignum.h:

    #define MBEDTLS_MPI_CHK(f) do { if( ( ret = f ) != 0 ) goto cleanup; } while( 0 )

    This macro assign f to ret. In other words, the variable "ret" has been set before it is read.

  • Dear Thorsrud,

    We know that ECDH need a lot of RAM and flash. I am worried that limitation of M52810 resource should cause uncertain problem while ECDH. You know, there is no pca10040e  support in ECDH example.

    Thus, I want to know whether Nordic ran ECDH on M52810? If true, could you share ECDH project for pca10040e?

    Especially, ECDH project with softdevice for pca10040e would be highly appreciated! I could copy your project directly.  That is great!

    Thanks,

    Jianxuan  

  • Hi Jianxuan,

    Ah, I did not spot that. The mbed TLS code is somewhat obfuscated. It seems likely that there is a memory allocation failure. Have you verified it by tracing the error further into mbed TLS?

    We have not tested ECDH properly on the nRF52810 (only the combinations which there are examples for in the SDK are part of the release testing). Fitting this into a nRF52810 with the S112 SoftDevice will be quite tight, though it depend on the amount of RAM needed for S112 (depending on configuration).

    You will probably have better luck by using the Oberon backend instead of mbed TLS as is less far memory hungry. Here (nrf_crypto_ecdh_examples_more_boards.zip) are untested project files of the ECDH example for more boards with and without a SoftDevice configured to use the Oberon backend. This includes a pca10040e project with SoftDevice. Note that the example is not updated to enable and use the SoftDevice, and that the application start address is probably too low for practical BLE applications (except for beacons), but you have some headroom when using the Oberon backend.

  • Dear Thorsrud,

    Thanks for your great support!

    I have not traced the error into mbed TLS.

    I need mbed TLS because of AES CCM. I would encrypt/decrypt data by AES CCM after got secret key by ECDH.

    It seems that 52810 cannot meet my demand. I should try 52832.

    Thank you!

    Jianxuan

Related