On 4/13/17, 5:58 PM, "openssl-dev on behalf of Richard Levitte" <openssl-dev-boun...@openssl.org on behalf of levi...@openssl.org> wrote:
deengert> > uri> $ openssl rsautl -engine pkcs11 -keyform ENGINE -decrypt
-inkey
deengert> >
"pkcs11:manufacturer=piv_II;object=KEY%20MAN%20key;type=private" -oaep
deengert> > -in t256.dat.enc -out t256.dat.dec
Replacing, as Richard suggested, rsautl with pkeyutl resulted in a successful
decryption of the previously encrypted message:
$ openssl pkeyutl -engine pkcs11 -keyform ENGINE -decrypt -inkey
"pkcs11:manufacturer=piv_II;object=KEY%20MAN%20key;type=private" -pkeyopt
rsa_padding_mode:oaep -in t256.dat.enc -out t256.dat.dec
engine "pkcs11" set.
Enter PKCS#11 token PIN for PIV Card Holder pin (PIV_II):
$ cmp t256.dat t256.dat.dec
$
. . . . . rsautl is a poor choice, as it uses the RSA
API. For something more general and with a whole lot more
functionality, pkeyutl is the better choice.
Your suggestion worked perfectly – I didn’t even need to provide any
parameters, besides specifying the padding mode.
Does it mean that rsautl is pretty much deprecated, and pkeyutl superseded it?
Or is it still worth bringing it “up to snuff”?
Incidently, for decryption, it will end up calling exactly the code
you're citing,
( What a coincidence!
and with -pkeyopt, you can specify the padding mode and
its necessary data.
Yep, and thanks for the great suggestion! Now whether rsautl.c is fixed or not
- is no longer critical (though since it’s still included in the codebase,
perhaps it could be made more capable?).
Thanks!
smime.p7s
Description: S/MIME cryptographic signature
-- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
