Re: tbslen parameter in EVP_PKEY_sign() and EVP_PKEY_verify()
Yes (duh) of course. The actual sign and verify functions don't know anything about the original payload. They only care about the thing being signed. Thanks for the help! On Tue, Apr 7, 2020 at 11:18 AM Kyle Hamilton wrote: > > 32 bytes means you're signing using RSA-WITH-SHA-256, yes? > > tbs is the digest value you calculated, tbslen is the size in bytes of > the digest. > > -Kyle H > > On Tue, Apr 7, 2020 at 1:07 PM Jason Proctor wrote: > > > > Esteemed cryptologists, > > > > Question regarding the "tbslen" parameter to the sign and verify > > functions. The documentation says -- > > > > "The verified data (i.e. the data believed originally signed) is > > specified using the tbs and tbslen parameters." > > > > Which might indicate that tbslen is the length of the payload. However > > I found that I had to set this to the length of the *signature* to get > > these calls to work. The sign() operation fails at rsa_pmeth.c line > > 134, and the debugger does indeed tell me that it's expecting 32 > > there, rather than the payload length which is 1024. > > > > Is this correct? Anything I'm missing, here? > > > > thanks for any clarity here > > Jason@Spatial
tbslen parameter in EVP_PKEY_sign() and EVP_PKEY_verify()
Esteemed cryptologists, Question regarding the "tbslen" parameter to the sign and verify functions. The documentation says -- "The verified data (i.e. the data believed originally signed) is specified using the tbs and tbslen parameters." Which might indicate that tbslen is the length of the payload. However I found that I had to set this to the length of the *signature* to get these calls to work. The sign() operation fails at rsa_pmeth.c line 134, and the debugger does indeed tell me that it's expecting 32 there, rather than the payload length which is 1024. Is this correct? Anything I'm missing, here? thanks for any clarity here Jason@Spatial
Re: OpenSSL vs SPKI
On Mon, Apr 6, 2020 at 10:03 PM William Roberts wrote: > > > > 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 Thanks for the help. Turns out, d2i_PUBKEY() does exactly the thing. The advantage over picking BIGNUMs out of the SPKI bundle is that the code doesn't need to know the key size.
Re: OpenSSL vs SPKI
On Mon, Apr 6, 2020 at 11:03 PM Viktor Dukhovni wrote: > > > Question -- is there a supported way of importing SPKI encoded public > > keys into the OpenSSL world? > > Yes. That'd be d2i_PUBKEY(3): > > https://www.openssl.org/docs/man1.1.1/man3/d2i_PUBKEY.html > Perfect! Thanks so much.
Re: OpenSSL vs SPKI
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 :-) any help with SPKI welcome! J
OpenSSL vs SPKI
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.) 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: SSL_connect returns -1 on HPUX
this is exactly the symptom i got when the optimiser on my compiler got a few things confused and SSL_connect() was thinking a simple allocation had failed when it had in fact succeeded. i got round that by building a library without the optimiser flags. can you do a regular ./configure? if so, just hack the debug flags into the makefile directly. on my port, it's line 63 of the makefile, starts with CFLAG =. slap a -g on the end, and you might want to get rid of any -O flags for good measure, too. then make clean and make all. hth j I am trying to open a client ssl connection and SSL_connect() is returning -1 on my HPUX port of my code. Note this exact code currently works (connects successfully and can send and receive data) on Linux, SunOS, INTERIX(Windows Services for UNIX). What I know SSL_connect() returns -1 errno is 0 immediately after that call ERR_error_string(ERR_get_error(), NULL) yields no error: error::lib(0):func(0):reason(0) SSL_get_error(ssl, success) yields an error of SSL_ERROR_SYSCALL What are some steps I can take to troubleshoot the client connection? I can't do too much to the server and know that it works fine in the other aforementioned environments. I was looking into compiling the ssl libraries in debug mode to step through the SSL_Connect call but get an unsupported system error when trying to do a ./configure -d to build the debug libraries. Any suggestions on where to start? If necessary for any system specific gotchas I may be unaware of my uname output: HP-UX --- B.11.00 U 9000/800 - unlimited-user license Thanks __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: SSL_connect returns -1 on HPUX
yuck. ok in that case just try getting rid of the optimiser flags? worked for me. that's all i can suggest... Thanks for the quick response. Unfortunately I run into a compilation error when trying to compile in debug mode (I had not compiled the libraries before as I obtained precompiled libraries). Unfortunately I am stuck on gcc 2.8.1 and can't install a new compiler and I'm afraid that may prevent me from building. Any ideas? The compiler error is below but I have a bad feeling they way to handle it would be to get the latest version of gcc. gcc -I.. -I../../include -DTHREADS -DDSO_DL -DNO_ASM -D_REENTRANT -O3 -DB_ENDIAN -DBN_DIV2W -c bn_err.c -o bn_err.o gcc -I.. -I../../include -DTHREADS -DDSO_DL -DNO_ASM -D_REENTRANT -O3 -DB_ENDIAN -DBN_DIV2W -c bn_sqr.c -o bn_sqr.o gcc -I.. -I../../include -DTHREADS -DDSO_DL -DNO_ASM -D_REENTRANT -O3 -DB_ENDIAN -DBN_DIV2W -c bn_asm.c -o bn_asm.o gcc: Internal compiler error: program cc1 got fatal signal 11 make[2]: *** [bn_asm.o] Error 1 make[2]: Leaving directory `/home/andrew/openssl/openssl-0.9.6/crypto/bn' make[1]: *** [subdirs] Error 1 make[1]: Leaving directory `/home/andrew/openssl/openssl-0.9.6/crypto' make: *** [all] Error 1 On 8/29/07, Jason Proctor mailto:[EMAIL PROTECTED][EMAIL PROTECTED] wrote: this is exactly the symptom i got when the optimiser on my compiler got a few things confused and SSL_connect() was thinking a simple allocation had failed when it had in fact succeeded. i got round that by building a library without the optimiser flags. can you do a regular ./configure? if so, just hack the debug flags into the makefile directly. on my port, it's line 63 of the makefile, starts with CFLAG =. slap a -g on the end, and you might want to get rid of any -O flags for good measure, too. then make clean and make all. hth j I am trying to open a client ssl connection and SSL_connect() is returning -1 on my HPUX port of my code. Note this exact code currently works (connects successfully and can send and receive data) on Linux, SunOS, INTERIX(Windows Services for UNIX). What I know SSL_connect() returns -1 errno is 0 immediately after that call ERR_error_string(ERR_get_error(), NULL) yields no error: error::lib(0):func(0):reason(0) SSL_get_error(ssl, success) yields an error of SSL_ERROR_SYSCALL What are some steps I can take to troubleshoot the client connection? I can't do too much to the server and know that it works fine in the other aforementioned environments. I was looking into compiling the ssl libraries in debug mode to step through the SSL_Connect call but get an unsupported system error when trying to do a ./configure -d to build the debug libraries. Any suggestions on where to start? If necessary for any system specific gotchas I may be unaware of my uname output: HP-UX --- B.11.00 U 9000/800 - unlimited-user license Thanks __ OpenSSL Project http://www.openssl.orghttp://www.openssl.org User Support Mailing Listmailto:openssl-users@openssl.orgopenssl-users@openssl.org Automated List Manager mailto:[EMAIL PROTECTED][EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
openssl certificate verification question
dear list, i'm having a real adventure trying to get gsoap openssl to behave consistently and i would appreciate some pointers before i run out of hair completely. i'm on MacOS X 10.4.9 but i shifted over to Linux Fedora Core 2 because debugging on the Mac is impossible thanks to the linker's insistence on linking the dylib version of the SSL library instead of the one i built from scratch and linked the program against. sigh. i have openssl 0.9.8a. initially my symptoms were that memory allocation routines were failing inside ssl23_connect(). i eventually tracked this down to the optimiser being a bit over-enthusiastic (on *both* platforms, maybe this is a wide-spread GCC problem), and after rebuilding the openssl library with the -O3 flag turned off, i get no weird problems like that - but i'm now getting certificate verification errors. my next step was to extract the openssl calls that gsoap was making and put them in a micro-app. the source for this app, which is definitely hacky test app code IYKWIM, is here - http://www.redfish.net/ssl2_safe.c - i've taken out the name of the server i'm connecting to because i work for a stealth mode startup. anyway, the micro-app works fine and can happily read write content over the SSL connection. running through the two apps with the debugger, it seems like the ssl3_get_server_certificate() routine errors out in the real program, but is happy in the micro-app. i should also say here that all the browsers i know of, and the Windows version of this application, and our Java webservices clients, are all 100% happy with the certificate setup on the server. so my question is -- could gsoap be doing some openssl setup somewhere that affects whether the certificate passes muster? under what circumstances could a certificate be OK to one openssl client but not another? is there a strictness control i could manipulate? thanks much for any help with this. jason __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
openssl cert problem diagnosed, bug report
dear list, further to my question earlier today i've been able to figure out what's going on and i have an interim solution, though i think the situation warrants an openssl bug report. in my micro-app, i wasn't setting up any client or server verification requirements. these seem to default to no verification, so the cert chain was being checked but the errors ignored. in the SOAP app, someone was requiring server verification, and openssl didn't like the self-signed cert in the chain, so the verification failed. for now, i've disabled server verification in my openssl setup, and that seems to make things work (duh). of course this isn't a good long-term solution but it will have to do for now. bug report: openssl rejects certificates which have self-signed elements in the chain, regardless of whether there are other trusted elements in the chain. my server certificates were generated using conventional procedures, and so it seems prudent to remark that openssl will probably barf on a good number of server certs out there. again - the certs on my servers work 100% fine with all the major browsers, the Windows version of my program, and all our Java SSL clients. wget doesn't work, because it uses openssl. thanks for the bandwidth. jason __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
