Topic: [SOLVED] wc_SignatureVerify() : with correct values
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 = [0x11, 0x22, 0x33, 0x44, ....]
plain_data = [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