BIGNUM - The buffer is too small to write to


We are using mbed-tls 2.18.1 on a FreeRTOS-based system. We have an ATECC608A chip which we have used to replace some ECDH functionality in MBED TLS with hardware accelerated counterparts.

While testing our code with our server, we are getting an error during the TLS handshake:

[ 1/11 17:31:58] ssl_cli.c:3396: mbedtls_ecdh_calc_secret() returned -8 (-0x0008)
[ 1/11 16:58:09] ssl_tls.c:9566: <= handshake
[ 1/11 16:58:09] TLS: (handshake) BIGNUM - The buffer is too small to write to
[ 1/11 16:58:09] ssl_tls.c:10197: => write close notify
[ 1/11 16:58:09] ssl_tls.c:10213: <= write close notify

For convenience, here is the function call that is erroring (line 3390 of ssl_cli.c):

    if( ( ret = mbedtls_ecdh_calc_secret( &ssl->handshake->ecdh_ctx,
                               ssl->conf->f_rng, ssl->conf->p_rng ) ) != 0 )

We did some debugging and were able to make the code work by tracking down the code that calculates ssl->handshare->pmslen and just manually increasing it in the mbedtls_ecdh_calc_secret() function on line 639 of crypto/library/ecdh.c:

*olen = ctx->grp.pbits / 8 + ( ( ctx->grp.pbits % 8 ) != 0 );
*olen *= 2;

Of course, that isn’t a real solution.

It seems we have missed something, possibly with our replacement ECDH code, possibly having to do with the premaster secret buffer…

Any insight would be much appreciated!

In case anyone needs any ideas in the future:

I had reimplemented mbedtls_ecdh_compute_shared() to use the hardware chip. I mistakenly stored the result of the computed shared secret in a buffer twice as large as it should have been. Basically, I used the size of a 64 byte key, instead of a 32 byte secret, simply because I confused myself by naming the variable “shared_key” instead of something reasonable, like “shared_secret”

In short: computers will only do what you tell them, even if it is stupid :frowning: