Re: [openssl-dev] rsautl.c incorrectly processes "-oaep" flag

[Richard Levitte]

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

[Blumenthal, Uri - 0553 - MITLL]

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

[Richard Levitte]

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

[Blumenthal, Uri - 0553 - MITLL]

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, _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

[Richard Levitte]

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