[EMAIL PROTECTED] - Wed Dec 6 06:32:05 2006]: > 2006/12/5, Stephen Henson via RT <[EMAIL PROTECTED]>: > > > > The sign and verify options of RSA are a kind of "raw sign" > operation. > > The PKCS#11 API does support it but some tokens do not. It is not > clear > > if the problem in your case is the PKCS#11 ENGINE not using the > relevant > > mechanism or the token not supporting it. > > No, the problem is clear, look at the source. The rsautl code calls > the wrong > function within ssl: encryption instead of signing. Thus the pkcs11 > engine have > no choice but to tell the token to encrypt. The token refuses it, as > the key is > not for encryption. > If the advertised interface states that it does siging, then it should > do signing, not encryption. It is not the case, and that is a bug. >
I wrote the source... The RSA_private_encrypt() and RSA_public_decrypt() functions despite their names are used for signing and verification operations in the manner I described. Check the source to RSA_sign() and RSA_verify() in crypto/rsa/rsa_sign.c, these perform the DigestInfo packing and unpacking, where necessary, before passing the data to RSA_private_encrypt() and RSA_public_decrypt(). If a PKCS#11 ENGINE maps those to C_Encrypt() and C_Decrypt() instead of C_Sign() and C_Verify() then it has a bug. See 12.1.3 in the PKCS#11 spec for the equivalent mechanism when RSA_PKCS1_PADDING is used. The "normal" RSA encrypt and decrypt operations are done using the different RSA_public_encrypt() and RSA_private_decrypt() functions. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [EMAIL PROTECTED]
