Question for the GURUs

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Question for the GURUs

Umberto Rustichelli aka Ubi


Dear all, I have been digging a bit into the OpenSC and OpenSSL code
because I have a doubt.

Using keys on smart cards via the OpenSC engine, I am almost sure that
by producing a PKCS7 the signature is of type "sha1WithRSAEncryption"
(at least without any special options), that implies using specific
kinds of padding for the digest before the RSA encryption, for instance.

The signature in the PKCS7, though, is marked as an object of type
"rsaEncryption" (can tell with the asn1parse command).

Is it correct to say that they are are the same, or, better, that

1) "rsaEncryption" includes the "sha1WithRSAEncryption" type

2) "sha1WithRSAEncryption" is what the PKCS7 API does by default?
     (I know, this is rather an OpenSSL-related question)

Do you think that specifying better would be an advantage?

Otherwise, if "sha1WithRSAEncryption" is not included in
"rsaEncryption", which is the actual difference when signing with smart
cards and engine_pkcs#11?

Thanks
_______________________________________________
opensc-user mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-user
Reply | Threaded
Open this post in threaded view
|

Re: [opensc-devel] Question for the GURUs

Umberto Rustichelli aka Ubi
Andre Zepezauer wrote:

> On Thu, 2010-09-23 at 15:50 +0200, Andre Zepezauer wrote:
>  
>> On Thu, 2010-09-23 at 14:19 +0200, Umberto Rustichelli aka Ubi wrote:
>>    
>>> Dear all, I have been digging a bit into the OpenSC and OpenSSL code
>>> because I have a doubt.
>>>
>>> Using keys on smart cards via the OpenSC engine, I am almost sure that
>>> by producing a PKCS7 the signature is of type "sha1WithRSAEncryption"
>>> (at least without any special options), that implies using specific
>>> kinds of padding for the digest before the RSA encryption, for instance.
>>>
>>> The signature in the PKCS7, though, is marked as an object of type
>>> "rsaEncryption" (can tell with the asn1parse command).
>>>
>>> Is it correct to say that they are are the same, or, better, that
>>>
>>> 1) "rsaEncryption" includes the "sha1WithRSAEncryption" type
>>>
>>> 2) "sha1WithRSAEncryption" is what the PKCS7 API does by default?
>>>      (I know, this is rather an OpenSSL-related question)
>>>      
>> You can find the corresponding definitions in [1] section 11. My
>> conclusion is, that both algorithms apply a pkcs1 padding before
>> exponentiation. And "sha1WithRSAEncryption" hashes input data before
>> padding but "rsaEncryption" doesn't do that.
>>
>>    



>> "Signature algorithms are always used in conjunction with a one-way hash
>> function." [2]
>>
>> Therefore it is an error when the algorithm identifier carried with a
>> signature is "rsaEncryption". Right?
>>    
>
> Ooops. Excerpt [2] only applies to X509 certificates and crls. What is
> required for pkcs7 signatures?
>
>  
I am specifically talking of PKCS#7 signedData, not detached, so it is,
in brief:
ORIGINAL CONTENT + SIGNER'S CERTIFICATE + SIGNER INFO that includes the
signature.
Signature is the RSA encryption of the hash of the content or, if
authenticated attributes are present in signer info, of the hash of
authenticated attributes.
If they are present, they also contain the hash of the original content,
so indirectly you're also signing the hash of the original content.
This is the theory and also what OpenSSL does, at least according to my
inspection of the code.
You can use more than one hash type, so you are free to end with a
"rsaEncryption" object (OpenSSL), but I know that other vendors produce
sha1WithRSAEncryption and/or sha256WithRSAEncryption. I hope this
answers your question.

Back to your reply, you're signing a hash, but for what I understand you
are telling me that such hash is re-hashed before padding...
I'm going back to the code and to the documents you've sent me to
understand things better, thank you very much.

>> [1] http://tools.ietf.org/html/rfc2313
>> [2] http://tools.ietf.org/html/rfc3279#section-2.2
>>
>>
>> _______________________________________________
>> opensc-devel mailing list
>> [hidden email]
>> http://www.opensc-project.org/mailman/listinfo/opensc-devel
>>    
>
>
>  

_______________________________________________
opensc-user mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-user