Re: EC_POINT_get_affine_coordinates replacement in 3.0
On Tue, May 3, 2022 at 3:18 PM Chris Bare wrote: > > > On Tue, May 3, 2022 at 3:10 PM William Roberts > wrote: >> >> On Tue, May 3, 2022 at 1:14 PM Chris Bare wrote: >> > >> > I'm converting some openssl 1.0 code to 3.0 and I don't know how to get >> > the coordinates >> > in a 3.0 way. >> > The old code is: >> > BN_CTX *ctx = BN_CTX_new (); >> > BIGNUM *X = NULL, *Y = NULL; >> > const EC_POINT *pubkey; >> > const EC_GROUP *group; >> > BN_CTX_start (ctx); >> > X = BN_CTX_get (ctx); >> > Y = BN_CTX_get (ctx); >> > pubkey = EC_KEY_get0_public_key ((EC_KEY *) EVP_PKEY_get0 (pkey)); >> > group = EC_KEY_get0_group ((EC_KEY *) EVP_PKEY_get0 (cvr->sm_pkey)); >> > EC_POINT_get_affine_coordinates_GFp (group, pubkey, X, Y, ctx) >> > >> > What would be the 3.0 way to get X and Y without using deprecated >> > functions? >> >> For EC_POINT_get_affine_coordinates_GFp it goes to >> EC_POINT_get_affine_coordinates, see: >> - >> https://www.openssl.org/docs/man3.0/man3/EC_POINT_get_affine_coordinates.html >> >> Offhand I don't see any other deprecated functions, was that the only one? >> >> Thanks, >> Bill > > > all the EC_KEY_get0_ functions are deprecated. Is there a new way to access > the internals of > the opaque structures, or am I stuck with the deprecated ones for this? I think you want the from and to data routines that provide the components from an EVP PKEY or produce an EVP_PKEY from the components: - https://www.openssl.org/docs/man3.0/man3/EVP_PKEY_todata.html - https://www.openssl.org/docs/man3.0/man3/EVP_PKEY_fromdata.html
Re: EC_POINT_get_affine_coordinates replacement in 3.0
On Tue, May 3, 2022 at 1:14 PM Chris Bare wrote: > > I'm converting some openssl 1.0 code to 3.0 and I don't know how to get the > coordinates > in a 3.0 way. > The old code is: > BN_CTX *ctx = BN_CTX_new (); > BIGNUM *X = NULL, *Y = NULL; > const EC_POINT *pubkey; > const EC_GROUP *group; > BN_CTX_start (ctx); > X = BN_CTX_get (ctx); > Y = BN_CTX_get (ctx); > pubkey = EC_KEY_get0_public_key ((EC_KEY *) EVP_PKEY_get0 (pkey)); > group = EC_KEY_get0_group ((EC_KEY *) EVP_PKEY_get0 (cvr->sm_pkey)); > EC_POINT_get_affine_coordinates_GFp (group, pubkey, X, Y, ctx) > > What would be the 3.0 way to get X and Y without using deprecated functions? For EC_POINT_get_affine_coordinates_GFp it goes to EC_POINT_get_affine_coordinates, see: - https://www.openssl.org/docs/man3.0/man3/EC_POINT_get_affine_coordinates.html Offhand I don't see any other deprecated functions, was that the only one? Thanks, Bill
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: Cross-project request... looking for input on a rewrite of Asterisk's res_crypto.c module
On Tue, Mar 29, 2022 at 3:40 PM Philip Prindeville wrote: > > Hi, > > I'm trying to develop a newer replacement module for Asterisk's res_crypto > that is (for now) 1.1.x compatible but can be easily updated to 3.0 (and > maybe even easily add provider support for TPM escrowed secrets, etc). Just an FYI to see if you're aware of the tpm2 provider: https://github.com/tpm2-software/tpm2-openssl > > I'm collecting requirements before I get started. > > https://wiki.asterisk.org/wiki/pages/viewpage.action?pageId=49153311 > > The modules in Asterisk that use res_crypto are: > > func/func_aes.c > chan/chan_iax2.c > pbx/pbx_dundi.c > pbx/dundi-parser.c > > as well as any independent third-party modules (but I'm not aware of what > they might be). > > The code is rife with assumptions, such as only AES128 and RSA1024 are to be > used, that only AES-EBC chaining is used, and that it's safe to block-cipher > with RSA. Signing digests, RSA padding and AES ciphers are hard-coded. As > are buffer sizes. (So you see why a rewrite is needed...) > > This is the tip of the proverbial iceberg. > > Anyway, more eyes on the problem are always a good thing. Godspeed > > Thanks, > > -Philip > >
Re: EVP_PKEY_fromdata_init returns unsupported.
On Mon, Feb 28, 2022 at 2:59 AM Matt Caswell wrote:
>
>
>
> On 25/02/2022 22:07, William Roberts wrote:
> > Hello,
> >
> > In openssl 3.0.1 the following code hits the ctx->keymgt is null check
> > and thus returns -2
> > in pmeth_gn.c:
> > static int fromdata_init(EVP_PKEY_CTX *ctx, int operation)
> > {
> > if (ctx == NULL || ctx->keytype == NULL)
> > goto not_supported;
> >
> > evp_pkey_ctx_free_old_ops(ctx);
> > if (ctx->keymgmt == NULL)
> > goto not_supported;
> >
> > The callpath comes in from EVP_PKEY_fromdata_init:
> >
> > libctx = OSSL_LIB_CTX_new()
> > genctx = EVP_PKEY_CTX_new_from_name(libctx, "RSA", NULL);
>
>
> My guess is EVP_PKEY_CTX_new_from_name() is finding a default engine
> implementation for RSA. You might like to step through
> EVP_PKEY_CTX_new_from_name in the debugger (actually int_ctx_new in
> crypto/evp/pmeth_lib.c) and see if the "e" variable ever gets associated
> with an engine.
>
Yes variable e does indeed get associated with the "pkcs11 engine"
> If an engine is being found then the EVP_PKEY_CTX will use that engine
> implementation for all subsequent RSA operations. EVP_PKEY_fromdata will
> only work with provider based implementations (we should make that
> explicit in the documentation) - hence it will fail.
>
Is there any way I can build an RSA or EC public key and encrypt with that and
not go to a provider?
> Matt
>
>
>
> > int rc = EVP_PKEY_fromdata_init(genctx);
> >
> > I have no idea why it returns unsupported... any ideas?
> > I also tried replacing EVP_PKEY_CTX_new_from_name with
> > EVP_PKEY_CTX_new_id, same error.
> >
> > Thanks,
> > Bill
> >
Re: EVP_PKEY_fromdata_init returns unsupported.
On Fri, Feb 25, 2022 at 4:19 PM William Roberts
wrote:
>
> Hi Kory,
>
> its the line:
> genctx = EVP_PKEY_CTX_new_from_name(libctx, "RSA", NULL);
>
> There's a snippet in the first email or is there something else you're
> asking me and I'm not groking it?
>
> Thanks,
> Bill
>
> On Fri, Feb 25, 2022 at 4:16 PM Kory Hamzeh wrote:
> >
> > Hi Bill,
> >
> > How are you creating the EVP_PKEY_CTX?
> >
> > Kory
> >
> >
> > > On Feb 25, 2022, at 2:07 PM, William Roberts
> > > wrote:
> > >
> > > Hello,
> > >
> > > In openssl 3.0.1 the following code hits the ctx->keymgt is null check
> > > and thus returns -2
> > > in pmeth_gn.c:
> > > static int fromdata_init(EVP_PKEY_CTX *ctx, int operation)
> > > {
> > >if (ctx == NULL || ctx->keytype == NULL)
> > >goto not_supported;
> > >
> > >evp_pkey_ctx_free_old_ops(ctx);
> > >if (ctx->keymgmt == NULL)
> > >goto not_supported;
> > >
> > > The callpath comes in from EVP_PKEY_fromdata_init:
> > >
> > > libctx = OSSL_LIB_CTX_new()
> > > genctx = EVP_PKEY_CTX_new_from_name(libctx, "RSA", NULL);
> > > int rc = EVP_PKEY_fromdata_init(genctx);
> > >
> > > I have no idea why it returns unsupported... any ideas?
> > > I also tried replacing EVP_PKEY_CTX_new_from_name with
> > > EVP_PKEY_CTX_new_id, same error.
> > >
I wonder if this is an issue with:
1. My underlying application linking to OpenSSL and not using any
custom provider or engine
2. That application is being called through the pkcs11-engine from libp11.
The flow looks something like this:
OPENSSL_CONF=ossl.cnf openssl req --> pkcs11 engine --> tpm2-pkcs11
--> tpm2-tss (linked to openssl libcrypto).
$ cat ossl.cnf
openssl_conf = openssl_init
[openssl_init]
engines = engine_section
[engine_section]
pkcs11 = pkcs11_section
[pkcs11_section]
engine_id = pkcs11
MODULE_PATH = ${ENV::TPM2_PKCS11_MODULE}
PIN=myuserpin
init = 0
[ req ]
distinguished_name = req_dn
string_mask = utf8only
utf8 = yes
[ req_dn ]
commonName = Mr Test Harness
--- EOF
This worked pre-3.0, any ideas of something I can tweak?
Bill
Re: EVP_PKEY_fromdata_init returns unsupported.
Hi Kory,
its the line:
genctx = EVP_PKEY_CTX_new_from_name(libctx, "RSA", NULL);
There's a snippet in the first email or is there something else you're
asking me and I'm not groking it?
Thanks,
Bill
On Fri, Feb 25, 2022 at 4:16 PM Kory Hamzeh wrote:
>
> Hi Bill,
>
> How are you creating the EVP_PKEY_CTX?
>
> Kory
>
>
> > On Feb 25, 2022, at 2:07 PM, William Roberts
> > wrote:
> >
> > Hello,
> >
> > In openssl 3.0.1 the following code hits the ctx->keymgt is null check
> > and thus returns -2
> > in pmeth_gn.c:
> > static int fromdata_init(EVP_PKEY_CTX *ctx, int operation)
> > {
> >if (ctx == NULL || ctx->keytype == NULL)
> >goto not_supported;
> >
> >evp_pkey_ctx_free_old_ops(ctx);
> >if (ctx->keymgmt == NULL)
> >goto not_supported;
> >
> > The callpath comes in from EVP_PKEY_fromdata_init:
> >
> > libctx = OSSL_LIB_CTX_new()
> > genctx = EVP_PKEY_CTX_new_from_name(libctx, "RSA", NULL);
> > int rc = EVP_PKEY_fromdata_init(genctx);
> >
> > I have no idea why it returns unsupported... any ideas?
> > I also tried replacing EVP_PKEY_CTX_new_from_name with
> > EVP_PKEY_CTX_new_id, same error.
> >
> > Thanks,
> > Bill
>
EVP_PKEY_fromdata_init returns unsupported.
Hello,
In openssl 3.0.1 the following code hits the ctx->keymgt is null check
and thus returns -2
in pmeth_gn.c:
static int fromdata_init(EVP_PKEY_CTX *ctx, int operation)
{
if (ctx == NULL || ctx->keytype == NULL)
goto not_supported;
evp_pkey_ctx_free_old_ops(ctx);
if (ctx->keymgmt == NULL)
goto not_supported;
The callpath comes in from EVP_PKEY_fromdata_init:
libctx = OSSL_LIB_CTX_new()
genctx = EVP_PKEY_CTX_new_from_name(libctx, "RSA", NULL);
int rc = EVP_PKEY_fromdata_init(genctx);
I have no idea why it returns unsupported... any ideas?
I also tried replacing EVP_PKEY_CTX_new_from_name with
EVP_PKEY_CTX_new_id, same error.
Thanks,
Bill
Re: Congratulations! Missing 3.0.0 tag?
On Wed, Sep 8, 2021 at 5:15 PM Steffen Nurpmeso wrote: > > Hello. > > William Roberts wrote in > : > |It's there: > |https://github.com/openssl/openssl/releases/tag/openssl-3.0.0 > | > |I checked it out this morning. > > Oh! I have > > fetch = +refs/heads/master:refs/remotes/origin/master > fetch = > +refs/heads/OpenSSL_1_0_2-stable:refs/remotes/origin/OpenSSL_1_0_2-stable > fetch = > +refs/heads/OpenSSL_1_0_1-stable:refs/remotes/origin/OpenSSL_1_0_1-stable > fetch = > +refs/heads/OpenSSL_1_1_0-stable:refs/remotes/origin/OpenSSL_1_1_0-stable > fetch = > +refs/heads/OpenSSL_1_1_1-stable:refs/remotes/origin/OpenSSL_1_1_1-stable > > and only saw refs/tags/openssl-3.0.0-alpha* and -beta*! > I see now via ls-remote there is a new openssl-3.0 branch.. > > From git://git.openssl.org/openssl >* [new branch]openssl-3.0 -> origin/openssl-3.0 >* [new tag] openssl-3.0.0 -> openssl-3.0.0 > > Yes, there it is, thank you! > > P.S.: maybe at least release commits and tags could be signed? > And/or HTTPS access to the repository ... but then i get the gut > feeling that the answer to this will be "use github" or something. > You could grab the release tarballs which have signatures https://www.openssl.org/source/
Re: Congratulations! Missing 3.0.0 tag?
It's there: https://github.com/openssl/openssl/releases/tag/openssl-3.0.0 I checked it out this morning. On Wed, Sep 8, 2021, 16:32 Steffen Nurpmeso wrote: > Yeah? > :) > > --steffen > | > |Der Kragenbaer,The moon bear, > |der holt sich munter he cheerfully and one by one > |einen nach dem anderen runter wa.ks himself off > |(By Robert Gernhardt) >
What to replace low-level padding operations with in OSSL 3.0?
I have code that applies PCKS1.5 padding via RSA_padding_add_PKCS1_type_1 and strips it with RSA_padding_check_PKCS1_type_2 before sending it to the HSM for raw RSA operation to support a legacy PKCS11 interface. Is there any way to perform these tasks with OpenSSL 3.0? Thanks, Bill
Re: openssl 3.0.0 valgrind failure on OPENSSL_ia32_cpuid
On Fri, Aug 27, 2021 at 2:47 PM Ken Goldman wrote: > > I run valgrind on all my software to find memory leaks. This worked for > openssl 1.0.2 and 1.1.1, but fails with 3.0.0. Suggestions? > > vex amd64->IR: unhandled instruction bytes: 0xF3 0xF 0x1E 0xFA 0x49 0x89 0xD8 > 0x31 > vex amd64->IR: REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0 > vex amd64->IR: VEX=0 VEX.L=0 VEX.n=0x0 ESC=0F > vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=1 > ==29625== valgrind: Unrecognised instruction at address 0x56b2b10. > ==29625==at 0x56B2B10: OPENSSL_ia32_cpuid (x86_64cpuid.s:36) > ==29625==by 0x569FA37: OPENSSL_cpuid_setup (cpuid.c:147) > ==29625==by 0x55163C2: ??? (in /home/kgold/openssl30/libcrypto.so.3) > ==29625== Your program just tried to execute an instruction that Valgrind > ==29625== did not recognise. There are two possible reasons for this. > ==29625== 1. Your program has a bug and erroneously jumped to a non-code > ==29625==location. If you are running Memcheck and you just saw a > ==29625==warning about a bad jump, it's probably your program's fault. > ==29625== 2. The instruction is legitimate but Valgrind doesn't handle it, > ==29625==i.e. it's Valgrind's fault. If you think this is the case or > ==29625==you are not sure, please let us know and we'll try to fix it. > ==29625== Either way, Valgrind will now raise a SIGILL signal which will > ==29625== probably kill your program. > ==29625== > ==29625== Process terminating with default action of signal 4 (SIGILL) > ==29625== Illegal opcode at address 0x56B2B10 > ==29625==at 0x56B2B10: OPENSSL_ia32_cpuid (x86_64cpuid.s:36) > ==29625==by 0x569FA37: OPENSSL_cpuid_setup (cpuid.c:147) > ==29625==by 0x55163C2: ??? (in /home/kgold/openssl30/libcrypto.so.3) > I stopped using valgrind awhile ago, because I had too many issues with false positives, etc. I really noticed this when dealing with glib/dbus. At this time, I made the switch to ASAN and both gcc and clang support it and the diagnostics have been better than anything I got with valgrind; it's been many years and I never looked back. Just google your compiler and asan and you should get guides, but in general it's as easy as adding CFLAGS='-O0 -g -fsanitize=address -fno-omit-frame-pointer' Then just run the binary as normal. You may need to set up the symbolizer to resolve addresses to file/line names. IIRC its via the ASAN_SYMBOLIZER_PATH and that is discussed further in the ASAN docs. I would give that a try, that's what I am using for OpenSSL 3.0 integration and fuzzing in my CI's Bill
Re: HMAC verification with EVP Interface
On Thu, Aug 26, 2021 at 3:01 AM Tomas Mraz wrote: > > On Wed, 2021-08-25 at 13:20 -0500, William Roberts wrote: > > Hello, > > > > I am trying to verify an HMAC signature with the code below and the > > EVP_DigestVerifyInit() > > routine is failing with "error:0608F096:digital envelope > > routines:EVP_PKEY_verify_init:operation not supported for this > > keytype". Eventually it gets to EVP_PKEY_verify_init() and since the > > ctx->pmeth->verify pointer is null, it sets this error. It's unclear > > to me why this function pointer is NULL, can someone elaborate the > > right way to do this via EVP interfaces? > > As HMAC is not a true signature algorithm there is no support for > the EVP_DigestVerifyInit() operation with HMAC 'signatures'. You just > have to use EVP_DigestSign*() operation to create a new HMAC and > compare with the original value. > Ahh okay thanks. This was in the wiki I just scrolled too far and ended up under asymmetric. For anyone looking it was on the on the wiki here: - https://wiki.openssl.org/index.php/EVP_Signing_and_Verifying But considering that Verifying could do this, since it has both the message and hmac "signature", wouldn't it be nice to add this support since it's generated through the sign interface? In my mind a Sign operation always has a verify operation.
HMAC verification with EVP Interface
Hello,
I am trying to verify an HMAC signature with the code below and the
EVP_DigestVerifyInit()
routine is failing with "error:0608F096:digital envelope
routines:EVP_PKEY_verify_init:operation not supported for this
keytype". Eventually it gets to EVP_PKEY_verify_init() and since the
ctx->pmeth->verify pointer is null, it sets this error. It's unclear
to me why this function pointer is NULL, can someone elaborate the
right way to do this via EVP interfaces?
Openssl Version: OpenSSL 1.1.1f 31 Mar 2020
Thanks,
Bill
/* This is just a testing key */
unsigned char hmac_key[] = {
0x30, 0x33, 0x33, 0x36, 0x61, 0x61, 0x37, 0x39,
0x34, 0x35, 0x61, 0x33, 0x63, 0x61, 0x64, 0x65,
0x63, 0x33, 0x63, 0x62, 0x64, 0x63, 0x36, 0x65,
0x37, 0x39, 0x30, 0x34, 0x33, 0x62, 0x35, 0x62
};
EVP_PKEY *ekey = EVP_PKEY_new_mac_key(EVP_PKEY_HMAC, NULL, hmac_key,
sizeof(hmac_key));
assert_non_null(ekey);
EVP_MD_CTX *mdctx = EVP_MD_CTX_new();
assert_non_null(mdctx);
int rc = EVP_DigestVerifyInit(mdctx, NULL, EVP_sha256(), NULL, ekey);
unsigned long x = ERR_get_error();
printf("EVP_DigestSignInit failed, error 0x%lx: %s\n", x,
ERR_error_string(x, NULL));
assert_int_equal(rc, 1);
rc = EVP_DigestVerifyUpdate(mdctx, msg, msg_len);
assert_int_equal(rc, 1);
rc = EVP_DigestVerifyFinal(mdctx, sig, sig_len);
assert_int_equal(rc, 1);
EVP_MD_CTX_free(mdctx);
EVP_PKEY_free(ekey);
Re: RSA_set0_key() equivalent for 3.0.0
On Wed, Jul 14, 2021, 09:27 Ken Goldman wrote: > On 7/13/2021 5:14 PM, William Roberts wrote: > > Outside of the migration guide others have pointed out, I think the > functions you need are: > > > > https://www.openssl.org/docs/manmaster/man3/EVP_PKEY_set1_RSA.html < > https://www.openssl.org/docs/manmaster/man3/EVP_PKEY_set1_RSA.html> > > > > Use use EVP level now as pointed out in the guide. > > Perhaps I'm reading it incorrectly, but I think that API is > deprecated. > > 1 - When I read the SYNOPSIS, there are a few APIs, then a > "deprecated since OpenSSL 3.0" separator, and then more APIs. > > I thought that APIs below the separator are deprecated. > Is that wrong? > > 2 - In evp.h, there is this: > > OSSL_DEPRECATEDIN_3_0 > int EVP_PKEY_set1_RSA(EVP_PKEY *pkey, struct rsa_st *key); > > I interpreted that to mean it's deprecated. > > Is that wrong? > > 3 - When I try to use it, I get: > > warning: 'EVP_PKEY_set1_RSA' is deprecated (declared at > openssl/include/openssl/evp.h:1344) > > Seems deprecated. > Matt Caswell pointed out that you want EVP_PKEY_fromdata()
Re: RSA_set0_key() equivalent for 3.0.0
I'd be nice to have a more detailed porting guide, I'd been poking into this a little bit, but did you see Matt's response? (Pasted below) Those functions are deprecated. Better would be EVP_PKEY_fromdata(): https://www.openssl.org/docs/manmaster/man3/EVP_PKEY_fromdata.html On Wed, Jul 14, 2021, 09:15 Ken Goldman wrote: > On 7/13/2021 5:08 PM, Nicola Tuveri wrote: > > There is the migration guide: > https://github.com/openssl/openssl/tree/master/doc/man7/migration_guide.pod > < > https://github.com/openssl/openssl/tree/master/doc/man7/migration_guide.pod > > > > > > The migration guide is very general. It says that the low level APIs are > deprecated, > and should be replaced with EVP functions. > > Is there anything more specific - replace RSA_set0_key() with ... > >
Re: RSA_set0_key() equivalent for 3.0.0
Outside of the migration guide others have pointed out, I think the functions you need are: https://www.openssl.org/docs/manmaster/man3/EVP_PKEY_set1_RSA.html Use use EVP level now as pointed out in the guide. On Tue, Jul 13, 2021, 16:04 Ken Goldman wrote: > What is the 3.0.0 equivalent to RSA_set0_key() when I > want to create a key token from n and e. > > Meta question: Is there a porting guide for these > type of questions - something that says, "If you > used this before, use this now." > >
Re: How to Manually allocate BIGNUM ->d and set dmax, top values to create a Result Buffer in openssl 1.1.1 ?
On Tue, Dec 22, 2020 at 3:45 AM prudvi raj wrote:
>
> Hello all,
>
> We use a hardware accelerator to calculate BIGNUM rr = a^p mod m .(
> bn_mod_exp). I am trying to rewrite that logic for openssl 1.1.1. Code
> snippet of custom bn_mod_exp function:
> --
> if(rr->d)
> {
> OPENSSL_free(rr->d);
> }
> rr->d = ( BN_ULONG * )( malloc( m->top * sizeof(BN_ULONG) ) );
> rr->top = m->top;
> rr->dmax = m->top;
> rr->neg = 0;
>
> publicKeyData.operandALength = a->top * sizeof(BN_ULONG);
> publicKeyData.operandA = ( System::BYTE * )( a->d );
> publicKeyData.operandBLength = p->top * sizeof(BN_ULONG);
> publicKeyData.operandB = ( System::BYTE * )( p->d );
> publicKeyData.modulusLength = m->top * sizeof(BN_ULONG);
> publicKeyData.modulus = ( System::BYTE * )( m->d );
>
> publicKeyData.resultLength = m->top * sizeof(BN_ULONG);
> publicKeyData.result = ( System::BYTE * )( rr->d );
>
> calculate ( publicKeyData );< "rr->d" buffer.
> --
> I found a few 'get' functions (no set functions though) like -- bn_get_top
> , bn_get_dmax. These are in "bn_intern.c" , not in "bn_lib.c" (or BN API).
>OPENSSL_free(rr->d)
>rr->d = ( BN_ULONG * )( malloc( m->top * sizeof(BN_ULONG) ) );
> rr->top = m->top;
> rr->dmax = m->top;
> rr->neg = 0
>
> As forward declarations are no longer allowed in openssl 1.1.1 , how to
> replicate above operations in openssl 1.1.1 ?
> Are there any Set functions for set, dmax , d values (allocate memory for
> rr->d) . ?!
> Please help me on this!!
>
> Thanks,
> Prudvi.
>
IIUC, this is just a side effect of not being able to access the RSA
structure directly like in openssl 1.0.2 days.
The function RSA_set0_key() will allow you to set D, and there are
routines for other portions of the struct as well.
When the structure went opaque, getter and setters we're added for
your use, see:
- https://www.openssl.org/docs/man1.1.1/man3/RSA_set0_key.html
If you need to keep backwards compat with 1.0.2, you can define those
getter/setter functions when building with 1.0.2 in your source
code. However, it's strongly recommended to not be using 1.0.2.
Bill
Re: x509_store_ctx_st structure in openssl 1.1.1
On Mon, Jun 22, 2020 at 10:45 AM shiva kumar wrote: > > Hi, > I was using the structure > struct x509_store_ctx_st > provide by x509_vfy.h in openssl 1.0.2, but can you please help me on how to > use the same or alternative for the above structure on openssl 1.1.1 I think just use the accessor and getter methods provided by the same header: X509_STORE_ > > > Thanks and regards > Shivakumar
Re: OpenSSL vs SPKI
On Mon, Apr 6, 2020, 11:59 PM Jason Proctor wrote: > On Mon, Apr 6, 2020 at 9:44 PM William Roberts > wrote: > > > > > > There's setter functions now. See: > > https://www.openssl.org/docs/man1.1.0/man3/RSA_set0_key.html > > Thanks, yes it does look like that replaces direct access to "n" and > "e". It's a hack, but it might work for the moment. > > Ideally though I wouldn't be reliant on offsets into the binary SPKI > structure :-) > I don't think I would consider it a hack necessarily. I work on the TPM stack and have to convert TPM structures to RSA public key structures for ooenssl to utilize, and we use this routine along the way. I would imagine theirs a higher level public from private routine you can call. I would dissect what: openssl rsa -in mykey.pem -pubout > mykey.pub Is doing > > any help with SPKI welcome! > J >
Re: OpenSSL vs SPKI
On Mon, Apr 6, 2020, 9:16 PM Jason Proctor wrote: > Distinguished crypto community, > > I have the requirement to import RSA keypairs generated by the Amazon > Key Management System into my environment. These keypairs arrive in > the de facto standard of SPKI for the public component and PKCS8 for > the private component. > > I have no problem with the PKCS8 encoded private keys, they seem fine > when imported using d2i_PKCS8_PRIV_KEY_INFO_bio(). > > However, I'm having issues importing the SPKI encoded public keys. My > Java test program imports them fine. The Js Web Crypto API is happy > with them. Online ASN.1 parsers are fine with them. The OpenSSL > command line tool can dump their contents, no problem. However, the > d2i_NETSCAPE_SPKI() function errors out trying to deal with them. > > Back in the day I had a hack to import SPKI encoded public keys, as I > knew their structure. I would just set the modulus and exponent > directly using BN_bin2bn(). However these days it seems that the RSA > structure is opaque, and so I can't do that either. (I mean fair > enough, it's a hack.) > There's setter functions now. See: https://www.openssl.org/docs/man1.1.0/man3/RSA_set0_key.html So I have no idea about the spki function, but if you have the rsa private key can't you get the public key from it? I would just look at what API the rsa command line tool is using. I would imagine there is a high level API for this. > > Question -- is there a supported way of importing SPKI encoded public > keys into the OpenSSL world? > > thanks so much for any help with this, > Jason@Spatial > EAY/OpenSSL user since 1995 >
Re: [RFC] TLS salt length auto detection, switch from DIGEST to AUTO
On Thu, Feb 27, 2020 at 1:01 PM Andersen, John S
wrote:
>
> Hi All,
>
> The TPM 2.0 PKCS11 project has been attempting to get the TPM working with
> EAP-TLS WiFi.
>
> We've run into an issue where the TPM spec specifies that for RSA PSS signing
> keys, the random salt length will be the largest size allowed by the key size
> and message digest size.
>
> Server side, in SSL state machine the salt length gets set to
> RSA_PSS_SALTLEN_DIGEST (aka -1) which means the salt length must equal the
> hash length. Since the TPM used the largest size allowed by the key size and
> message digest size, rather than digest size, the handshake fails.
>
> The TSS and TPM TCG working groups will be working to modify this behavior, so
> that the salt length equals the hash length. However, rolling out the update
> to
> the spec and then firmware updates to TPMs will take a very long time. As such
> we're wondering if OpenSSL would default to verifying with
> RSA_PSS_SALTLEN_AUTO for RSA PSS keys instead of RSA_PSS_SALTLEN_DIGEST
> as an intermediary measure.
>
> This was my original stab at it which made it work, which of course isn't
> upstreamable.
>
> diff --git a/crypto/rsa/rsa_pss.c b/crypto/rsa/rsa_pss.c
> index f7c575d00a..26c9dcd078 100644
> --- a/crypto/rsa/rsa_pss.c
> +++ b/crypto/rsa/rsa_pss.c
> @@ -50,6 +50,10 @@ int RSA_verify_PKCS1_PSS_mgf1(RSA *rsa, const unsigned
> char *mHash,
> hLen = EVP_MD_size(Hash);
> if (hLen < 0)
> goto err;
> +
> +dprintf(2, "openssl: sLen: %d\n", sLen);
> +sLen = -2;
> +
> /*-
> * Negative sLen has special meanings:
> * -1 sLen == hLen
>
>
>
> The following isn't hacky, but it doesn't work and I'm not yet sure why
> (still in the
> process of debugging but wanted to float the idea on the list).
>
>
>
> diff --git b/ssl/statem/statem_srvr.c a/ssl/statem/statem_srvr.c
> index 8cf9c40d15..d6793e01a4 100644
> --- b/ssl/statem/statem_srvr.c
> +++ a/ssl/statem/statem_srvr.c
> @@ -2783,7 +2783,7 @@ int tls_construct_server_key_exchange(SSL *s, WPACKET
> *pkt)
> }
> if (lu->sig == EVP_PKEY_RSA_PSS) {
> if (EVP_PKEY_CTX_set_rsa_padding(pctx, RSA_PKCS1_PSS_PADDING) <= > 0
> -|| EVP_PKEY_CTX_set_rsa_pss_saltlen(pctx,
> RSA_PSS_SALTLEN_DIGEST) <= 0) {
> +|| EVP_PKEY_CTX_set_rsa_pss_saltlen(pctx,
> RSA_PSS_SALTLEN_AUTO) <= 0) {
> SSLfatal(s, SSL_AD_INTERNAL_ERROR,
> SSL_F_TLS_CONSTRUCT_SERVER_KEY_EXCHANGE,
> ERR_R_EVP_LIB);
>
>
> Reference:
> https://github.com/tpm2-software/tpm2-pkcs11/pull/403#issuecomment-590395767
>
I was hoping to hear some thoughts from OSSL maintainers. I guess
perhaps the question wasn't clear. The
question is, can we relax the TLS requirement that slen == hlen and
set the flag to autodetect and upstream this?
Thanks,
Bill
Re: Add ECDSA signature R and S to X509 structure
This thread actually has some code on it for doing this: https://www.mail-archive.com/openssl-users@openssl.org/msg86672.html Bill On Mon, Aug 26, 2019 at 9:46 AM Ken Goldman wrote: > > On 8/17/2019 5:35 AM, Billy Brumley wrote: > > Hey Ken, > > > >> I have an ECDSA signature supplied to me as R and S byte arrays and > >> lengths (from an HSM). > >> > >> How do I add them to the X509 structure? > >> > >> Is there an API, a set of calls, or do you have any hints? > > > > You might be looking for ECDSA_SIG_set0: > > > > https://www.openssl.org/docs/man1.1.0/man3/ECDSA_SIG_set0.html > > > > You might find some snippets in ecdsatest.c. > > > > Hope it helps, > > I think so. This seems to work. Does it make sense? Is there a better way? > > - convert R and S, bin to bignum > - use ECDSA_SIG_set0 to create an ECDSA_SIG > - use i2d to convert the ECDSA_SIG to DER > - memcpy the DER into X509->signature->data > >
Re: i2d_ASN1_INTEGER zero pad
On Tue, Aug 6, 2019 at 11:18 AM William Roberts
wrote:
>
> On Tue, Aug 6, 2019 at 11:16 AM Matt Caswell wrote:
> >
> >
> >
> > On 06/08/2019 17:00, William Roberts wrote:
> > > On Tue, Aug 6, 2019 at 10:56 AM Matt Caswell wrote:
> > >>
> > >>
> > >>
> > >> On 06/08/2019 16:34, William Roberts wrote:
> > >>> Hi,
> > >>> I occasionally get spurious errors in my ECDSA signatures, and it
> > >>> appears that when the top byte is over 0x80 of either the R or S
> > >>> component, that I get a zero pad. I noticed all this when reading
> > >>> through the source, their was some comments (see below). I noticed a
> > >>> d2i_ASN1_UINTEGER, but I can't find a coresponding i2d_ version to
> > >>> create it. The zero pad seems to be the correct behavior, but it seems
> > >>> to be breaking things.
> > >>
> > >> As you note the zero pad is the correct behaviour.
> > >>
> > >>
> > >>> This is the link to the issue request I got filed for more details:
> > >>> https://github.com/tpm2-software/tpm2-pkcs11/issues/277
> > >>
> > >> This seems to be a problem in tmp2-pkcs11 and not OpenSSL. So its not
> > >> clear to
> > >> me what your question to openssl-users is?
> > >
> > > The questions is their is a d2i_ASN1_UINTEGER exists for that zero pad
> > > issue, is their a i2d version, I couldn't find one.
> >
> > No, an i2d version does not exists. d2i_ASN1_UINTEGER exists only for
> > interoperability with broken software. From the code (crypto/asn1/a_int.c):
> >
> > /*
> > * This is a version of d2i_ASN1_INTEGER that ignores the sign bit of ASN1
> > * integers: some broken software can encode a positive INTEGER with its MSB
> > * set as negative (it doesn't add a padding zero).
> > */
> >
> > ASN1_INTEGER *d2i_ASN1_UINTEGER(ASN1_INTEGER **a, const unsigned char **pp,
> > long length)
> >
> > Sine we don't want to *create* knowingly broken DER we don't provide the
> > equivalent function.
> >
>
> That's what I figured.
>
> >
> > >
> > > I guess a second question is, is their a better way to build an ECDSA
> > > signature from the R and S components, the code
> > > for ASNI sequence is something I never figured out, is their an
> > > example in ossl somewhere?
> >
> > If you have the r and s components in raw "binary" format then something
> > like
> > this should create an OpenSSL ECDSA_SIG object (totally untested):
> >
> > ECDSA_SIG *create_ecdsa_sig(unsigned char *r, size_t rlen, unsigned char *s,
> > size_t slen)
> > {
> > ECDSA_SIG *sig = ECDSA_SIG_new();
> >
> > if (sig == NULL)
> > return NULL;
> >
> > sig->r = BN_bin2bn(r, rlen, NULL);
> > sig->s = BN_bin2bn(s, slen, NULL);
> >
> > if (sig->r == NULL || sig->s == NULL) {
> > ECDSA_SIG_free(sig);
> > return NULL;
> > }
> >
> > return sig;
> > }
> >
> > Once you have the ECDSA_SIG structure then encoding it as DER is simply a
> > call
> > to i2d_ECDSA_SIG:
> >
> > https://www.openssl.org/docs/manmaster/man3/i2d_ECDSA_SIG.html
> >
>
> That's what I am looking for, thanks!
>
For completeness encase anyone else stumbles into this bit of lore, is
that pkcs11 doesn't use
the IETF ASN1 encoded scheme. While our code did occasionally suffer
from this "UNINTEGER" issue,
It actually uses a straight R + S concatenation.
However, this code will fix our tpm2-tools code.
> >
> > Matt
> >
> >
> >
> >
> >
> >
Re: i2d_ASN1_INTEGER zero pad
On Tue, Aug 6, 2019 at 11:16 AM Matt Caswell wrote:
>
>
>
> On 06/08/2019 17:00, William Roberts wrote:
> > On Tue, Aug 6, 2019 at 10:56 AM Matt Caswell wrote:
> >>
> >>
> >>
> >> On 06/08/2019 16:34, William Roberts wrote:
> >>> Hi,
> >>> I occasionally get spurious errors in my ECDSA signatures, and it
> >>> appears that when the top byte is over 0x80 of either the R or S
> >>> component, that I get a zero pad. I noticed all this when reading
> >>> through the source, their was some comments (see below). I noticed a
> >>> d2i_ASN1_UINTEGER, but I can't find a coresponding i2d_ version to
> >>> create it. The zero pad seems to be the correct behavior, but it seems
> >>> to be breaking things.
> >>
> >> As you note the zero pad is the correct behaviour.
> >>
> >>
> >>> This is the link to the issue request I got filed for more details:
> >>> https://github.com/tpm2-software/tpm2-pkcs11/issues/277
> >>
> >> This seems to be a problem in tmp2-pkcs11 and not OpenSSL. So its not
> >> clear to
> >> me what your question to openssl-users is?
> >
> > The questions is their is a d2i_ASN1_UINTEGER exists for that zero pad
> > issue, is their a i2d version, I couldn't find one.
>
> No, an i2d version does not exists. d2i_ASN1_UINTEGER exists only for
> interoperability with broken software. From the code (crypto/asn1/a_int.c):
>
> /*
> * This is a version of d2i_ASN1_INTEGER that ignores the sign bit of ASN1
> * integers: some broken software can encode a positive INTEGER with its MSB
> * set as negative (it doesn't add a padding zero).
> */
>
> ASN1_INTEGER *d2i_ASN1_UINTEGER(ASN1_INTEGER **a, const unsigned char **pp,
> long length)
>
> Sine we don't want to *create* knowingly broken DER we don't provide the
> equivalent function.
>
That's what I figured.
>
> >
> > I guess a second question is, is their a better way to build an ECDSA
> > signature from the R and S components, the code
> > for ASNI sequence is something I never figured out, is their an
> > example in ossl somewhere?
>
> If you have the r and s components in raw "binary" format then something like
> this should create an OpenSSL ECDSA_SIG object (totally untested):
>
> ECDSA_SIG *create_ecdsa_sig(unsigned char *r, size_t rlen, unsigned char *s,
> size_t slen)
> {
> ECDSA_SIG *sig = ECDSA_SIG_new();
>
> if (sig == NULL)
> return NULL;
>
> sig->r = BN_bin2bn(r, rlen, NULL);
> sig->s = BN_bin2bn(s, slen, NULL);
>
> if (sig->r == NULL || sig->s == NULL) {
> ECDSA_SIG_free(sig);
> return NULL;
> }
>
> return sig;
> }
>
> Once you have the ECDSA_SIG structure then encoding it as DER is simply a call
> to i2d_ECDSA_SIG:
>
> https://www.openssl.org/docs/manmaster/man3/i2d_ECDSA_SIG.html
>
That's what I am looking for, thanks!
>
> Matt
>
>
>
>
>
>
Re: i2d_ASN1_INTEGER zero pad
On Tue, Aug 6, 2019 at 10:56 AM Matt Caswell wrote: > > > > On 06/08/2019 16:34, William Roberts wrote: > > Hi, > > I occasionally get spurious errors in my ECDSA signatures, and it > > appears that when the top byte is over 0x80 of either the R or S > > component, that I get a zero pad. I noticed all this when reading > > through the source, their was some comments (see below). I noticed a > > d2i_ASN1_UINTEGER, but I can't find a coresponding i2d_ version to > > create it. The zero pad seems to be the correct behavior, but it seems > > to be breaking things. > > As you note the zero pad is the correct behaviour. > > > > This is the link to the issue request I got filed for more details: > > https://github.com/tpm2-software/tpm2-pkcs11/issues/277 > > This seems to be a problem in tmp2-pkcs11 and not OpenSSL. So its not clear to > me what your question to openssl-users is? The questions is their is a d2i_ASN1_UINTEGER exists for that zero pad issue, is their a i2d version, I couldn't find one. I guess a second question is, is their a better way to build an ECDSA signature from the R and S components, the code for ASNI sequence is something I never figured out, is their an example in ossl somewhere? > > Matt
i2d_ASN1_INTEGER zero pad
Hi,
I occasionally get spurious errors in my ECDSA signatures, and it
appears that when the top byte is over 0x80 of either the R or S
component, that I get a zero pad. I noticed all this when reading
through the source, their was some comments (see below). I noticed a
d2i_ASN1_UINTEGER, but I can't find a coresponding i2d_ version to
create it. The zero pad seems to be the correct behavior, but it seems
to be breaking things.
I understand the ECDSA signature to be a der encoded:
0x30 (ASN1 sequence>
0x (byte len of sequence)
0x20
0x
0x20
0x
Below we can see the zero pad on R where the first byte is 0xB2.
pSignature is what's in question:
26: C_Sign
2019-08-06 02:51:15.252
[in] hSession = 0x100
[in] pData[ulDataLen] 7ffe2dcc7520 / 32
A7 84 A1 44 7F 22 B3 52 98 D8 02 30 E3 7D 21 BD ...D^?".R...0.}!.
0010 C9 78 3E 3B 9C 1B 53 BA FD 95 B7 93 A6 64 E5 4E .x>;..S..d.N
[out] pSignature[*pulSignatureLen] 558c88c9b640 / 71
30 45 02 21 00 B2 F0 60 57 11 B3 63 83 94 FB 15 0E.!...`W..c
0010 74 DC 8C DF A8 2E D9 29 35 89 F7 15 74 70 11 9D t..)5...tp..
0020 3A E1 3A BE 10 02 20 42 4A 99 54 2E 0D D5 32 92 :.:... BJ.T...2.
0030 3B 7B 96 E9 2F B8 8B 24 77 38 2F 37 FD 13 98 35 ;{../..$w8/7...5
0040 4E FC C1 D2 80 6E 46 NnF
Returned: 0 CKR_OK
-- details and links --
This is the link to the issue request I got filed for more details:
https://github.com/tpm2-software/tpm2-pkcs11/issues/277
https://docs.huihoo.com/doxygen/openssl/1.0.1c/a__int_8c_source.html
95 * Positive integers are no problem: they are almost the same as the DER
96 * encoding, except if the first byte is >= 0x80 we need to add
a zero pad.
266 /* This is a version of d2i_ASN1_INTEGER that ignores the sign bit of
267 * ASN1 integers: some broken software can encode a positive INTEGER
268 * with its MSB set as negative (it doesn't add a padding zero).
269 */
270
271 ASN1_INTEGER *d2i_ASN1_UINTEGER(ASN1_INTEGER **a, const unsigned
char **pp,
272 long length)
273 {
https://www.openssl.org/docs/man1.1.0/man3/d2i_ASN1_UINTEGER.html
Re: [openssl-users] Question on implementing the ameth ctrl ASN1_PKEY_CTRL_DEFAULT_MD_NID
On Wed, Nov 28, 2018 at 1:22 AM Fuchs, Andreas wrote: > > Hi all, > > I'm currently implementing a TPM2 engine for OpenSSL over at > https://github.com/tpm2-software/tpm2-tss-engine > The problem I'm facing is that OpenSSL's TLS negotiation will request ECDSA > from my engine with any hash alg, even though the TPM's keys are restricted > to just one specific hash alg. What about when keys aren't restricted to one specific signing scheme and support raw encrypt/decrypt? You could just synthesize it by building up the signature structure on the client side and using the raw primitives to encrypt the signing structure directly. > > Most recently, David Woodhouse pointed out the possibility to require a > certain hash-alg from the key to TLS via the ameth > ASN1_PKEY_CTRL_DEFAULT_MD_NID at > https://github.com/tpm2-software/tpm2-tss-engine/issues/31 > > Since I'm not that familiar with OpenSSL, I wanted to confirm that I'm > following the right path for implementing this. > Thus: Is the following approach correct ? > > So, at > https://github.com/tpm2-software/tpm2-tss-engine/blob/master/src/tpm2-tss-engine-ecc.c#L328: > - I need to call "const EVP_PKEY_ASN1_METHOD *EVP_PKEY_get0_asn1(const > EVP_PKEY *pkey)" to get the ameth ? > - I need to call EVP_PKEY_asn1_set_ctrl(EVP_PKEY_ASN1_METHOD *ameth, > (*pkey_ctrl)) to some pkey_ctrl for ECC keys of mine ? > - That pkey_ctrl is a int (*pkey_ctrl) (EVP_PKEY *pkey, int op, long arg1, > void *arg2)) that implements the op ASN1_PKEY_CTRL_DEFAULT_MD_NID ? > - That pkey_ctrl()'s ASN1_PKEY_CTRL_DEFAULT_MD_NID looks up the hash for the > provided pkey's ecc key from the tpm2data and returns it via *(int *)arg2 = > NID_sha1 or NID_sha256 or etc and then returns 1 or 2 or something ? > - Which one of the return codes (1 or 2) makes it mandatory rather than > recommended ? > > Thanks a lot for any advice, > Andreas > -- > 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
[openssl-users] public version of encode_pkcs1
I would like to use OpenSSL to compute the DigestInfo structure to pass to a TPM for a TPM side RSA_Decrypt() operation when the TPM doesn't support the digest algorithm. I see in crypt/rsa_sign.c the routine encode_pkcs1() seems to do what I want. Is their a public version of this or a better way to do this? I could just use the pre-computed ASN1 headers from the Notes section in RFC3447 and concatenate the digest but my initial reaction to that idea is don't do it. Thoughts or ideas? Bill -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] How to encode R and S of an ECDSA signature to ASN1 sequence
I can successfully deconstruct an an ECDSA Signature Sequence, but now I
need
to construct it, and I am getting lost.
The format I need to build is:
sECDSA-Sig-Value ::= SEQUENCE { r INTEGER, s INTEGER }
I have r and s as buffers in the same format as returned from:
d2i_ASN1_INTEGER() if one used it to remove r or s from the sequence above.
I am not sure how to compose the sequence given r and s, and if their is a
routine to
essentially do the opposite of d2i_ASN1_INTEGER.
Thanks,
Bill
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Using a TPM to sign CSRs
On Sat, Jul 28, 2018, 09:13 Devang Kubavat wrote: > Hi Kaarhik, > > Please refer https://github.com/ThomasHabets/openssl-tpm-engine. It is > OpenSSL TPM Engine. It will help to offload all crypto operation to TPM. > Is this for tpm2.0? > Regards, > Devang. > > On Tue, Jul 24, 2018 at 4:48 PM, Kaarthik Sivakumar > wrote: > >> Hello >> >> I need to create a key pair using a TPM (proprietary) and build a CSR and >> sign it using it the TPM as well. Currently I dont have an engine interface >> to talk to the TPM. I do the following: >> >> 1. generate key pair in the TPM. private key is kept private in the TPM >> and public key can be obtained out of the TPM >> >> 2. use the public key to generate a CSR (X509_REQ_init(), etc) >> >> 3. Get the hash of the CSR (X509_REQ_digest()) >> >> 4. Pass the digest to the TPM and get back signature >> >> 5. Add signature to the CSR - I dont see any way to do this. Is there an >> openssl API to perform this step? I dont think I can use X509_REQ_sign() >> since that will use the private key provided or if I have an engine >> interface then it will call the engine to do the signing. Is there a way to >> call sign() and make it call my function that can do the step 4 above? >> >> Thanks! >> >> -kaarthik- >> >> >> -- >> 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 > -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] conversion of RAND_bytes to rand in fips apporved way
On Wed, Jul 25, 2018 at 11:30 AM, Michael Wojcik
wrote:
>> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
>> Sudarshan Soma
>> Sent: Wednesday, July 25, 2018 12:13
>
>> But rand() returns max value of 32767 . Is there a recomended way to
>> convert RAND_bytes to libc rand()
>> something like this?
>
>> unsigned char buf[2];
>> RAND_bytes(buf,2)
>> int *rndp = malloc(4);
>> memcpy(rndp,buf,2);
>> return (unsigned) ((*rndp) % 32768)
>
> Ugh. Memory leak, unnecessary malloc, undefined behavior (only part of the
> rdnp object is initialized)... I really hope you don't have code like this in
> your application.
>
> C guarantees unsigned integer types use a pure binary representation, and
> 32767 is 2**15 - 1. So assuming you're only using octet-based C
> implementations (limits.h defines CHAR_BIT as 8), which is very likely the
> case, just do this:
>
> unsigned int openssl_rand(void) {
LibC's rand() is int, so if it matters you'll want to match that
interface. But usually, you want to avoid signed numbers when negative
doesn't matter..
>unsigned char bytes[2];
>RAND_bytes(bytes, 2);
>return (bytes[0] | (bytes[1] << 8)) & 0x7fff;
You can ditch the shift logic. Offhand, i'm not sure what would
happen on Big Endian machine, would it leave bit 15 high since it's in
byte 0?
int openssl_rand(void) {
uint16_t x;
RAND_bytes((unsigned char *), sizeof(x));
return x & 0x7FFF;
}
> }
>
> Untested, but I think that will work on any conforming C implementation with
> CHAR_BIT == 8, and as long as the 15 least-significant bits of the output of
> RAND_bytes are unbiased, the result will be an unbiased value in [0,32767].
>
> Note this does not give you the semantics of C's rand, as it ignores any
> invocation of srand. Some C programs require a predictable rand; they use it
> for reproducible Monte Carlo test runs, for example. So replacing rand this
> way is not necessarily valid.
>
> Also, calling it "rand" would be a violation of the C specification, so if
> you want your C applications to conform to the spec, you'll have to change
> them anyway. Or use a macro, provided the application code never suppresses a
> macro definition for rand.
>
> --
> Michael Wojcik
> Distinguished Engineer, Micro Focus
>
>
> --
> 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
Re: [openssl-users] Using a TPM to sign CSRs
On Tue, Jul 24, 2018 at 4:18 AM, Kaarthik Sivakumar wrote: > Hello > > I need to create a key pair using a TPM (proprietary) and build a CSR and What TPM Version? If it's TPM 2.0, a new Engine project has emerged here: https://github.com/tpm2-software/tpm2-tss-engine This might be able to handle to just calling the create CSR routine. I know back-in- the-day the OpenSC engine with a PIV card could do it. You can try to get ahold of the maintainer of that project (Andraes) through a direct email or the project mailing list: - https://lists.01.org/mailman/listinfo/tpm2 > sign it using it the TPM as well. Currently I dont have an engine interface > to talk to the TPM. I do the following: > > 1. generate key pair in the TPM. private key is kept private in the TPM and > public key can be obtained out of the TPM > > 2. use the public key to generate a CSR (X509_REQ_init(), etc) > > 3. Get the hash of the CSR (X509_REQ_digest()) > > 4. Pass the digest to the TPM and get back signature > > 5. Add signature to the CSR - I dont see any way to do this. Is there an > openssl API to perform this step? I dont think I can use X509_REQ_sign() > since that will use the private key provided or if I have an engine > interface then it will call the engine to do the signing. Is there a way to > call sign() and make it call my function that can do the step 4 above? > > Thanks! > > > -kaarthik- > > > -- > 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
Re: [openssl-users] engine interface for genrsa
On Thu, Apr 19, 2018 at 7:45 PM, Scott Wisniewski
<swisniew...@salesforce.com> wrote:
> 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,
>
> _data))
>
> goto end;
>
> }
>
>
> instead of:
>
> if (!PEM_write_bio_RSAPrivateKey(out, rsa, enc, NULL, 0,
>
> (pem_password_cb *)password_callback,
>
> _data))
>
>goto end;
>
>
> And then it will save the key you generated in public key pem format. which
> will allow openssl to read it.
Good to know, thanks for the detail.
>
> 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).
I have only looked at the PKCS11 module, and it's quite limited in
functionality.
I've been extending it submitting patches as they make sense. I just added
random support.
>
> On Fri, Apr 13, 2018 at 5:28 PM, William Roberts <bill.c.robe...@gmail.com>
> wrote:
>>
>> On Fri, Apr 13, 2018 at 2:55 PM, Richard Levitte <levi...@openssl.org>
>> wrote:
>> > In message
>> > <CAFftDdqWPXq1+Mo9_6J0EzhZ4uwg5QC=R5fx8N1j=qycha8...@mail.gmail.com> on
>> > Fri,
>> > 13 Apr 2018 09:17:28 -0700, William Roberts <bill.c.robe...@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 levi...@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
>
>
>
> --
> 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
Re: [openssl-users] engine interface for genrsa
On Fri, Apr 13, 2018 at 2:55 PM, Richard Levitte <levi...@openssl.org> wrote: > In message > <CAFftDdqWPXq1+Mo9_6J0EzhZ4uwg5QC=R5fx8N1j=qycha8...@mail.gmail.com> on Fri, > 13 Apr 2018 09:17:28 -0700, William Roberts <bill.c.robe...@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 levi...@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
[openssl-users] engine interface for genrsa
I am currently working on writing an openssl engine to interface with a piece of hardware. I am trying to understand how to implement rsa key generation, where the private key bytes would not be available. I am currently invoking the command: openssl genrsa -engine foo Which is calling my callback for RSA keygen, registered via ENGINE_set_RSA() and I set the flags: RSA_FLAG_EXT_PKEY. However, genrsa app seems to want rsa->e set here: https://github.com/openssl/openssl/blob/OpenSSL_1_0_2g/apps/genrsa.c#L291 I can't find documentation on how to handle the keygen interface for RSA. Can someone point me in the right direction? Thanks, Bill -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
