My goal is to be able to sign a 256byte public RSA key with it's own private key.  (Self signed key as it were.)  I can't get the target system to accept the signature I create.  So I've set out to see if I can validate my own signature.

I start with a RSA key pair in the PKDS (call is RSAPRIM).  I also have a 256 binary message (BINMSG) that I need to sign.   I have the 256 byte public key (PUBKEY) in program storage that is a match to RSAPRIM.  I will use SHA-256 and PKCS-1.1 attributes in my efforts.

(For what it's worth, BINMSG and PUBKEY are identical)

Step 1.  Use OWH to apply a SHA-256 hash to the BINMSG to generate a 32 byte hash result.

Step 2. Use DSG to sign that 32 byte hash result using PKCS-1.1 and the RSAPRIM.   I get my first signature (FIRSTSIG).

Step 3. Use DSG to sign the BINMSG using MESSAGE, SHA-256, PKCS-1.1 and the RSAPRIM generating my second signature (SECONDSIG).

FIRSTSIG and SECONDSIG do not match.

Use PKB to create a RSA-PUBL external token (RSAPUBTKN) on the PUBKEY (256 byte RSA public key).  I use 256 bytes, 2048 bits, with exponent of 3 bytes X'010001'.    The structure contains all fixed fields up to and including the 2 byte reserved field.  Then the block has 256 byte area for the public key and a 3 byte area for the exponent value.  I did not include any of the PPP, QQQ, UUU etc fields in the structure.  I'd have no clue what to put in them anyway.  

All of the above calls return zeros.

Step 4. Use DSV with MESSAGE, PKCS-1.1 & SHA-256 rules, RSAPUBTKN, source data of BINMSG to try and validate FIRSTSIG.  That fails 4/100011. (Good return but failed sig validation).

Step 5. Use DSV with MESSAGE, PKCS-1.1 & SHA-256 rules, RSAPUBTKN, source data of BINMSG to try and validate SECONDTSIG. That fails 4/100011. (Good return but failed sig validation).

I have to be doing something wrong somewhere.  I've checked all the parameters (down to the bytes) going into and coming out of each ICSF call.  I've very sure they are all correct.

I can't explain why I get two different signature results.  I expected them to the the same.

And I can't explain why I can't validate either of the signatures that I've created.   Perhaps it has something to do with the RSAPUBTKN I created.

I have visually inspected the RSAPRIM token and confirmed that I do in fact have the corresponding 256 public RSA key in my storage (PUBKEY).   I have every reason to believe they match.

I could use a second pair of eyes.  Thanks very much for your help.

Sincerely,

My goal is to be able to sign a 256byte public RSA key with it's own private key.  (Self signed key as it were.)  I can't get the target system to accept the signature I create.  So I've set out to see if I can validate my own signature.

I start with a RSA key pair in the PKDS (call is RSAPRIM).  I also have a 256 binary message (BINMSG) that I need to sign.   I have the 256 byte public key (PUBKEY) in program storage that is a match to RSAPRIM.  I will use SHA-256 and PKCS-1.1 attributes in my efforts.

(For what it's worth, BINMSG and PUBKEY are identical)

Step 1.  Use OWH to apply a SHA-256 hash to the BINMSG to generate a 32 byte hash result.

Step 2. Use DSG to sign that 32 byte hash result using PKCS-1.1 and the RSAPRIM.   I get my first signature (FIRSTSIG).

Step 3. Use DSG to sign the BINMSG using MESSAGE, SHA-256, PKCS-1.1 and the RSAPRIM generating my second signature (SECONDSIG).

FIRSTSIG and SECONDSIG do not match.

Use PKB to create a RSA-PUBL external token (RSAPUBTKN) on the PUBKEY (256 byte RSA public key).  I use 256 bytes, 2048 bits, with exponent of 3 bytes X'010001'.    The structure contains all fixed fields up to and including the 2 byte reserved field.  Then the block has 256 byte area for the public key and a 3 byte area for the exponent value.  I did not include any of the PPP, QQQ, UUU etc fields in the structure.  I'd have no clue what to put in them anyway.  

All of the above calls return zeros.

Step 4. Use DSV with MESSAGE, PKCS-1.1 & SHA-256 rules, RSAPUBTKN, source data of BINMSG to try and validate FIRSTSIG.  That fails 4/100011. (Good return but failed sig validation).

Step 5. Use DSV with MESSAGE, PKCS-1.1 & SHA-256 rules, RSAPUBTKN, source data of BINMSG to try and validate SECONDTSIG. That fails 4/100011. (Good return but failed sig validation).

I have to be doing something wrong somewhere.  I've checked all the parameters (down to the bytes) going into and coming out of each ICSF call.  I've very sure they are all correct.

I can't explain why I get two different signature results.  I expected them to the the same.

And I can't explain why I can't validate either of the signatures that I've created.   Perhaps it has something to do with the RSAPUBTKN I created.

I have visually inspected the RSAPRIM token and confirmed that I do in fact have the corresponding 256 public RSA key in my storage (PUBKEY).   I have every reason to believe they match.

I could use a second pair of eyes.  Thanks very much for your help.

Sincerely,

Eric,

Thanks for trying to help me out.  I appreciate it.

Regarding PKCS-1.1 -->  I've noted that it seems (by eyeball) that the signature results are repeatable in my tests.  This suggests the me that the padding might consistent with the data sizes.  What am I missing about the steps 1 & 2 vs 3.  It would seem to me that step 3 is equivalent to steps 1 & 2.  What is happening different that I'm missing?  Perhaps it is when and where the padding is applied during the process?  Or something else.

Yes, I was looking at the RSA-CRT structure rather than the RSA-PUBL structure.   And now I have a question.  Since I do not have a private part of the key, I will leave the private exponent length value as zero.  My structure now looks like yours, albeit, in COBOL.

The RSA public key I have to work with is just the 256 byte public RSA key.  I get to assume the exponent is x'010001'.   If it had to specify the exponent when I created the RSA pair (in ICSF), then I did indeed use x'010001'.  It is a standard I will not stray from until I know a better, more appropriate, value to use.

I will make the structure changes and try my tests again to see if I get new results.

Thank you.

Sincerely,

My goal is to be able to sign a 256byte public RSA key with it's own private key.  (Self signed key as it were.)  I can't get the target system to accept the signature I create.  So I've set out to see if I can validate my own signature.

I start with a RSA key pair in the PKDS (call is RSAPRIM).  I also have a 256 binary message (BINMSG) that I need to sign.   I have the 256 byte public key (PUBKEY) in program storage that is a match to RSAPRIM.  I will use SHA-256 and PKCS-1.1 attributes in my efforts.

(For what it's worth, BINMSG and PUBKEY are identical)

Step 1.  Use OWH to apply a SHA-256 hash to the BINMSG to generate a 32 byte hash result.

Step 2. Use DSG to sign that 32 byte hash result using PKCS-1.1 and the RSAPRIM.   I get my first signature (FIRSTSIG).

Step 3. Use DSG to sign the BINMSG using MESSAGE, SHA-256, PKCS-1.1 and the RSAPRIM generating my second signature (SECONDSIG).

FIRSTSIG and SECONDSIG do not match.

Use PKB to create a RSA-PUBL external token (RSAPUBTKN) on the PUBKEY (256 byte RSA public key).  I use 256 bytes, 2048 bits, with exponent of 3 bytes X'010001'.    The structure contains all fixed fields up to and including the 2 byte reserved field.  Then the block has 256 byte area for the public key and a 3 byte area for the exponent value.  I did not include any of the PPP, QQQ, UUU etc fields in the structure.  I'd have no clue what to put in them anyway.  

All of the above calls return zeros.

Step 4. Use DSV with MESSAGE, PKCS-1.1 & SHA-256 rules, RSAPUBTKN, source data of BINMSG to try and validate FIRSTSIG.  That fails 4/100011. (Good return but failed sig validation).

Step 5. Use DSV with MESSAGE, PKCS-1.1 & SHA-256 rules, RSAPUBTKN, source data of BINMSG to try and validate SECONDTSIG. That fails 4/100011. (Good return but failed sig validation).

I have to be doing something wrong somewhere.  I've checked all the parameters (down to the bytes) going into and coming out of each ICSF call.  I've very sure they are all correct.

I can't explain why I get two different signature results.  I expected them to the the same.

And I can't explain why I can't validate either of the signatures that I've created.   Perhaps it has something to do with the RSAPUBTKN I created.

I have visually inspected the RSAPRIM token and confirmed that I do in fact have the corresponding 256 public RSA key in my storage (PUBKEY).   I have every reason to believe they match.

I could use a second pair of eyes.  Thanks very much for your help.

Sincerely,

"Since I do not have a private part of the key, I will leave the private exponent length value as zero." How did you call DSG without the private key?

steps 1 and 2 COULD give the same results as step 3 if you format the data a certain way. If you say "HASH" you are saying that the data is already in the correct format. If you ask for "MESSAGE" you are asking for ICSF to hash and format the message. I think you are missing the DER encoding of the hash.

For example, if the hash is '0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF'X, the input for "HASH" rule should really be 
'3031300D060960864801650304020105000420'X||
'0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF'X

Which is:

Thank you for pointing out my error regarding the repeatability of PKCS #1 signatures. Technically, PKCS-1.1 signatures can be repeatable, which is what it appears is happening here.

A terminology clarification: an RSA public key is both the modulus (256 bytes) AND the exponent (3 bytes for '010001'X).

I need to take a break but I will take another look at this later.

Eric,

Thanks for trying to help me out.  I appreciate it.

Regarding PKCS-1.1 -->  I've noted that it seems (by eyeball) that the signature results are repeatable in my tests.  This suggests the me that the padding might consistent with the data sizes.  What am I missing about the steps 1 & 2 vs 3.  It would seem to me that step 3 is equivalent to steps 1 & 2.  What is happening different that I'm missing?  Perhaps it is when and where the padding is applied during the process?  Or something else.

Yes, I was looking at the RSA-CRT structure rather than the RSA-PUBL structure.   And now I have a question.  Since I do not have a private part of the key, I will leave the private exponent length value as zero.  My structure now looks like yours, albeit, in COBOL.

The RSA public key I have to work with is just the 256 byte public RSA key.  I get to assume the exponent is x'010001'.   If it had to specify the exponent when I created the RSA pair (in ICSF), then I did indeed use x'010001'.  It is a standard I will not stray from until I know a better, more appropriate, value to use.

I will make the structure changes and try my tests again to see if I get new results.

Thank you.

Sincerely,

My goal is to be able to sign a 256byte public RSA key with it's own private key.  (Self signed key as it were.)  I can't get the target system to accept the signature I create.  So I've set out to see if I can validate my own signature.

I start with a RSA key pair in the PKDS (call is RSAPRIM).  I also have a 256 binary message (BINMSG) that I need to sign.   I have the 256 byte public key (PUBKEY) in program storage that is a match to RSAPRIM.  I will use SHA-256 and PKCS-1.1 attributes in my efforts.

(For what it's worth, BINMSG and PUBKEY are identical)

Step 1.  Use OWH to apply a SHA-256 hash to the BINMSG to generate a 32 byte hash result.

Step 2. Use DSG to sign that 32 byte hash result using PKCS-1.1 and the RSAPRIM.   I get my first signature (FIRSTSIG).

Step 3. Use DSG to sign the BINMSG using MESSAGE, SHA-256, PKCS-1.1 and the RSAPRIM generating my second signature (SECONDSIG).

FIRSTSIG and SECONDSIG do not match.

Use PKB to create a RSA-PUBL external token (RSAPUBTKN) on the PUBKEY (256 byte RSA public key).  I use 256 bytes, 2048 bits, with exponent of 3 bytes X'010001'.    The structure contains all fixed fields up to and including the 2 byte reserved field.  Then the block has 256 byte area for the public key and a 3 byte area for the exponent value.  I did not include any of the PPP, QQQ, UUU etc fields in the structure.  I'd have no clue what to put in them anyway.  

All of the above calls return zeros.

Step 4. Use DSV with MESSAGE, PKCS-1.1 & SHA-256 rules, RSAPUBTKN, source data of BINMSG to try and validate FIRSTSIG.  That fails 4/100011. (Good return but failed sig validation).

Step 5. Use DSV with MESSAGE, PKCS-1.1 & SHA-256 rules, RSAPUBTKN, source data of BINMSG to try and validate SECONDTSIG. That fails 4/100011. (Good return but failed sig validation).

I have to be doing something wrong somewhere.  I've checked all the parameters (down to the bytes) going into and coming out of each ICSF call.  I've very sure they are all correct.

I can't explain why I get two different signature results.  I expected them to the the same.

And I can't explain why I can't validate either of the signatures that I've created.   Perhaps it has something to do with the RSAPUBTKN I created.

I have visually inspected the RSAPRIM token and confirmed that I do in fact have the corresponding 256 public RSA key in my storage (PUBKEY).   I have every reason to believe they match.

I could use a second pair of eyes.  Thanks very much for your help.

Sincerely,

Eric,

Thanks very much for your help.  We are making progress.

I had no idea that I needed to wrap the HASH in a DER block.  I'll work on that for my next test.   But if the DER wrapping was the problem, then the second signature should have validated.

I have the private key in the PKDS file under a 64 character label.

A while back, I created a 256 byte RSA private-public key pair.  I extracted the public key for use later.   It is these two pieces of information that I use to generate the signatures and to validate them too.

I'll get this test done on Monday and let you know how I'm progressing.

Sincerely,

"Since I do not have a private part of the key, I will leave the private exponent length value as zero." How did you call DSG without the private key?

steps 1 and 2 COULD give the same results as step 3 if you format the data a certain way. If you say "HASH" you are saying that the data is already in the correct format. If you ask for "MESSAGE" you are asking for ICSF to hash and format the message. I think you are missing the DER encoding of the hash.

For example, if the hash is '0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF'X, the input for "HASH" rule should really be 
'3031300D060960864801650304020105000420'X||
'0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF'X

Which is:

Thank you for pointing out my error regarding the repeatability of PKCS #1 signatures. Technically, PKCS-1.1 signatures can be repeatable, which is what it appears is happening here.

A terminology clarification: an RSA public key is both the modulus (256 bytes) AND the exponent (3 bytes for '010001'X).

I need to take a break but I will take another look at this later.

Eric,

Thanks for trying to help me out.  I appreciate it.

Regarding PKCS-1.1 -->  I've noted that it seems (by eyeball) that the signature results are repeatable in my tests.  This suggests the me that the padding might consistent with the data sizes.  What am I missing about the steps 1 & 2 vs 3.  It would seem to me that step 3 is equivalent to steps 1 & 2.  What is happening different that I'm missing?  Perhaps it is when and where the padding is applied during the process?  Or something else.

Yes, I was looking at the RSA-CRT structure rather than the RSA-PUBL structure.   And now I have a question.  Since I do not have a private part of the key, I will leave the private exponent length value as zero.  My structure now looks like yours, albeit, in COBOL.

The RSA public key I have to work with is just the 256 byte public RSA key.  I get to assume the exponent is x'010001'.   If it had to specify the exponent when I created the RSA pair (in ICSF), then I did indeed use x'010001'.  It is a standard I will not stray from until I know a better, more appropriate, value to use.

I will make the structure changes and try my tests again to see if I get new results.

Thank you.

Sincerely,

My goal is to be able to sign a 256byte public RSA key with it's own private key.  (Self signed key as it were.)  I can't get the target system to accept the signature I create.  So I've set out to see if I can validate my own signature.

I start with a RSA key pair in the PKDS (call is RSAPRIM).  I also have a 256 binary message (BINMSG) that I need to sign.   I have the 256 byte public key (PUBKEY) in program storage that is a match to RSAPRIM.  I will use SHA-256 and PKCS-1.1 attributes in my efforts.

(For what it's worth, BINMSG and PUBKEY are identical)

Step 1.  Use OWH to apply a SHA-256 hash to the BINMSG to generate a 32 byte hash result.

Step 2. Use DSG to sign that 32 byte hash result using PKCS-1.1 and the RSAPRIM.   I get my first signature (FIRSTSIG).

Step 3. Use DSG to sign the BINMSG using MESSAGE, SHA-256, PKCS-1.1 and the RSAPRIM generating my second signature (SECONDSIG).

FIRSTSIG and SECONDSIG do not match.

Use PKB to create a RSA-PUBL external token (RSAPUBTKN) on the PUBKEY (256 byte RSA public key).  I use 256 bytes, 2048 bits, with exponent of 3 bytes X'010001'.    The structure contains all fixed fields up to and including the 2 byte reserved field.  Then the block has 256 byte area for the public key and a 3 byte area for the exponent value.  I did not include any of the PPP, QQQ, UUU etc fields in the structure.  I'd have no clue what to put in them anyway.  

All of the above calls return zeros.

Step 4. Use DSV with MESSAGE, PKCS-1.1 & SHA-256 rules, RSAPUBTKN, source data of BINMSG to try and validate FIRSTSIG.  That fails 4/100011. (Good return but failed sig validation).

Step 5. Use DSV with MESSAGE, PKCS-1.1 & SHA-256 rules, RSAPUBTKN, source data of BINMSG to try and validate SECONDTSIG. That fails 4/100011. (Good return but failed sig validation).

I have to be doing something wrong somewhere.  I've checked all the parameters (down to the bytes) going into and coming out of each ICSF call.  I've very sure they are all correct.

I can't explain why I get two different signature results.  I expected them to the the same.

And I can't explain why I can't validate either of the signatures that I've created.   Perhaps it has something to do with the RSAPUBTKN I created.

I have visually inspected the RSAPRIM token and confirmed that I do in fact have the corresponding 256 public RSA key in my storage (PUBKEY).   I have every reason to believe they match.

I could use a second pair of eyes.  Thanks very much for your help.

Sincerely,

My goal is to be able to sign a 256byte public RSA key with it's own private key.  (Self signed key as it were.)  I can't get the target system to accept the signature I create.  So I've set out to see if I can validate my own signature.

I start with a RSA key pair in the PKDS (call is RSAPRIM).  I also have a 256 binary message (BINMSG) that I need to sign.   I have the 256 byte public key (PUBKEY) in program storage that is a match to RSAPRIM.  I will use SHA-256 and PKCS-1.1 attributes in my efforts.

(For what it's worth, BINMSG and PUBKEY are identical)

Step 1.  Use OWH to apply a SHA-256 hash to the BINMSG to generate a 32 byte hash result.

Step 2. Use DSG to sign that 32 byte hash result using PKCS-1.1 and the RSAPRIM.   I get my first signature (FIRSTSIG).

Step 3. Use DSG to sign the BINMSG using MESSAGE, SHA-256, PKCS-1.1 and the RSAPRIM generating my second signature (SECONDSIG).

FIRSTSIG and SECONDSIG do not match.

Use PKB to create a RSA-PUBL external token (RSAPUBTKN) on the PUBKEY (256 byte RSA public key).  I use 256 bytes, 2048 bits, with exponent of 3 bytes X'010001'.    The structure contains all fixed fields up to and including the 2 byte reserved field.  Then the block has 256 byte area for the public key and a 3 byte area for the exponent value.  I did not include any of the PPP, QQQ, UUU etc fields in the structure.  I'd have no clue what to put in them anyway.  

All of the above calls return zeros.

Step 4. Use DSV with MESSAGE, PKCS-1.1 & SHA-256 rules, RSAPUBTKN, source data of BINMSG to try and validate FIRSTSIG.  That fails 4/100011. (Good return but failed sig validation).

Step 5. Use DSV with MESSAGE, PKCS-1.1 & SHA-256 rules, RSAPUBTKN, source data of BINMSG to try and validate SECONDTSIG. That fails 4/100011. (Good return but failed sig validation).

I have to be doing something wrong somewhere.  I've checked all the parameters (down to the bytes) going into and coming out of each ICSF call.  I've very sure they are all correct.

I can't explain why I get two different signature results.  I expected them to the the same.

And I can't explain why I can't validate either of the signatures that I've created.   Perhaps it has something to do with the RSAPUBTKN I created.

I have visually inspected the RSAPRIM token and confirmed that I do in fact have the corresponding 256 public RSA key in my storage (PUBKEY).   I have every reason to believe they match.

I could use a second pair of eyes.  Thanks very much for your help.

Sincerely,

My goal is to be able to sign a 256byte public RSA key with it's own private key.  (Self signed key as it were.)  I can't get the target system to accept the signature I create.  So I've set out to see if I can validate my own signature.

I start with a RSA key pair in the PKDS (call is RSAPRIM).  I also have a 256 binary message (BINMSG) that I need to sign.   I have the 256 byte public key (PUBKEY) in program storage that is a match to RSAPRIM.  I will use SHA-256 and PKCS-1.1 attributes in my efforts.

(For what it's worth, BINMSG and PUBKEY are identical)

Step 1.  Use OWH to apply a SHA-256 hash to the BINMSG to generate a 32 byte hash result.

Step 2. Use DSG to sign that 32 byte hash result using PKCS-1.1 and the RSAPRIM.   I get my first signature (FIRSTSIG).

Step 3. Use DSG to sign the BINMSG using MESSAGE, SHA-256, PKCS-1.1 and the RSAPRIM generating my second signature (SECONDSIG).

FIRSTSIG and SECONDSIG do not match.

Use PKB to create a RSA-PUBL external token (RSAPUBTKN) on the PUBKEY (256 byte RSA public key).  I use 256 bytes, 2048 bits, with exponent of 3 bytes X'010001'.    The structure contains all fixed fields up to and including the 2 byte reserved field.  Then the block has 256 byte area for the public key and a 3 byte area for the exponent value.  I did not include any of the PPP, QQQ, UUU etc fields in the structure.  I'd have no clue what to put in them anyway.  

All of the above calls return zeros.

Step 4. Use DSV with MESSAGE, PKCS-1.1 & SHA-256 rules, RSAPUBTKN, source data of BINMSG to try and validate FIRSTSIG.  That fails 4/100011. (Good return but failed sig validation).

Step 5. Use DSV with MESSAGE, PKCS-1.1 & SHA-256 rules, RSAPUBTKN, source data of BINMSG to try and validate SECONDTSIG. That fails 4/100011. (Good return but failed sig validation).

I have to be doing something wrong somewhere.  I've checked all the parameters (down to the bytes) going into and coming out of each ICSF call.  I've very sure they are all correct.

I can't explain why I get two different signature results.  I expected them to the the same.

And I can't explain why I can't validate either of the signatures that I've created.   Perhaps it has something to do with the RSAPUBTKN I created.

I have visually inspected the RSAPRIM token and confirmed that I do in fact have the corresponding 256 public RSA key in my storage (PUBKEY).   I have every reason to believe they match.

I could use a second pair of eyes.  Thanks very much for your help.

Sincerely,

Okay, my 8 / 72 error was because of my PKB structure.  I had an extra halfword field in the structure.  Once I removed it, I am now back to the 4 / 11000 errors for my DSV calls again.

My goal is to be able to sign a 256byte public RSA key with it's own private key.  (Self signed key as it were.)  I can't get the target system to accept the signature I create.  So I've set out to see if I can validate my own signature.

I start with a RSA key pair in the PKDS (call is RSAPRIM).  I also have a 256 binary message (BINMSG) that I need to sign.   I have the 256 byte public key (PUBKEY) in program storage that is a match to RSAPRIM.  I will use SHA-256 and PKCS-1.1 attributes in my efforts.

(For what it's worth, BINMSG and PUBKEY are identical)

Step 1.  Use OWH to apply a SHA-256 hash to the BINMSG to generate a 32 byte hash result.

Step 2. Use DSG to sign that 32 byte hash result using PKCS-1.1 and the RSAPRIM.   I get my first signature (FIRSTSIG).

Step 3. Use DSG to sign the BINMSG using MESSAGE, SHA-256, PKCS-1.1 and the RSAPRIM generating my second signature (SECONDSIG).

FIRSTSIG and SECONDSIG do not match.

Use PKB to create a RSA-PUBL external token (RSAPUBTKN) on the PUBKEY (256 byte RSA public key).  I use 256 bytes, 2048 bits, with exponent of 3 bytes X'010001'.    The structure contains all fixed fields up to and including the 2 byte reserved field.  Then the block has 256 byte area for the public key and a 3 byte area for the exponent value.  I did not include any of the PPP, QQQ, UUU etc fields in the structure.  I'd have no clue what to put in them anyway.  

All of the above calls return zeros.

Step 4. Use DSV with MESSAGE, PKCS-1.1 & SHA-256 rules, RSAPUBTKN, source data of BINMSG to try and validate FIRSTSIG.  That fails 4/100011. (Good return but failed sig validation).

Step 5. Use DSV with MESSAGE, PKCS-1.1 & SHA-256 rules, RSAPUBTKN, source data of BINMSG to try and validate SECONDTSIG. That fails 4/100011. (Good return but failed sig validation).

I have to be doing something wrong somewhere.  I've checked all the parameters (down to the bytes) going into and coming out of each ICSF call.  I've very sure they are all correct.

I can't explain why I get two different signature results.  I expected them to the the same.

And I can't explain why I can't validate either of the signatures that I've created.   Perhaps it has something to do with the RSAPUBTKN I created.

I have visually inspected the RSAPRIM token and confirmed that I do in fact have the corresponding 256 public RSA key in my storage (PUBKEY).   I have every reason to believe they match.

I could use a second pair of eyes.  Thanks very much for your help.

Sincerely,

I've made significant progress.  The extra DER for step 1 made all the difference.  My failure to pass the entire message to step 3 to create the second digital signature was also corrected.   I can now create signatures two different ways that are equal and verify both with the public RSA key using DSV.

Unfortunately the device I pass the data and signature to, cannot validate my signature.   

I have a question regarding the signature generating process...

I see this in the EMSA-PKCS-v1.5 steps to pad the message.   EM = 0x00 || 0x01 || PS || 0x00 || T

The T is the DER wrapped hash result.  In my case it is 51 bytes.

I believe the PS portion is a number of 0xFF bytes numbering (in my case)  256-3-51 = 202 bytes.

Does DSG apply this for me, or do I need to do this myself prior to generating the signature?   I am wanting to believe the specifying PKCS-1.1 makes this happen in the ICSF DSG call.   Am I correct in my understanding?

Sincerely,

Okay, my 8 / 72 error was because of my PKB structure.  I had an extra halfword field in the structure.  Once I removed it, I am now back to the 4 / 11000 errors for my DSV calls again.

My goal is to be able to sign a 256byte public RSA key with it's own private key.  (Self signed key as it were.)  I can't get the target system to accept the signature I create.  So I've set out to see if I can validate my own signature.

I start with a RSA key pair in the PKDS (call is RSAPRIM).  I also have a 256 binary message (BINMSG) that I need to sign.   I have the 256 byte public key (PUBKEY) in program storage that is a match to RSAPRIM.  I will use SHA-256 and PKCS-1.1 attributes in my efforts.

(For what it's worth, BINMSG and PUBKEY are identical)

Step 1.  Use OWH to apply a SHA-256 hash to the BINMSG to generate a 32 byte hash result.

Step 2. Use DSG to sign that 32 byte hash result using PKCS-1.1 and the RSAPRIM.   I get my first signature (FIRSTSIG).

Step 3. Use DSG to sign the BINMSG using MESSAGE, SHA-256, PKCS-1.1 and the RSAPRIM generating my second signature (SECONDSIG).

FIRSTSIG and SECONDSIG do not match.

Use PKB to create a RSA-PUBL external token (RSAPUBTKN) on the PUBKEY (256 byte RSA public key).  I use 256 bytes, 2048 bits, with exponent of 3 bytes X'010001'.    The structure contains all fixed fields up to and including the 2 byte reserved field.  Then the block has 256 byte area for the public key and a 3 byte area for the exponent value.  I did not include any of the PPP, QQQ, UUU etc fields in the structure.  I'd have no clue what to put in them anyway.  

All of the above calls return zeros.

Step 4. Use DSV with MESSAGE, PKCS-1.1 & SHA-256 rules, RSAPUBTKN, source data of BINMSG to try and validate FIRSTSIG.  That fails 4/100011. (Good return but failed sig validation).

Step 5. Use DSV with MESSAGE, PKCS-1.1 & SHA-256 rules, RSAPUBTKN, source data of BINMSG to try and validate SECONDTSIG. That fails 4/100011. (Good return but failed sig validation).

I have to be doing something wrong somewhere.  I've checked all the parameters (down to the bytes) going into and coming out of each ICSF call.  I've very sure they are all correct.

I can't explain why I get two different signature results.  I expected them to the the same.

And I can't explain why I can't validate either of the signatures that I've created.   Perhaps it has something to do with the RSAPUBTKN I created.

I have visually inspected the RSAPRIM token and confirmed that I do in fact have the corresponding 256 public RSA key in my storage (PUBKEY).   I have every reason to believe they match.

I could use a second pair of eyes.  Thanks very much for your help.

Sincerely,

I see this in the EMSA-PKCS-v1.5 steps to pad the message.   EM = 0x00 || 0x01 || PS || 0x00 || T

The T is the DER wrapped hash result.  In my case it is 51 bytes.

I believe the PS portion is a number of 0xFF bytes numbering (in my case)  256-3-51 = 202 bytes.

Does DSG apply this for me, or do I need to do this myself prior to generating the signature?   I am wanting to believe the specifying PKCS-1.1 makes this happen in the ICSF DSG call.   Am I correct in my understanding?

Your understanding is correct. If you use the "HASH" rule, you provide the T value directly (which is why it needed the DER encoding). If you use the "MESSAGE" rule, T is calculated by DSG by DER-encoding H(SHA-256,M).

I've made significant progress.  The extra DER for step 1 made all the difference.  My failure to pass the entire message to step 3 to create the second digital signature was also corrected.   I can now create signatures two different ways that are equal and verify both with the public RSA key using DSV.

Unfortunately the device I pass the data and signature to, cannot validate my signature.   

I have a question regarding the signature generating process...

I see this in the EMSA-PKCS-v1.5 steps to pad the message.   EM = 0x00 || 0x01 || PS || 0x00 || T

The T is the DER wrapped hash result.  In my case it is 51 bytes.

I believe the PS portion is a number of 0xFF bytes numbering (in my case)  256-3-51 = 202 bytes.

Does DSG apply this for me, or do I need to do this myself prior to generating the signature?   I am wanting to believe the specifying PKCS-1.1 makes this happen in the ICSF DSG call.   Am I correct in my understanding?

Sincerely,

Okay, my 8 / 72 error was because of my PKB structure.  I had an extra halfword field in the structure.  Once I removed it, I am now back to the 4 / 11000 errors for my DSV calls again.

My goal is to be able to sign a 256byte public RSA key with it's own private key.  (Self signed key as it were.)  I can't get the target system to accept the signature I create.  So I've set out to see if I can validate my own signature.

I start with a RSA key pair in the PKDS (call is RSAPRIM).  I also have a 256 binary message (BINMSG) that I need to sign.   I have the 256 byte public key (PUBKEY) in program storage that is a match to RSAPRIM.  I will use SHA-256 and PKCS-1.1 attributes in my efforts.

(For what it's worth, BINMSG and PUBKEY are identical)

Step 1.  Use OWH to apply a SHA-256 hash to the BINMSG to generate a 32 byte hash result.

Step 2. Use DSG to sign that 32 byte hash result using PKCS-1.1 and the RSAPRIM.   I get my first signature (FIRSTSIG).

Step 3. Use DSG to sign the BINMSG using MESSAGE, SHA-256, PKCS-1.1 and the RSAPRIM generating my second signature (SECONDSIG).

FIRSTSIG and SECONDSIG do not match.

Use PKB to create a RSA-PUBL external token (RSAPUBTKN) on the PUBKEY (256 byte RSA public key).  I use 256 bytes, 2048 bits, with exponent of 3 bytes X'010001'.    The structure contains all fixed fields up to and including the 2 byte reserved field.  Then the block has 256 byte area for the public key and a 3 byte area for the exponent value.  I did not include any of the PPP, QQQ, UUU etc fields in the structure.  I'd have no clue what to put in them anyway.  

All of the above calls return zeros.

Step 4. Use DSV with MESSAGE, PKCS-1.1 & SHA-256 rules, RSAPUBTKN, source data of BINMSG to try and validate FIRSTSIG.  That fails 4/100011. (Good return but failed sig validation).

Step 5. Use DSV with MESSAGE, PKCS-1.1 & SHA-256 rules, RSAPUBTKN, source data of BINMSG to try and validate SECONDTSIG. That fails 4/100011. (Good return but failed sig validation).

I have to be doing something wrong somewhere.  I've checked all the parameters (down to the bytes) going into and coming out of each ICSF call.  I've very sure they are all correct.

I can't explain why I get two different signature results.  I expected them to the the same.

And I can't explain why I can't validate either of the signatures that I've created.   Perhaps it has something to do with the RSAPUBTKN I created.

I have visually inspected the RSAPRIM token and confirmed that I do in fact have the corresponding 256 public RSA key in my storage (PUBKEY).   I have every reason to believe they match.

I could use a second pair of eyes.  Thanks very much for your help.

Sincerely,

Eric,

This was all exceptionally helpful.   I believe all my questions are answered here.   One day I hope to return the favor.

Thanks very much.

Sincerely,

I see this in the EMSA-PKCS-v1.5 steps to pad the message.   EM = 0x00 || 0x01 || PS || 0x00 || T

The T is the DER wrapped hash result.  In my case it is 51 bytes.

I believe the PS portion is a number of 0xFF bytes numbering (in my case)  256-3-51 = 202 bytes.

Does DSG apply this for me, or do I need to do this myself prior to generating the signature?   I am wanting to believe the specifying PKCS-1.1 makes this happen in the ICSF DSG call.   Am I correct in my understanding?

Your understanding is correct. If you use the "HASH" rule, you provide the T value directly (which is why it needed the DER encoding). If you use the "MESSAGE" rule, T is calculated by DSG by DER-encoding H(SHA-256,M).

I've made significant progress.  The extra DER for step 1 made all the difference.  My failure to pass the entire message to step 3 to create the second digital signature was also corrected.   I can now create signatures two different ways that are equal and verify both with the public RSA key using DSV.

Unfortunately the device I pass the data and signature to, cannot validate my signature.   

I have a question regarding the signature generating process...

I see this in the EMSA-PKCS-v1.5 steps to pad the message.   EM = 0x00 || 0x01 || PS || 0x00 || T

The T is the DER wrapped hash result.  In my case it is 51 bytes.

I believe the PS portion is a number of 0xFF bytes numbering (in my case)  256-3-51 = 202 bytes.

Does DSG apply this for me, or do I need to do this myself prior to generating the signature?   I am wanting to believe the specifying PKCS-1.1 makes this happen in the ICSF DSG call.   Am I correct in my understanding?

Sincerely,

Okay, my 8 / 72 error was because of my PKB structure.  I had an extra halfword field in the structure.  Once I removed it, I am now back to the 4 / 11000 errors for my DSV calls again.

My goal is to be able to sign a 256byte public RSA key with it's own private key.  (Self signed key as it were.)  I can't get the target system to accept the signature I create.  So I've set out to see if I can validate my own signature.

I start with a RSA key pair in the PKDS (call is RSAPRIM).  I also have a 256 binary message (BINMSG) that I need to sign.   I have the 256 byte public key (PUBKEY) in program storage that is a match to RSAPRIM.  I will use SHA-256 and PKCS-1.1 attributes in my efforts.

(For what it's worth, BINMSG and PUBKEY are identical)

Step 1.  Use OWH to apply a SHA-256 hash to the BINMSG to generate a 32 byte hash result.

Step 2. Use DSG to sign that 32 byte hash result using PKCS-1.1 and the RSAPRIM.   I get my first signature (FIRSTSIG).

Step 3. Use DSG to sign the BINMSG using MESSAGE, SHA-256, PKCS-1.1 and the RSAPRIM generating my second signature (SECONDSIG).

FIRSTSIG and SECONDSIG do not match.

Use PKB to create a RSA-PUBL external token (RSAPUBTKN) on the PUBKEY (256 byte RSA public key).  I use 256 bytes, 2048 bits, with exponent of 3 bytes X'010001'.    The structure contains all fixed fields up to and including the 2 byte reserved field.  Then the block has 256 byte area for the public key and a 3 byte area for the exponent value.  I did not include any of the PPP, QQQ, UUU etc fields in the structure.  I'd have no clue what to put in them anyway.  

All of the above calls return zeros.

Step 4. Use DSV with MESSAGE, PKCS-1.1 & SHA-256 rules, RSAPUBTKN, source data of BINMSG to try and validate FIRSTSIG.  That fails 4/100011. (Good return but failed sig validation).

Step 5. Use DSV with MESSAGE, PKCS-1.1 & SHA-256 rules, RSAPUBTKN, source data of BINMSG to try and validate SECONDTSIG. That fails 4/100011. (Good return but failed sig validation).

I have to be doing something wrong somewhere.  I've checked all the parameters (down to the bytes) going into and coming out of each ICSF call.  I've very sure they are all correct.

I can't explain why I get two different signature results.  I expected them to the the same.

And I can't explain why I can't validate either of the signatures that I've created.   Perhaps it has something to do with the RSAPUBTKN I created.

I have visually inspected the RSAPRIM token and confirmed that I do in fact have the corresponding 256 public RSA key in my storage (PUBKEY).   I have every reason to believe they match.

I could use a second pair of eyes.  Thanks very much for your help.

Sincerely,