Re: [SOLVED] wc_SignatureVerify() : with correct values

2016-11-28T17:28:46Z

Hi Thomas,

Please try using the "WC_SIGNATURE_TYPE_RSA_W_ENC" sig_type. This adds a DER encoded header to the hash prior to the verify. This type typically required when using RSA signatures generated from openssl.

Thanks,
David Garske, wolfSSL

Re: [SOLVED] wc_SignatureVerify() : with correct values

2016-11-17T17:05:04Z

Hi thomas.cornu,

Could you send us a very simple test case to reproduce what you are seeing. A short .c program with just a main function would do nicely.

Also could you send us the configure options used when building wolfSSL so we have the same setup as you used for testing.

If it's not too much trouble could you give us a little background on the project you're working on? Feel free to send project details to support@wolfssl.com if you don't want to publish in the forums.

Thanks and Regards,

Kaleb

[SOLVED] wc_SignatureVerify() : with correct values

2016-11-17T08:07:40Z

Hi
I'm evaluating wolfssl on an embedded target and I have trouble when I test wc_SignatureVerify() function.
Here the input parameter values of the function that I put:
hash_type = WC_HASH_TYPE_SHA256
sig_type = WC_SIGNATURE_TYPE_RSA
data = ref to a data byte array
data_len = size of the data byte array
sig = ref to array that contains the signature (compute with a pc application)
sig_len = signature length (= 256 bytes or 2048 bits in my case)
key = ref the key structure initialized and filled with the public key information (modulus, exponent).
key_len = size of the key structure

I tried many iterations with different data and different private/public key pair but, each time, the function returned SIG_VERIFY_E error.
I step into the function:
- the hash of my data was correctly computed (I cross checked the result with a pc application). The hash_data is 32 bytes length (normal because I use SHA256).
- the wc_RsaSSL_Verify (responsible to decrypt the signature) returned 51 as decrypted message length (store in plain_data array).
So the verification failed and return SIG_VERIFY_E because the decrypted message (plain_data) is different than the expected one (hash_data).
But I look into the plain_data content and, even if it's larger than hash (51 > 32), it contains at the end of the array the hash data value.
Let me show an example:
hash_data[32] = [0x11, 0x22, 0x33, 0x44, ....]
plain_data[256] = [0xFF, 0xFF, ..., 0xXX, 0xXX, 0xXX, ..., 0x11, 0x22, 0x33, 0x44, ....]
plain_data contains 0xFF padding bytes (which is not counted in the final length), then 19 values different than 0xFF (19 = 51 - 32), then hash data values.

How do you explain this strange behavior? Do I made a mistake in the signing computation or is it a issue in the library?

I succeed to bypass the problem by modifying wc_SignatureVerify function. Actually, before strictly compare plain_data content with hash_data, I reduce plain_data size to match hash_data size and provide only the end of the plain_data array to the XMEMCMP call.
It a temporally fix to go further in my testing but I don't know if it's a good solution. I don't want to hide an other problem.

many thanks in advance for your answer and suggestion

Regards,

Thomas

wolfSSL - Embedded SSL Library — [SOLVED] wc_SignatureVerify() : with correct values

Re: [SOLVED] wc_SignatureVerify() : with correct values

Re: [SOLVED] wc_SignatureVerify() : with correct values

[SOLVED] wc_SignatureVerify() : with correct values