Bad signature when generating key in OpenPGP Java Card Applet

[Erik Nellessen]

You are right, the applet does not compute the signature as described in the specification.

Maybe the cause of the problem is, that the environment on my android smartphone behaves differently than on a real Java Card when creating the PKCS1 padding. The question is, if the padding creation in the smartphone environment is not correct according to PKCS1. It could also be, that PKCS1 does not prescribe padding to the full key length and both paddings are correct according to PKCS1.

In any case, I will raise the question in jCardSim, which provides the RSA interfaces on the smartphone.

For now, thank you very much!

Erik

NIIBE Yutaka:
> On 04/11/2016 10:40 PM, NIIBE Yutaka wrote:
>> On 04/06/2016 02:14 AM, Erik Nellessen wrote:
>>> Received APDU (57 bytes): 002A9E9A333031300D060960864801650304020105000420265A93D234241BD20BF0773B6011FD037CBE8B985D487116DC08E6914F38DBD100
>>
>> This is strange.  I think that this is the cause of your problem.
>> It should be:
>>
>>     002A9E9A20265A93D234241BD20BF0773B6011FD037CBE8B985D487116DC08E6914F38DBD100
>>
>> I mean, scdaemon removes the prefix (which specifies the hash algo)
>>
>> 	3031300D060960864801650304020105000420
>>
>> before sending card.
> 
> Sorry, I was wrong.  The APDU is correct (the prefix is removed and
> added again in the code scd/app-openpgp.c).  I didn't read the code
> of adding the prefix again, and misunderstood.
> 
> 
> I think that your OpenPGPcard implementation does some mistake for the
> calculation of length of padding string.
> 
> For 2048-bit RSA, the length of octet is 256 (N=256).  I checked
> OpenPGPcard specification.  It says (in 7.2.8 PSO: COMPUTE DIGITAL
> SIGNATURE):
> 
>     The DSI format for RSA:
>     According to PKCS #1 the DSI is generated internally by the card
>     and has the following structure:
> 
>     Description           Length  Value
>     ----------------------------------------
>     Start byte            1       00
>     Block type            1       01
>     Padding string (PS)   N-3-L   FF...FF
>     Separator             1       00
>     Data field            L       Digestinfo
>     ----------------------------------------
> 
> With SHA256 hash, L=19+32=51.  So, the length of PS should be 202
> (= 256 - 3 - 51).
> 
> It seems that it was computed as the length of PS=8 by the applet.
> 
> 
> 
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20160412/04b00eea/attachment.sig>