RSA test vectors, etc.

[William Roberts]

On Wed, Apr 27, 2022 at 11:46 AM Philip Prindeville
<philipp_subx at redfish-solutions.com> wrote:
>
> Oh, forgot one other issue:
>
> I also need to pick apart the RSA keys into their constituent exponents, modulus, etc. as BN's that I can then compare to bit-strings.
>
> With the old RSA_* routines this was trivial.  How does one do this with the EVP_PKEY_* interface so that it works with 1.1.x and 3.0?
>

Unfortunately to support 1.1 and 3.0 you'll need to ifdef them based on version
For 3.0+ you use:
  - https://www.openssl.org/docs/man3.0/man3/EVP_PKEY_todata.html

For 1.1 you use:
  - https://www.openssl.org/docs/man1.1.1/man3/RSA_get0_key.html

There are equivalents for EC and other key types. You can get an RSA *
from en EVP key using:
  - EVP_PKEY_get0_RSA

There are examples of going from pieces of an RSA/EC key to an EVP
pkey using fromdata, you'll have to
,essentially, do the inverse of this code (see functions like
get_RSA_evp_pubkey and get_EC_evp_pubkey):
  - https://github.com/tpm2-software/tpm2-pkcs11/blob/master/src/lib/ssl_util.c
You will use that todata routine here.

There's also an example of using EVP_PKEY_get0_RSA in that file. The
downside is, on 3.0, any usages
for the low level keys (Raw RSA and EC pointers) is deprecated, along
with some of the padding routines
we use.  PSS is essentially broken on many TPM's so we apply padding
and use raw rsa on broken TPMS.

It's not clear to me how I will ever be able to migrate away from
those APIs unless I break backwards compat
support. Although it's not clear to me why I did it for PKCS1.5 as
well. So I think ill just lose PSS support offhand.

>
>
> > On Apr 27, 2022, at 10:43 AM, Philip Prindeville <philipp_subx at redfish-solutions.com> wrote:
> >
> > Hi,
> >
> > I've been trying to rewrite the res_crypto.so support in Asterisk to use Openssl-1.1.x and the EVP_PKEY interface, rather than the AES_* and RSA_* stuff.
> >
> > The AES stuff uses ECB and 128 bit keys... That's a larger issue of redesigning the entire API and the client apps to support GCM and stronger keys.  Yes, I'm aware... but I'm focusing on baby steps for now.
> >
> > To make sure I'm not breaking anything, I'm trying to add test coverage (including test vectors) for both.
> >
> > AES-ECB is easy, because it's 100% reproducible.
> >
> > RSA is turning out to be trickier, because of OAEP and PKCSv1.5 randomness.
> >
> > As I see it, I have two choices:
> >
> > (1) test RSA as an end-to-end pipeline, encrypting, then decrypting, and verifying that there's agreement on the plaintext message at both ends--this gives no visibility into the intermediate crypt text results... for all I know, the text is going through unchanged;
> >
> > (2) mess with the randomness/seeding of OAEP and PSS to force it to always generate the same results--this is ideal from a reproducibility point of view, but cryptographically a nightmare;
> >
> > As a test, I tried to generate my crypt text from the CLI to paste into my C code as:
> >
> > % echo -n "Mary had a littl" | openssl rsautl -inkey tests/keys/rsa_key1.pub -pubin -encrypt -oaep -rand /dev/zero | xxd --include -c 8
> >
> > But repeating this command gets me different output every time, so faking out the random-number generator with something that always generates the same value doesn't seem to be sufficient.
> >
> > How do other people deal with this?
> >
> > The other tests I need to do are RSA signing and verifying.  Verifying is easy because I can use a canned signature (and key, of course).  Signing is more problematic, because of the non-determinism/reproducibility.
> >
> > Same question: how do other people deal with this?
> >
> > Thanks,
> >
> > -Philip

We have the same issues with TPM integration testing, we just do a
sign with the HSM and a verify with OpenSSL and vice versa to confirm.
Unfortunately, it requires that full test versus checking
static data. I don't know what you mean by "end-to-end pipeline
testing", but you could use cmocka to mock out parts of the code so
you can just verify the buffer without doing a full end-to-end flow.

Hope some of my ramblings are bit helpful,
Bill