On 09/08/2010 05:52 AM, tedx wrote:
> On Sep 8, 3:09 am, Nelson B <nel...@bolyard.me> wrote:
>
>> On 2010/09/07 17:08 PDT, tedx wrote:
>>
>>
>>> I've hacked up something to try but I've now encountered a
>>> compilation error that I don't understand. Has anyone else seen this?
>>> nss_signing.c: In function ‘spl_nssVerifySignature’:
>>> nss_signing.c:172: error: storage size of ‘vfy_context’ isn’t known
>>> cc1: warnings being treated as errors
>>> nss_signing.c:172: error: unused variable ‘vfy_context’
>>>
>> I suggest you change your warning settings, so that warnings are no
>> longer treated as errors.
>>
>> NSS's type VFYContext is an opaque type.
>> seehttp://mxr.mozilla.org/security/ident?i=VFYContext
>>
>> You can never declare an instance of it. You can only declare a pointer
>> to it. You get a pointer to it by calling one of the VFY_CreateContext
>> variants. You destroy it by calling VFY_DestroyContext. You never get
>> to see what's inside it, or know how big it is.
>>
>> It appears that you tried to declare a VFYContext variable instance,
>> which was an error, but then you didn't use it, which was also an error.
>> The simplest solution is to get rid of it. :)
>>
> Oops left the * off the pointer declaration :0, Now I'll see if it
> works. I am however still concerned that I don't fully understand
> how to determine the signature algorithms.
Signature algorithm IDs are the NSS representation of the ASN wrapping
for signatures. All normal signatures have them, most notably
certificates and PKCS #7/CMS signed blobs (S/MIME).
The idea behind using them in your application is you can always ask NSS
to extract them from your ANS.1 blob, and you as an application do not
need to add any special code for handling various types of hash/signing
algorihtms
When we add new hash/signing algorithms occur, I will usually
encapsulate all that knowledge into secvfy.c It will parse the
parameters in the asn.1 signatureAlgorithm, so you as an application
don't need to deal with that.
Your sample app does not provide an ASN.1 encoded signature, in fact it
does not provide any indication about how the data was signed (which if
you use that in a protocol, you may find some issues). If you are
setting up your own protocol, I highly suggest that you at least ASN.1
sign your data, and preferably use pkcs #7. This is the primary reason
you are having a hard time finding examples, you are trying do so all
these functions at a very low level.
If you are trying to match an existing protocol that does not use ANS.1,
then you really want to use VFY_CreateContextDirect.
Finally you are going way low level. You should try using the SGN
functions rather than going directly to the PK11 underlying function
calls. PK11_Sign is not likely to do what you think it does (It does not
add the RSA PKCS #1 DER encoding oid, so your signatures will not
verify). Difference between various asymmetric signing algorithms are
still visible at the PKCS #11 level.
My guess is you are probably running into a bug I just noticed from
inspection. This will case both SGN and VFY to fail for RSA SHA-2
signatures, except for the VFY_CreateContextDirect case.
===================================================================
RCS file: /cvsroot/mozilla/security/nss/lib/cryptohi/secvfy.c,v
retrieving revision 1.24
diff -u -r1.24 secvfy.c
--- secvfy.c 23 Jun 2010 02:13:56 -0000 1.24
+++ secvfy.c 8 Sep 2010 23:44:35 -0000
@@ -240,7 +240,15 @@
case SEC_OID_PKCS1_RSA_PSS_SIGNATURE:
*hashalg = SEC_OID_UNKNOWN; /* get it from the RSA signature */
break;
-
+ case SEC_OID_PKCS1_SHA256_WITH_RSA_ENCRYPTION:
+ *hashalg = SEC_OID_SHA256;
+ break;
+ case SEC_OID_PKCS1_SHA384_WITH_RSA_ENCRYPTION:
+ *hashalg = SEC_OID_SHA384;
+ break;
+ case SEC_OID_PKCS1_SHA512_WITH_RSA_ENCRYPTION:
+ *hashalg = SEC_OID_SHA512;
+ break;
case SEC_OID_ANSIX962_ECDSA_SHA256_SIGNATURE:
case SEC_OID_PKCS1_SHA256_WITH_RSA_ENCRYPTION:
*hashalg = SEC_OID_SHA256;
bobs-laptop(367)
> For testing I generated
> certificates but in the field someone else will be doing this
> and I have no visibility into how they do it. You mentioned earlier
> that some public keys support multiple signature algorithms.
> How do I determine which algorithms the public key I'm supports? How
> do I tell VFY about these multiple algorithms? Thanks
> again for your help.
>
> Ted
>
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
