Re: RSA test vectors, etc.
On Wed, Apr 27, 2022 at 11:46 AM Philip Prindeville 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 > > 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
Re: RSA test vectors, etc.
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? > On Apr 27, 2022, at 10:43 AM, Philip Prindeville > 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 > > >
RSA test vectors, etc.
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
Re: test vectors for CTR DRBG
Hi Julien, thanks for the hint, I'm going to try it! Sorry for the long delay in response, I was quite sometime off-line and now I'm going through all the e-mails... Thanks! Jirka On Wed, Oct 19, 2011 at 7:06 PM, nimou rild...@gmail.com wrote: Jiri Hladky-2 wrote: Hello, I'm looking for the test vectors for CTR DRBG random number generator. I got test vectors from http://csrc.nist.gov/groups/STM/cavp/documents/drbg/drbgtestvectors.zip which contains CTR_DRBG.rsp file. However, I'm looking for the following scenario which is not covered right now: [AES-128 no df] [PredictionResistance = False] [EntropyInputLen = 256] [NonceLen = 0] [PersonalizationStringLen = 0] [AdditionalInputLen = 0] Can anybody please provide such testing vectors? Thanks a lot! Jiri Actually, you can use vectors from the following scenario : [AES-128 no df] [PredictionResistance = False] [EntropyInputLen = 256] [NonceLen = 64] [PersonalizationStringLen = 0] [AdditionalInputLen = 0] Here, it says that there is a nonce of length 64, but it is not used as there is no nonce used when DF is not used... So even though this scenario provides a nonce value, it is never used. Trust me I tested it myself ! (you can also verify in SP800-90 that no nonce is used when no df..) Cheers ! Julien -- View this message in context: http://old.nabble.com/test-vectors-for-CTR-DRBG-tp32446997p32683724.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: test vectors for CTR DRBG
Jiri Hladky-2 wrote: Hello, I'm looking for the test vectors for CTR DRBG random number generator. I got test vectors from http://csrc.nist.gov/groups/STM/cavp/documents/drbg/drbgtestvectors.zip which contains CTR_DRBG.rsp file. However, I'm looking for the following scenario which is not covered right now: [AES-128 no df] [PredictionResistance = False] [EntropyInputLen = 256] [NonceLen = 0] [PersonalizationStringLen = 0] [AdditionalInputLen = 0] Can anybody please provide such testing vectors? Thanks a lot! Jiri Actually, you can use vectors from the following scenario : [AES-128 no df] [PredictionResistance = False] [EntropyInputLen = 256] [NonceLen = 64] [PersonalizationStringLen = 0] [AdditionalInputLen = 0] Here, it says that there is a nonce of length 64, but it is not used as there is no nonce used when DF is not used... So even though this scenario provides a nonce value, it is never used. Trust me I tested it myself ! (you can also verify in SP800-90 that no nonce is used when no df..) Cheers ! Julien -- View this message in context: http://old.nabble.com/test-vectors-for-CTR-DRBG-tp32446997p32683724.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
test vectors for CTR DRBG
Hello, I'm looking for the test vectors for CTR DRBG random number generator. I got test vectors from http://csrc.nist.gov/groups/STM/cavp/documents/drbg/drbgtestvectors.zip which contains CTR_DRBG.rsp file. However, I'm looking for the following scenario which is not covered right now: [AES-128 no df] [PredictionResistance = False] [EntropyInputLen = 256] [NonceLen = 0] [PersonalizationStringLen = 0] [AdditionalInputLen = 0] Can anybody please provide such testing vectors? Thanks a lot! Jiri
Test vectors for OpenSSL ECC imp
I have been asked to verify the ECC as I have used from Openssl using some well know test vectors. Does anyone know where I can get some ECC test vectors that I could use? I've looked and really have not come up with anything. Looking for ones doing ECDH and MQV. I'm assuming that these test vectors would supply the private/pulic keys to use and what the group key would be after the calculations. Thanks, Frank __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
test vectors
Hello, Could someone tell me where I could find some test vectors for a DES in CBC mode? Thank you.
Re: test vectors
On Fri, 4 May 2001, Frédéric Viollet wrote: Hello, Could someone tell me where I could find some test vectors for a DES in CBC mode? You could have looked for DES test vectors in a good web search engine, such as Google. The second result gives you the URL: http://csrc/nist.gov/cryptval/#46-2 The last one on the first page is also interesting: http://grifter.hektik.org/Crypto/DESCRYPT.TXT It was posted 11 years ago. -- Erwann ABALEA [EMAIL PROTECTED] RSA PGP Key ID: 0x2D0EABD5 - Time never started at all. Chaos never died. The Empire was never founded. We are not now never have been slaves to the past or hostages to the future. -Hakim Bey, /T.A.Z./ __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: test vectors
- Original Message - From: Erwann ABALEA [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, May 04, 2001 5:10 PM Subject: Re: test vectors Could someone tell me where I could find some test vectors for a DES in CBC mode? The last one on the first page is also interesting: http://grifter.hektik.org/Crypto/DESCRYPT.TXT It was posted 11 years ago. They don't talk about any initial vector. Does this mean that the IV is set to 00h ? Thanks [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
