[openssl-users] engine interface for genrsa

[Scott Wisniewski]

FYI:

If you provide an genrsa implementation in your engine that doesn't include
the private parameters, even if it's marked with RSA_FLAG_EXT_PKEY, the
openssl executable will not handle it correctly.

That's because genrsa_main assumes that the object that comes back is an
rsa private key. So it will attempt to save a PEM encoded RSA private key
even though it doesn't have the private key fields and openssl won't be
able to open the saved file.

So, if you want to enable use of the openssl executable with genrsa being
supported by your engine, you will actually need to modify apps/genrsa.c So
that genrsa_main does:

if (RSA_test_flags(rsa, RSA_FLAG_EXT_PKEY) == RSA_FLAG_EXT_PKEY) {

    if (! PEM_write_bio_RSA_PUBKEY(out, rsa))

        goto end;

}

else {

    if (!PEM_write_bio_RSAPrivateKey(out, rsa, enc, NULL, 0,

                                     (pem_password_cb *)password_callback,

                                     &cb_data))

        goto end;

}

instead of:

if (!PEM_write_bio_RSAPrivateKey(out, rsa, enc, NULL, 0,

                                    (pem_password_cb *)password_callback,

                                    &cb_data))

       goto end;

And then it will save the key you generated in public key pem format. which
will allow openssl to read it.

One thing to note:

None of the open source engines I checked (neither the PCKS11 engine, the
NCipher engine, nor the CAPI engine) implement the genrsa hook. If you are
looking for wide compatibility you may wish to ask your clients to do key
generation using an external utility (as that's how almost everyone else
does it).

On Fri, Apr 13, 2018 at 5:28 PM, William Roberts <bill.c.roberts at gmail.com>
wrote:

> On Fri, Apr 13, 2018 at 2:55 PM, Richard Levitte <levitte at openssl.org>
> wrote:
> > In message <CAFftDdqWPXq1+Mo9_6J0EzhZ4uwg5QC=R5fx8N1j=QYchA8
> +YQ at mail.gmail.com> on Fri, 13 Apr 2018 09:17:28 -0700, William Roberts <
> bill.c.roberts at gmail.com> said:
> >
> > bill.c.roberts> I am currently working on writing an openssl engine
> > bill.c.roberts> to interface with a piece of hardware.
> > bill.c.roberts>
> > bill.c.roberts> I am trying to understand how to implement
> > bill.c.roberts> rsa key generation, where the private key
> > bill.c.roberts> bytes would not be available.
> > bill.c.roberts>
> > bill.c.roberts> I am currently invoking the
> > bill.c.roberts> command:
> > bill.c.roberts>
> > bill.c.roberts> openssl genrsa -engine foo
> > bill.c.roberts>
> > bill.c.roberts> Which is calling my callback for RSA keygen, registered
> via ENGINE_set_RSA()
> > bill.c.roberts> and I set the flags: RSA_FLAG_EXT_PKEY.
> > bill.c.roberts>
> > bill.c.roberts> However, genrsa app seems to want rsa->e set here:
> > bill.c.roberts> https://github.com/openssl/openssl/blob/OpenSSL_1_0_2g/
> apps/genrsa.c#L291
> > bill.c.roberts>
> > bill.c.roberts> I can't find documentation on how to handle the keygen
> interface
> > bill.c.roberts> for RSA.
> > bill.c.roberts>
> > bill.c.roberts> Can someone point me in the right direction?
> >
> > e and n are public components of any RSA key pair (and RSA structure
> > in OpenSSL).  You *must* make them available.  The rest of the numbers
> > are private and do not need to be part of the RSA structure that
> > OpenSSL handles.
>
> Thanks. I went and read the RSA page on Wikipedia, and sure enough it
> has what common meanings of what all the single letter variables
> are in the RSA struct.
> https://en.wikipedia.org/wiki/RSA_(cryptosystem)
>
> >
> > Cheers,
> > Richard
> >
> > --
> > Richard Levitte         levitte at openssl.org
> > OpenSSL Project         http://www.openssl.org/~levitte/
> > --
> > openssl-users mailing list
> > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180419/b04c7c14/attachment.html>