<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title><![CDATA[wolfSSL - Embedded SSL Library — [SOLVED] wc_SignatureVerify() : with correct values]]></title>
		<link>https://www.wolfssl.com/forums/topic891-solved-wcsignatureverify-with-correct-values.html</link>
		<atom:link href="https://www.wolfssl.com/forums/feed-rss-topic891.xml" rel="self" type="application/rss+xml" />
		<description><![CDATA[The most recent posts in [SOLVED] wc_SignatureVerify() : with correct values.]]></description>
		<lastBuildDate>Mon, 28 Nov 2016 17:28:46 +0000</lastBuildDate>
		<generator>PunBB</generator>
		<item>
			<title><![CDATA[Re: [SOLVED] wc_SignatureVerify() : with correct values]]></title>
			<link>https://www.wolfssl.com/forums/post2898.html#p2898</link>
			<description><![CDATA[<p>Hi Thomas,</p><p>Please try using the &quot;WC_SIGNATURE_TYPE_RSA_W_ENC&quot; 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.</p><p>Thanks,<br />David Garske, wolfSSL</p>]]></description>
			<author><![CDATA[null@example.com (dgarske)]]></author>
			<pubDate>Mon, 28 Nov 2016 17:28:46 +0000</pubDate>
			<guid>https://www.wolfssl.com/forums/post2898.html#p2898</guid>
		</item>
		<item>
			<title><![CDATA[Re: [SOLVED] wc_SignatureVerify() : with correct values]]></title>
			<link>https://www.wolfssl.com/forums/post2871.html#p2871</link>
			<description><![CDATA[<p>Hi thomas.cornu,</p><p>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.</p><p>Also could you send us the configure options used when building wolfSSL so we have the same setup as you used for testing.</p><p>If it&#039;s not too much trouble could you give us a little background on the project you&#039;re working on? Feel free to send project details to support@wolfssl.com if you don&#039;t want to publish in the forums.</p><br /><p>Thanks and Regards,</p><p>Kaleb</p>]]></description>
			<author><![CDATA[null@example.com (Kaleb J. Himes)]]></author>
			<pubDate>Thu, 17 Nov 2016 17:05:04 +0000</pubDate>
			<guid>https://www.wolfssl.com/forums/post2871.html#p2871</guid>
		</item>
		<item>
			<title><![CDATA[[SOLVED] wc_SignatureVerify() : with correct values]]></title>
			<link>https://www.wolfssl.com/forums/post2868.html#p2868</link>
			<description><![CDATA[<p>Hi<br />I&#039;m evaluating wolfssl on an embedded target and I have trouble when I test wc_SignatureVerify() function.<br />Here the input parameter values of the function that I put:<br />hash_type = WC_HASH_TYPE_SHA256<br />sig_type = WC_SIGNATURE_TYPE_RSA<br />data = ref to a data byte array<br />data_len = size of the data byte array<br />sig = ref to array that contains the signature (compute with a pc application)<br />sig_len = signature length (= 256 bytes or 2048 bits in my case)<br />key = ref the key structure initialized and filled with the public key information (modulus, exponent).<br />key_len = size of the key structure</p><p>I tried many iterations with different data and different private/public key pair but, each time, the function returned SIG_VERIFY_E error.<br />I step into the function:<br />- 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).<br />- the wc_RsaSSL_Verify (responsible to decrypt the signature) returned 51 as decrypted message length (store in plain_data array).<br />So the verification failed and return SIG_VERIFY_E because the decrypted message (plain_data) is different than the expected one (hash_data).<br />But I look into the plain_data content and, even if it&#039;s larger than hash (51 &gt; 32), it contains at the end of the array the hash data value.<br />Let me show an example:<br />hash_data[32] = [0x11, 0x22, 0x33, 0x44, ....]<br />plain_data[256] = [0xFF, 0xFF, ..., 0xXX, 0xXX, 0xXX, ..., 0x11, 0x22, 0x33, 0x44, ....]<br />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.</p><p>How do you explain this strange behavior? Do I made a mistake in the signing computation or is it a issue in the library?</p><p>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.<br />It a temporally fix to go further in my testing but I don&#039;t know if it&#039;s a good solution. I don&#039;t want to hide an other problem.</p><p>many thanks in advance for your answer and suggestion</p><p>Regards,</p><p>Thomas</p>]]></description>
			<author><![CDATA[null@example.com (thomas.cornu)]]></author>
			<pubDate>Thu, 17 Nov 2016 08:07:40 +0000</pubDate>
			<guid>https://www.wolfssl.com/forums/post2868.html#p2868</guid>
		</item>
	</channel>
</rss>
