On Wed, Apr 27, 2022 at 11:46 AM Philip Prindeville <philipp_subx@xxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx> 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
