1 (edited by jakobsa 2015-10-21 07:16:32)

Topic: [SOLVED] MP_EXPTMOD_E during SSL handshake


we came across the problem that during the SSL Handshake (using ECDHE-RSA-AES128-GCM-SHA256)
WolfSSL is returning with VERIFY_SIGN_ERROR (-330). The Error occurs in one test environment while on
another everything works as expected. In both environments WOLFSSL is used on the client side. While the servers SSL Stack is unknown.

We tracked the error down further and found that a call to mp_exptmod() results in MP_EXPTMOD_E

That happens during processing server key exchange (which is printed out right before)

Digging further down we found the following condition to be the reason for that behavior:

(TAG 3.6.9) tfm.c:1206 if (P->used > (FP_SIZE/2))

We have logged the parameters from both of the machines:

In our test environment (Client compiled for and runs on iOS Simulator 64Bit) no1 the parameters are
P->used:    32
FP_SIZE/2: 36 --> sizeof(fp_digit) == 8 (64Bit mode)

Result: handshake succeeds

In the second test envioronment (Client compiled for and runs on iOS Device 64Bit) the condition matches with the following values:
P->used:    96
FP_SIZE/2: 68 --> sizeof(fp_digit) == 4 (compiled for 32Bit mode, I think ARM64 is not supported)

Result: VERIFY_SIGN_ERROR due tue MP_EXPTMOD_E due to FP_VAL returned by fp_exptmod

We need some suggestion on how to proceed from here. We are unsure if the problem is due to a client or server problem.
We use wolfssl 3.6.9 in an iOS environment and have build with the following settings:

#define HAVE_ECC
#define TFM_ECC256
#define ECC_SHAMIR
#define HAVE_CRL
#define NO_DSA
#define NO_HC128
#define NO_RABBIT
#define NO_MD4

Thank you very much!


2 (edited by jakobsa 2015-10-21 07:15:08)

Re: [SOLVED] MP_EXPTMOD_E during SSL handshake

Is it correct to assume that P->used times the compiled architecture size equals the key length in bit? 

If thats true, I think that in one test environment RSA is done using a 2048 (32 * 64bit) long key while in the other it's a 3072 (96*32bit) long key.

This brought me to the idea to raise FP_MAX_BITS to 8192. I will test this.

"⁠When using RSA keys, always prefer key lengths of at least 3072 bits signed by at least SHA-256, which is sufficiently large for true 128 bits of security." https://access.redhat.com/documentation … ation.html

So I think it might be reasonable to think about raising the FP_MAX_BITS in general.

Update: Successfully tested.
Related: http://www.yassl.com/forums/topic585-so … us-dh.html