> From: owner-openssl-us...@openssl.org On Behalf Of TSCOconan > Sent: Tuesday, 18 October, 2011 14:57
> I'm trying to implement certificate signature verification > <snip> on a Microchip pic controller. <snip> > After reading PKCS#1 V2.1 <snip> > I realized that encryption is essentially the same as > signature verification > and decryption is the same as signing. <snip> Therefore, > I'm trying to use the encryption algorithm provided to > perform signature > verification. > Raw RSA encrypt/decrypt are the same as verify/sign, but the standard paddings are different. (PKCS#1 type2 padding for encrypt is similar to type1 padding for sign but not identical, and it proved vulnerable in application so it was mostly superseded by OAEP which is very different. And encrypt is pad-then-modexp-pub while verify is modexp-pub-then-unpad.) > In order to verify the certificate, <snip usual> > openssl rsautl -verify -in signature.txt -inkey pubkey.pem > -pubin -raw -hexdump > 00 01 ff ff ff ff ff ff-ff ff ff ff 00 30 21 30 > 09 06 05 2b 0e 03 02 1a-05 00 04 14 db e8 c6 cb > 78 19 3c 0f fd 96 1c 4f-ed bd b2 34 45 60 bf 65 > I believe this is what I should get after decoding the > signature. After > removing "ff" paddings I'll end up with asn1 format of the > certificate hash. > Yes. (To be exact, removing type 01, at least 8 IIRC FF's, and delimiter 00; those are all part of the padding.) > However this is what I got from the PIC controller which is > much different > 8e fb 62 0e 09 c8 0b 49 40 1f 4d 2d a7 7d d6 8c > 9b bc 95 e6 bc 98 4b 96 aa 74 e5 68 90 40 bf 43 > b5 c5 02 6d ab e3 ad 7b e6 98 fd 10 22 af b9 fb > I'm not sure what that encryption primitive is doing. Does it take any kind of setting to do padding or not? If it is doing any real padding it should reject your call because no padding scheme can encrypt a 384-bit (or even 376-bit) value with a 384-bit key. Maybe it is failing to return the error or you are failing to recognize it. If it is supposed to be doing unpadded something is wrong. <snip data> > This is my public key (I'm using a very small key just for > testing, will make it larger once everything works) I suggest you use a key large enough to give OAEP some elbow room, at least 512. Then try encrypting several known short values like 01; 01 02; 01 02 03; etc. and see if rsautl -decrypt -raw or -oaep gives them back. (Or maybe -pkcs, but as noted that is rare these days.) Increase up to the length you need (about 48 bytes). If you can get raw-encrypt to match, you can use it for the modexp-pub part of verify. (And the rest is, as you correctly described, relatively simple.) ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
