rsautl.c incorrectly processes "-oaep" flag

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

rsautl.c incorrectly processes "-oaep" flag

Blumenthal, Uri - 0553 - MITLL
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


--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: rsautl.c incorrectly processes "-oaep" flag

Richard Levitte - VMS Whacker-2
In message <[hidden email]> on Thu, 13 Apr 2017 20:55:36 +0000, "Blumenthal, Uri - 0553 - MITLL" <[hidden email]> 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 muuuuuch 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         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: rsautl.c incorrectly processes "-oaep" flag

Blumenthal, Uri - 0553 - MITLL
On 4/13/17, 5:18 PM, "Richard Levitte" <[hidden email]> 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 muuuuuch 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())?

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: rsautl.c incorrectly processes "-oaep" flag

Douglas E Engert
In reply to this post by Richard Levitte - VMS Whacker-2


On 4/13/2017 4:18 PM, Richard Levitte wrote:

> In message <[hidden email]> on Thu, 13 Apr 2017 20:55:36 +0000, "Blumenthal, Uri - 0553 - MITLL" <[hidden email]> 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 muuuuuch 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  <[hidden email]>

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: rsautl.c incorrectly processes "-oaep" flag

Richard Levitte - VMS Whacker-2
In message <[hidden email]> on Thu, 13 Apr 2017 16:41:35 -0500, Douglas E Engert <[hidden email]> said:

deengert>
deengert>
deengert> On 4/13/2017 4:18 PM, Richard Levitte wrote:
deengert> > In message <[hidden email]> on Thu,
deengert> > 13 Apr 2017 20:55:36 +0000, "Blumenthal, Uri - 0553 - MITLL"
deengert> > <[hidden email]> 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 muuuuuch 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         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: rsautl.c incorrectly processes "-oaep" flag

Blumenthal, Uri - 0553 - MITLL
On 4/13/17, 5:58 PM, "openssl-dev on behalf of Richard Levitte" <[hidden email] on behalf of [hidden email]> 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!

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: rsautl.c incorrectly processes "-oaep" flag

Richard Levitte - VMS Whacker-2
In message <[hidden email]> on Thu, 13 Apr 2017 22:16:49 +0000, "Blumenthal, Uri - 0553 - MITLL" <[hidden email]> 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         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev