Re: DH_compute_key query
Sindya, Looking at the hexdump issue earlier in the thread, I have a question for you. Is your memory buffer block or word aligned? Some mismatch here may cause some block computation issues. - Steve > Steve, > > I am also facing a similar issue. In my case the key generated by > DH_compute_key need to be used by hash function for authentication > purpose. > Even after prepending the key with zeros, hash'd value is not same as the > other end. > > Is there any built-in or openSSL function that will prepend the key with > zeros. I tried different string functions for this purpose but it is not > helping me. > > Can you please help me with this? > > -Sindya. > > > > -- > View this message in context: > http://openssl.6102.n7.nabble.com/DH-compute-key-query-tp13943p47257.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 > > __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: DH_compute_key query
Steve, I am also facing a similar issue. In my case the key generated by DH_compute_key need to be used by hash function for authentication purpose. Even after prepending the key with zeros, hash'd value is not same as the other end. Is there any built-in or openSSL function that will prepend the key with zeros. I tried different string functions for this purpose but it is not helping me. Can you please help me with this? -Sindya. -- View this message in context: http://openssl.6102.n7.nabble.com/DH-compute-key-query-tp13943p47257.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: FIPS support with shared libraries on FreeBSD 9.1
I am facing the same issue and getting same error on FreeBED 9.1 as below. FIPS routines:FIPS_check_incore_fingerprint:fingerprint does not match:fips.c:232: Only thing different is I am using openssl-fips-2.0.5. Did anyone get solution for this problem? --Girish -- View this message in context: http://openssl.6102.n7.nabble.com/FIPS-support-with-shared-libraries-on-FreeBSD-9-1-tp44127p47255.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
verifying signature of self-signed certificate
Hello list, given that I know in advance the remote end's RSA public key, and that the remote end is responding to my TLS handshake with a self-signed certificate signed by his private RSA key, then what is the proper way of verifying that nobody has tampered with the connection? What I am currently doing is twofold: 1. compare the stored key with the one received via X509_get_pubkey(SSL_get_peer_certificate()) 2. Verify that it was indeed signed by the remote peer: X509_verify(received_cert, received_pubkey) Thanks in advance, Dimitris __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: ssl handshake failure in 1.0.1 but not 1.0.0
> From: Viktor Dukhovni > > You can test with s_client(1) and compare results. Is your client > certificate an > RSA certificate? How many bits of public key? Is its signature SHA1 or > SHA256? It's a 2048 bit RSA SHA1 certificate, but I think Dave Thompson's right and it's not getting that far. I have tried using s_client and it fails with the same handshake failure. Please see below. > Attaching a PCAP file of the traffic is much more useful than hex packet > dumps. You're right of course, that is much more sensible. I have attached two pcap traces from s_connect, one success and one failure. > From: Dave Thompson > > To OP: is the logged server cert info true? I note the log shows the client > verification of the server failed; did this website give you a "custom" root > to > trust and did you simply not set that up (or perhaps not in the environment > you're testing in)? > Yes, the server has a custom root cert that isn't installed on this machine. I am happy that the server cert is correct. > To OP: If you can try to reproduce with s_client default (which is > TLSv1.2 or less) and again specifying -tls1 (or -no_tls1_2 -no_tls1_1). > That might narrow it down pretty close. I can reproduce the failure with s_client in the same manner. It looks (to me) like the server only asks for the client certificate once the GET command has been issued, the initial negotiation doesn't ask for it. I don't know the TLS protocol so that might be normal. Once I send the GET ... command it tries to renegotiate but fails. Looking at the output from s_client -state I see this during the first negotiation... --- No client certificate CA names sent --- SSL handshake has read 2884 bytes and written 639 bytes --- New, TLSv1/SSLv3, Cipher is DES-CBC3-SHA Server public key is 2048 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE And then I send GET /directory HTTP/1.1 and see... SSL_connect:SSL renegotiate ciphers SSL_connect:unknown state SSL_connect:failed in unknown state 16444:error:140940E5:SSL routines:SSL3_READ_BYTES:ssl handshake failure:.\ssl\s3_pkt.c:1156: > From: Krzysztof Kwiatkowski > > Do you still see an error if you specify one cipher? f.e. AES256-SHA? I do get an error when using AES256-SHA, in fact a much earlier error as the server does not support that cipher, nor does it support AES-128-SHA. However I took the idea and if I add -cipher "DES-CBC3-SHA" (as selected by the server in the previous run) to s_connect then everything works OK, and if I add the same cipher selection to my program that that works too. When I do specify DES-CBC3-SHA, s_client also reports Secure Renegotiation IS supported This sounds important to me! :) Notice that the failure case reports renegotiation is NOT supported. So the question now is, how come negotiation *is* supported when I manually specify DES-CBC3-SHA and *not* supported when I leave default ciphers, when the server ends up picking DES-CBC3-SHA anyway. I have attached two pcap files, both captured using s_client - one with the default ciphers and one with -cipher "DES_CBC3-SHA". I notice that the Client Hello is slightly different, when using all ciphers there are two extra extensions: ec_point_formats and elliptic_curves. Whether or not this is relevant I have no idea, I imagine not as they are likely omitted because DES isn't ECC. For now all the servers I need to talk to support DES-CBC3-SHA, this may not always be the case. Any idea how likely it is I will find a server that doesn't? Or is there something else I can set to make renegotiation supported without specifying the cipher. Thanks for all your suggestions so far, Ben s_client_default.pcap Description: s_client_default.pcap s_client_des_cbc3_sha.pcap Description: s_client_des_cbc3_sha.pcap
Re: EC private key generation problem
On Fri, Nov 08, 2013 at 01:37:21PM +0200, Serhat Sevki Dincer wrote: > what's the correct commandline? You can alternatively generate ec keys with ecparam(1): $ umask 077 $ openssl ecparam -genkey -name prime256v1 | openssl pkey -aes128 -out priv.pem -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Memory Management Using RSA_public_encrypt
Hello,
I am currently trying to fix some memory leaks I introduced into my
application, and am left with some leaks (according to valgrind) that
seem to relate to RSA_public_encrypt. However, I cannot detect any
problem with not freeing memory I explicitly allocated.
Hence the question: Do I miss something using RSA_public_encrypt?
I wrote a wrapper for RSA_public_encrypt, which breaks down to this,
ignoring some sanity checking:
unsigned char *RSA_encrypt(
PublicKeyRSA *public_key,
unsigned char* plaintext,
int *plaintext_length)
{
unsigned char *ciphertext = malloc(RSA_size(public_key));
int result;
result = RSA_public_encrypt(
*plaintext_length,
plaintext,
ciphertext,
public_key,
RSA_PADDING
);
return ciphertext;
}
Valgrind repeatedly reports the RSA_public_encrypt line as a source of
mempory leaks, for example:
==6359== 5,456 (1,144 direct, 4,312 indirect) bytes in 11 blocks are
definitely lost in loss record 22 of 23
==6359==at 0x4C2B6CD: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6359==by 0x5A5E133: CRYPTO_malloc (in
/lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==6359==by 0x5AA41E6: BN_MONT_CTX_new (in
/lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==6359==by 0x5AA45B7: BN_MONT_CTX_set_locked (in
/lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==6359==by 0x5AC751A: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==6359==by 0x40A162: RSA_getEncryptedSymmetricKey (rsa.c:217)
...
As suggested in
http://www.mail-archive.com/openssl-dev@openssl.org/msg08797.html,
I added OpenSSL's memleak checking to my application, but I do not know
how to interpret the output:
[14:57:43] 3655 file=bn_lib.c, line=317, thread=139918492813024,
number=264, address=0252FBF0
[14:57:48] 5389 file=bn_lib.c, line=317, thread=139918492813024,
number=136, address=025387A0
[14:57:48] 4941 file=bn_mont.c, line=325, thread=139918492813024,
number=104, address=02530A10
[14:57:53] 7767 file=stack.c, line=125, thread=139918492813024,
number=32, address=02485250
[14:57:48] 5449 file=bn_lib.c, line=317, thread=139918492813024,
number=264, address=02539710
[14:57:48] 4557 file=bn_mont.c, line=325, thread=139918492813024,
number=104, address=0252FA70
[14:57:43] 3435 file=bn_mont.c, line=325, thread=139918492813024,
number=104, address=02526CE0
[14:57:48] 4969 file=bn_lib.c, line=317, thread=139918492813024,
number=264, address=02537770
[14:57:48] 5325 file=bn_mont.c, line=325, thread=139918492813024,
number=104, address=025385F0
[14:57:43] 4074 file=bn_lib.c, line=283, thread=139918492813024,
number=24, address=02525B30
[14:57:53] 7769 file=lhash.c, line=193, thread=139918492813024,
number=24, address=0247D250
[14:57:43] 3533 file=bn_lib.c, line=317, thread=139918492813024,
number=128, address=02526AD0
[14:57:48] 4525 file=bn_lib.c, line=317, thread=139918492813024,
number=136, address=025326B0
[14:57:43] 3691 file=bn_lib.c, line=317, thread=139918492813024,
number=136, address=0252F800
[14:57:48] 5292 file=bn_lib.c, line=283, thread=139918492813024,
number=24, address=025383E0
[14:57:43] 4072 file=rsa_lib.c, line=139, thread=139918492813024,
number=168, address=02525A10
[14:57:43] 4039 file=bn_lib.c, line=317, thread=139918492813024,
number=264, address=025315C0
[14:57:53] 7772 file=stack.c, line=127, thread=139918492813024,
number=32, address=02531590
[14:57:48] 4943 file=bn_lib.c, line=317, thread=139918492813024,
number=128, address=0252E680
[14:57:43] 3367 file=bn_lib.c, line=317, thread=139918492813024,
number=264, address=02526920
[14:57:48] 5231 file=bn_lib.c, line=317, thread=139918492813024,
number=128, address=02538200
[14:57:48] 5005 file=bn_lib.c, line=317, thread=139918492813024,
number=136, address=02537320
[14:57:43] 4107 file=bn_mont.c, line=325, thread=139918492813024,
number=104, address=02530440
[14:57:48] 4653 file=bn_mont.c, line=325, thread=139918492813024,
number=104, address=02524FD0
[14:57:43] 3405 file=bn_lib.c, line=317, thread=139918492813024,
number=8, address=02526770
[14:57:48] 4430 file=bn_lib.c, line=283, thread=139918492813024,
number=24, address=0252F4D0
[14:57:53] 7773 file=lhash.c, line=193, thread=139918492813024,
number=24, address=02536A00
[14:57:43] 3307 file=bn_lib.c, line=317, thread=139918492813024,
number=136, address=02525F10
[14:57:48] 5295 file=bn_lib.c, line=317, thread=139918492813024,
number=8, address=025379D0
[14:57:43] 3404 file=bn_lib.c, line=283, thread=139918492813024,
number=24, address=025266E0
[14:57:48] 4461 file=bn_mont.c, line=325, thread=139918492813024,
number=104, address=0252F440
[14:57:48] 5037 file=bn_mont.c, line=325, thread=139918492813024,
number=104, address=02537170
[14:57:43] 3531 file=bn_mont.c, line=325, thread=139918492813024,
number=104, address=025256B0
[14:57:48] 5294 file=bn_lib.c, line=283, thread=139918492813024,
number=24, address=02537940
[14:57:43] 3306 file=bn_lib.c, line=283, thread=139918492813024,
num
Re: EC private key generation problem
On Fri, Nov 08, 2013 at 01:37:21PM +0200, Serhat Sevki Dincer wrote:
> On windows 7 with OpenSSL 1.0.1e, I get the following output:
>
> $ openssl.exe genpkey -out priv.pem -aes128 -algorithm EC -pkeyopt
> ec_paramgen_curve:secp224r1
>
> parameter setting error 3512:error:06089094:digital envelope
> routines:EVP_PKEY_CTX_ctrl:invalid operation:.\crypto\evp\pmeth_lib.c:404
>
> Is this a bug? what's the correct commandline?
This is a bug, it is fixed on the OpenSSL master branch. The fix for
1.0.1e is to apply the same change.
diff --git a/crypto/ec/ec.h b/crypto/ec/ec.h
index dfe8710..50cf8c1 100644
--- a/crypto/ec/ec.h
+++ b/crypto/ec/ec.h
@@ -960,7 +960,8 @@ int EC_KEY_print_fp(FILE *fp, const EC_KEY *key, int off);
#endif
#define EVP_PKEY_CTX_set_ec_paramgen_curve_nid(ctx, nid) \
- EVP_PKEY_CTX_ctrl(ctx, EVP_PKEY_EC, EVP_PKEY_OP_PARAMGEN, \
+ EVP_PKEY_CTX_ctrl(ctx, EVP_PKEY_EC, \
+ EVP_PKEY_OP_PARAMGEN|EVP_PKEY_OP_KEYGEN, \
EVP_PKEY_CTRL_EC_PARAMGEN_CURVE_NID, nid, NULL)
If someone on OpenSSL team adopts the above, they may as well also
apply the below fix which silences a compiler warning about a
potentially uninitialized variable 'i'
diff --git a/crypto/pem/pem_lib.c b/crypto/pem/pem_lib.c
index 5a421fc..f562181 100644
--- a/crypto/pem/pem_lib.c
+++ b/crypto/pem/pem_lib.c
@@ -477,13 +477,12 @@ int PEM_do_header(EVP_CIPHER_INFO *cipher, unsigned char
*data, long *plen,
EVP_CIPHER_CTX_cleanup(&ctx);
OPENSSL_cleanse((char *)buf,sizeof(buf));
OPENSSL_cleanse((char *)key,sizeof(key));
- j+=i;
if (!o)
{
PEMerr(PEM_F_PEM_DO_HEADER,PEM_R_BAD_DECRYPT);
return(0);
}
- *plen=j;
+ *plen=j + i;
return(1);
}
--
Viktor.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: EC private key generation problem
On Fri, Nov 08, 2013, Serhat Sevki Dincer wrote: > Hi, > On windows 7 with OpenSSL 1.0.1e, I get the following output: > > $ openssl.exe genpkey -out priv.pem -aes128 -algorithm EC -pkeyopt > ec_paramgen_curve:secp224r1 > > parameter setting error 3512:error:06089094:digital envelope > routines:EVP_PKEY_CTX_ctrl:invalid operation:.\crypto\evp\pmeth_lib.c:404 > > Is this a bug? what's the correct commandline? > It's more a missing feature than a bug. For OpenSSL 1.0.1 and below you have to "generate" parameters for EC in the same way as DSA/DH. For exampple: openssl genpkey -genparam -algorithm EC -pkeyopt ec_paramgen_curve:secp224r1 -out ecp.pem openssl genpkey -paramfile ecp.pem Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
EC private key generation problem
Hi, On windows 7 with OpenSSL 1.0.1e, I get the following output: $ openssl.exe genpkey -out priv.pem -aes128 -algorithm EC -pkeyopt ec_paramgen_curve:secp224r1 parameter setting error 3512:error:06089094:digital envelope routines:EVP_PKEY_CTX_ctrl:invalid operation:.\crypto\evp\pmeth_lib.c:404 Is this a bug? what's the correct commandline? Note: I sent this before and after subscription. Sorry if multiple copies have arrived..
