Re: [openssl-dev] rsautl.c incorrectly processes "-oaep" flag
In message <1f398e96-a7db-4389-94bd-7f1c1af99...@ll.mit.edu> on Thu, 13 Apr 2017 22:16:49 +, "Blumenthal, Uri - 0553 - MITLL" said: uri> Does it mean that rsautl is pretty much deprecated, and pkeyutl superseded it? Or is it still worth bringing it “up to snuff”? In my very personal opinion, I'd say yes, pkeyutl supersedes rsautl. I don't know if there's any operation of rsautl's that isn't implemented in pkeyutl (yet?), though. But yeah, if you ask me, I'd rather see rsautl abandoned for the benefit of pkeyutl. Team opinion may differ... the question of deprecating commands hasn't actually come up yet. Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] rsautl.c incorrectly processes "-oaep" flag
On 4/13/17, 5:58 PM, "openssl-dev on behalf of Richard Levitte" 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
Re: [openssl-dev] rsautl.c incorrectly processes "-oaep" flag
In message <006b8116-8aad-18f6-8759-2696ebf38...@gmail.com> on Thu, 13 Apr 2017 16:41:35 -0500, Douglas E Engert said: deengert> deengert> deengert> On 4/13/2017 4:18 PM, Richard Levitte wrote: deengert> > In message <1ef605ec-d2dd-4d15-a27f-1e1ce7956...@ll.mit.edu> on Thu, deengert> > 13 Apr 2017 20:55:36 +, "Blumenthal, Uri - 0553 - MITLL" deengert> > said: deengert> > deengert> > uri> I am trying to use “openssl rsautl” to wrap/unwrap symmetric keys deengert> > in a script. Decryption (and encryption too, but that isn’t relevant) deengert> > is done using a token accessible via pkcs11 engine (libp11). deengert> > uri> deengert> > uri> The problem is: “rsautl” appears to assume that if “-oaep” flag deengert> > is given, then the engine is going to handle OAEP padding. This is the deengert> > screen log: deengert> > uri> deengert> > uri> $ openssl rsautl -engine pkcs11 -keyform ENGINE -encrypt -pubin deengert> > -inkey deengert> > "pkcs11:manufacturer=piv_II;object=KEY%20MAN%20pubkey;type=public" deengert> > -oaep -in t256.dat -out t256.dat.enc deengert> > uri> engine "pkcs11" set. deengert> > uri> $ ls -l t256.dat.enc deengert> > uri> -rw-r--r-- 1 mouse 256 Apr 10 17:34 t256.dat.enc 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 deengert> > uri> engine "pkcs11" set. deengert> > uri> PKCS#11 token PIN: deengert> > uri> PKCS#11: Unsupported padding type deengert> > uri> RSA operation error deengert> > uri> $ deengert> > uri> deengert> > uri> libp11 does not know how to deal with OAEP padding, so it returns deengert> > an error. deengert> > uri> deengert> > uri> Desired solution: in case of “-oaep” pass “RSA_NO_PADDING” to the deengert> > engine (aka to libp11), and strip the padding using OpenSSL deengert> > mechanisms. deengert> > uri> deengert> > uri> I’d like to see that fixed in both 1.1 and 1.0.2 branches. deengert> > deengert> > Wouldn't it be much easier to add the following lines: deengert> > deengert> > case RSA_PKCS1_OAEP_PADDING: deengert> > mechanism->mechanism = CKM_RSA_PKCS_OAEP; deengert> > break; deengert> > deengert> > right about here? deengert> > https://github.com/OpenSC/libp11/blob/master/src/p11_rsa.c#L72 deengert> > deengert> > What you propose for OpenSSL is quite a lot harder to implement well, deengert> > and one might also wonder why the OAEP padding should have that deengert> > special treatment and no other? deengert> > deengert> deengert> Because there are parameters to the OAEP, and rsautl.c does not set deengert> it. deengert> deengert> when not using an engine, rsa/rsa_pmeth.c in pkey_rsa_decrypt does deengert> something similar: deengert> deengert> 300 if (rctx->pad_mode == RSA_PKCS1_OAEP_PADDING) { deengert> deengert> 304 ret = RSA_private_decrypt(inlen, in, rctx->tbuf, deengert> 305 ctx->pkey->pkey.rsa, RSA_NO_PADDING); deengert> deengert> 312 ret = RSA_padding_check_PKCS1_OAEP_mgf1(out, ret, rctx->tbuf + i, deengert> 313 ret - i, ret, deengert> 314 rctx->oaep_label, deengert> 315 rctx->oaep_labellen, deengert> 316 rctx->md, rctx->mgf1md); Good point. But then, 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. Incidently, for decryption, it will end up calling exactly the code you're citing, and with -pkeyopt, you can specify the padding mode and its necessary data. Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] rsautl.c incorrectly processes "-oaep" flag
On 4/13/2017 4:18 PM, Richard Levitte wrote: In message <1ef605ec-d2dd-4d15-a27f-1e1ce7956...@ll.mit.edu> on Thu, 13 Apr 2017 20:55:36 +, "Blumenthal, Uri - 0553 - MITLL" said: uri> I am trying to use “openssl rsautl” to wrap/unwrap symmetric keys in a script. Decryption (and encryption too, but that isn’t relevant) is done using a token accessible via pkcs11 engine (libp11). uri> uri> The problem is: “rsautl” appears to assume that if “-oaep” flag is given, then the engine is going to handle OAEP padding. This is the screen log: uri> uri> $ openssl rsautl -engine pkcs11 -keyform ENGINE -encrypt -pubin -inkey "pkcs11:manufacturer=piv_II;object=KEY%20MAN%20pubkey;type=public" -oaep -in t256.dat -out t256.dat.enc uri> engine "pkcs11" set. uri> $ ls -l t256.dat.enc uri> -rw-r--r-- 1 mouse 256 Apr 10 17:34 t256.dat.enc uri> $ openssl rsautl -engine pkcs11 -keyform ENGINE -decrypt -inkey "pkcs11:manufacturer=piv_II;object=KEY%20MAN%20key;type=private" -oaep -in t256.dat.enc -out t256.dat.dec uri> engine "pkcs11" set. uri> PKCS#11 token PIN: uri> PKCS#11: Unsupported padding type uri> RSA operation error uri> $ uri> uri> libp11 does not know how to deal with OAEP padding, so it returns an error. uri> uri> Desired solution: in case of “-oaep” pass “RSA_NO_PADDING” to the engine (aka to libp11), and strip the padding using OpenSSL mechanisms. uri> uri> I’d like to see that fixed in both 1.1 and 1.0.2 branches. Wouldn't it be much easier to add the following lines: case RSA_PKCS1_OAEP_PADDING: mechanism->mechanism = CKM_RSA_PKCS_OAEP; break; right about here? https://github.com/OpenSC/libp11/blob/master/src/p11_rsa.c#L72 What you propose for OpenSSL is quite a lot harder to implement well, and one might also wonder why the OAEP padding should have that special treatment and no other? Because there are parameters to the OAEP, and rsautl.c does not set it. when not using an engine, rsa/rsa_pmeth.c in pkey_rsa_decrypt does something similar: 300 if (rctx->pad_mode == RSA_PKCS1_OAEP_PADDING) { 304 ret = RSA_private_decrypt(inlen, in, rctx->tbuf, 305 ctx->pkey->pkey.rsa, RSA_NO_PADDING); 312 ret = RSA_padding_check_PKCS1_OAEP_mgf1(out, ret, rctx->tbuf + i, 313 ret - i, ret, 314 rctx->oaep_label, 315 rctx->oaep_labellen, 316 rctx->md, rctx->mgf1md); Cheers, Richard -- Douglas E. Engert -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] rsautl.c incorrectly processes "-oaep" flag
On 4/13/17, 5:18 PM, "Richard Levitte" wrote: uri> . . . . . uri> libp11 does not know how to deal with OAEP padding, so it returns an error. uri> uri> Desired solution: in case of “-oaep” pass “RSA_NO_PADDING” to the engine (aka to libp11), and strip the padding using OpenSSL mechanisms. uri> uri> I’d like to see that fixed in both 1.1 and 1.0.2 branches. Wouldn't it be much easier to add the following lines [to libp11/src/p11_rsa.c]: case RSA_PKCS1_OAEP_PADDING: mechanism->mechanism = CKM_RSA_PKCS_OAEP; break; I’m afraid not – because currently OpenSSL does have full support for OAEP, and OpenSC has none. This is what causes the problem: OpenSSL expects the engine (libp11 and OpenSC) to handle OAEP, which they cannot do. What you propose for OpenSSL is quite a lot harder to implement well, I agree that it’s harder to implement *well*, but it is a lot simpler and shorter to implement in rsautl.c (a few lines of code), as compared to adding the whole support for OAEP to OpenSC (which – I agree – would be great to have, but let’s be realistic: it’s not there now). and one might also wonder why the OAEP padding should have that special treatment and no other? I’d say the same treatment is applicable to any padding that is supported by OpenSSL but not by (the majority of) PKCS#11 devices (and OpenSC). What OpenSSL does programmatically with this is (IMHO) perfect. This code works correctly with the token that only does raw RSA (the original had a lot more of error checking stuff (): privkey = ENGINE_load_private_key(e, KeyManPrivKey, NULL, &cb_data); ctx = EVP_PKEY_CTX_new(privkey, NULL); EVP_PKEY_free(privkey); rv = EVP_PKEY_decrypt_init(ctx); if (rv <= 0) goto end; rv = EVP_PKEY_CTX_set_rsa_padding(ctx, PADDING); *olen = 0; rv = EVP_PKEY_decrypt(ctx, NULL, olen, in, inlen); *out = OPENSSL_malloc(*olen); rv = EVP_PKEY_decrypt(ctx, *out, olen, in, inlen); end: Perhaps rsautl.c could do the same? Instead of what it’s doing now (aka calling RSA_private_decrypt())? smime.p7s Description: S/MIME cryptographic signature -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] rsautl.c incorrectly processes "-oaep" flag
In message <1ef605ec-d2dd-4d15-a27f-1e1ce7956...@ll.mit.edu> on Thu, 13 Apr 2017 20:55:36 +, "Blumenthal, Uri - 0553 - MITLL" said: uri> I am trying to use “openssl rsautl” to wrap/unwrap symmetric keys in a script. Decryption (and encryption too, but that isn’t relevant) is done using a token accessible via pkcs11 engine (libp11). uri> uri> The problem is: “rsautl” appears to assume that if “-oaep” flag is given, then the engine is going to handle OAEP padding. This is the screen log: uri> uri> $ openssl rsautl -engine pkcs11 -keyform ENGINE -encrypt -pubin -inkey "pkcs11:manufacturer=piv_II;object=KEY%20MAN%20pubkey;type=public" -oaep -in t256.dat -out t256.dat.enc uri> engine "pkcs11" set. uri> $ ls -l t256.dat.enc uri> -rw-r--r-- 1 mouse 256 Apr 10 17:34 t256.dat.enc uri> $ openssl rsautl -engine pkcs11 -keyform ENGINE -decrypt -inkey "pkcs11:manufacturer=piv_II;object=KEY%20MAN%20key;type=private" -oaep -in t256.dat.enc -out t256.dat.dec uri> engine "pkcs11" set. uri> PKCS#11 token PIN: uri> PKCS#11: Unsupported padding type uri> RSA operation error uri> $ uri> uri> libp11 does not know how to deal with OAEP padding, so it returns an error. uri> uri> Desired solution: in case of “-oaep” pass “RSA_NO_PADDING” to the engine (aka to libp11), and strip the padding using OpenSSL mechanisms. uri> uri> I’d like to see that fixed in both 1.1 and 1.0.2 branches. Wouldn't it be much easier to add the following lines: case RSA_PKCS1_OAEP_PADDING: mechanism->mechanism = CKM_RSA_PKCS_OAEP; break; right about here? https://github.com/OpenSC/libp11/blob/master/src/p11_rsa.c#L72 What you propose for OpenSSL is quite a lot harder to implement well, and one might also wonder why the OAEP padding should have that special treatment and no other? Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] rsautl.c incorrectly processes "-oaep" flag
I am trying to use “openssl rsautl” to wrap/unwrap symmetric keys in a script. Decryption (and encryption too, but that isn’t relevant) is done using a token accessible via pkcs11 engine (libp11). The problem is: “rsautl” appears to assume that if “-oaep” flag is given, then the engine is going to handle OAEP padding. This is the screen log: $ openssl rsautl -engine pkcs11 -keyform ENGINE -encrypt -pubin -inkey "pkcs11:manufacturer=piv_II;object=KEY%20MAN%20pubkey;type=public" -oaep -in t256.dat -out t256.dat.enc engine "pkcs11" set. $ ls -l t256.dat.enc -rw-r--r-- 1 mouse 256 Apr 10 17:34 t256.dat.enc $ openssl rsautl -engine pkcs11 -keyform ENGINE -decrypt -inkey "pkcs11:manufacturer=piv_II;object=KEY%20MAN%20key;type=private" -oaep -in t256.dat.enc -out t256.dat.dec engine "pkcs11" set. PKCS#11 token PIN: PKCS#11: Unsupported padding type RSA operation error $ libp11 does not know how to deal with OAEP padding, so it returns an error. Desired solution: in case of “-oaep” pass “RSA_NO_PADDING” to the engine (aka to libp11), and strip the padding using OpenSSL mechanisms. I’d like to see that fixed in both 1.1 and 1.0.2 branches. — Regards, Uri smime.p7s Description: S/MIME cryptographic signature -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev