Dear OpenSSL Team,
While migrating to OpenSSL 3.0 we are facing issue with use of
DH_generate_key(). Getting dh->pub_key NULL.
Logic used is as given below, I have omitted the error handling code.
* p and g buffer is of type unsigned char *
* p_len is 128 and g_len i
b_key/ priv_key) from the DH_generate_key() with
> single values of dh->p/ dh->g.
>
> But now in 3.0 equivalent, I guess we can get only one key from the p/g
> params right ? how to get equivalent pub_key / priv_key ? please suggest.
An EVP_PKEY can hold either a priv/public
Hi Matt,
Thanks for the code sample. we understood the end to end flow
to generate the DH key.
I wanted to understand one more aspect here, In our application we were
obtaining two keys (pub_key/ priv_key) from the DH_generate_key() with single
values of dh->p/ dh->g.
B
On 09/12/2020 15:31, Matt Caswell wrote:
>> our application creates a new DH and using DH_generate_key()
>
> How do you set up the DH parameters? Do you load them from a file or
> generate them in your application? Or some other way? Will it break your
> application if
On 08/12/2020 17:43, Narayana, Sunil Kumar wrote:
> Dear openssl team,
>
>
>
> While migrating from 1.0.2 to 3.0, we found that
> DH_generate_key() has be deprecated. And as per the man page, it is
> advised to use EVP_PKEY_derive_init
> <h
to decrypt TLS session from PCAP files
(Matt Caswell)
2. Re: Use OpenSSL to decrypt TLS session from PCAP files
(John Baldwin)
3. DH_generate_key (Narayana, Sunil Kumar)
4. RE: DH_generate_key (Sands, Daniel)
--
Message: 1
Date:
Dear openssl team,
While migrating from 1.0.2 to 3.0, we found that
DH_generate_key() has be deprecated. And as per the man page, it is advised to
use
EVP_PKEY_derive_init<https://www.openssl.org/docs/manmaster/man3/EVP_PKEY_derive_init.html>
&
EVP_PKEY_de
Dear openssl team,
While migrating from 1.0.2 to 3.0, we found that
DH_generate_key() has be deprecated. And as per the man page, it is advised to
use
EVP_PKEY_derive_init<https://www.openssl.org/docs/manmaster/man3/EVP_PKEY_derive_init.html>
&
EVP_PKEY_de
1.0.2 and 1.1.0, whatever the highest letter is, are the supported releases.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Hi Salz,
I have built the 1.1.0f with vc10 ( have to move some header files)
Is the OpenSSL 1.1.0f supported version ?
Thanks
Jason
On Thu, Oct 5, 2017 at 3:31 PM, Salz, Rich wrote:
>
>- Compared code of RAND_poll(void) between 1.0.1 and 1.0.2 and it
>seems no change
>
>
Hi Jeff,
Checked https://rt.openssl.org/Ticket/Display.html?id=2100&user=
guest&pass=guest
and it seems exactly the same issue I have. I have moved to 1.0.1c.
One question is where can I find the patch ? I have the built
environment and I can build myself.
Thanks for the help
Jason
On T
Thanks,
On Fri, Oct 6, 2017 at 9:36 AM, Salz, Rich wrote:
> Okay, you seem to be looking for an answer and there isn’t one.
>
>
>
> The release you are using has problems when it decided to walk the heap.
> The release you are using WILL NOT BE FIXED.
>
>
>
> Change your code, backport the fix,
Okay, you seem to be looking for an answer and there isn’t one.
The release you are using has problems when it decided to walk the heap. The
release you are using WILL NOT BE FIXED.
Change your code, backport the fix, or move to a more modern release. Sorry,
there is no other way.
--
opens
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
> Jason Qian via openssl-users
> Sent: Friday, October 06, 2017 07:14
> The challenge is that, we are not directly calling RAND_poll(). We just call
> DH_generate_key for DH key.
> From the fol
Thanks Jeff,
The challenge is that, we are not directly calling RAND_poll(). We just
call *DH_generate_key* for DH key.
>From the following call stacks, you can see the RAND_poll() is triggered by
ssleay_rand_bytes.
libeay32d.dll!*RAND_poll*() Line 572 C
libeay32d.dll!ssleay_rand_by
>> You should avoid calls to RAND_poll altogether on Windows. Do so by
>> explicitly seeding the random number generator yourself.
>
> As a starting point, try something like this:
>
> -
> static ENGINE *rdrand;
>
> void init_prng(void) {
> /* Try to seed the PRNG with the Intel RDRAND on-c
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
> Of Jeffrey Walton
> Sent: Thursday, October 05, 2017 13:33
> To: Jason Qian; OpenSSL Users
> Subject: Re: [openssl-users] DH_generate_key Hangs
>
>
> You should avoid calls to RAND_poll altoget
More :
The call stacks are from 1.0.1c when calling DH_generate_key.
Is any fix in the latest version for this ?
Thanks
Jason
On Thu, Oct 5, 2017 at 3:53 PM, Jason Qian wrote:
> We call DH_generate_key(DH *dh) and the RAND_poll() is called
> ssleay_rand_bytes
>
>
>
We call DH_generate_key(DH *dh) and the RAND_poll() is called
ssleay_rand_bytes
libeay32d.dll!RAND_poll() Line 572 C
libeay32d.dll!ssleay_rand_bytes(unsigned char * buf=0x03318fe0, int
num=128, int pseudo=0) Line 395 C
libeay32d.dll!ssleay_rand_nopseudo_bytes(unsigned char * buf
On Thu, Oct 5, 2017 at 3:27 PM, Jason Qian via openssl-users
wrote:
> Compared code of RAND_poll(void) between 1.0.1 and 1.0.2 and it seems no
> change
I believe it was fixed earlier than that. Also see
https://rt.openssl.org/Ticket/Display.html?id=2100&user=guest&pass=guest
As Michael suggested
On Thu, Oct 5, 2017 at 2:55 PM, Jason Qian via openssl-users
wrote:
> Thanks Michael,
>
> I saw a lot of discussion for this issue on,
>
>https://mta.openssl.org/pipermail/openssl-dev/2015-July/002210.html
>
> Not sure if openSSL has a workaround or a patch ?
>
>
> It hangs on
* Compared code of RAND_poll(void) between 1.0.1 and 1.0.2 and it seems no
change
Sorry, then try 1.1.0 The HEAPWALK bug/issue is fixed there.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Compared code of RAND_poll(void) between 1.0.1 and 1.0.2 and it seems no
change
Thanks
On Thu, Oct 5, 2017 at 2:59 PM, Salz, Rich wrote:
> You could try to backport the win_rand file from a more recent release.
>
>
>
> Far better, as Michael first said, to move to 1.0.2 or later.
>
>
>
>
>
--
You could try to backport the win_rand file from a more recent release.
Far better, as Michael first said, to move to 1.0.2 or later.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
gt; *Sent:* Thursday, October 05, 2017 08:44
> *To:* Michael Wojcik
> *Cc:* openssl-users@openssl.org
> *Subject:* Re: [openssl-users] DH_generate_key Hangs
>
>
>
>
>
> Here is the stack trace :
>
>
>
> libeay32.dll!RAND_poll Normal
>
> [External Code]
rom: Jason Qian [mailto:jq...@tibco.com]
Sent: Thursday, October 05, 2017 08:44
To: Michael Wojcik
Cc: openssl-users@openssl.org
Subject: Re: [openssl-users] DH_generate_key Hangs
Here is the stack trace :
libeay32.dll!RAND_poll Normal
[External Code]
libeay32.dll!RAND_poll() Line 523
li
l.org
> > Subject: [openssl-users] DH_generate_key Hangs
>
> > Need some help, one of our application that hangs when calling
> > DH_generate_key (openssl-0.9.8y). This occurs randomly under loaded
> condition.
> > Not sure, if anyone know this issue ?
>
> The iss
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
> Jason Qian via openssl-users
> Sent: Wednesday, September 27, 2017 07:00
> To: openssl-users@openssl.org
> Subject: [openssl-users] DH_generate_key Hangs
> Need some help, one of our applicati
Hi,
Need some help, one of our application that hangs when calling
DH_generate_key (openssl-0.9.8y). This occurs randomly under loaded
condition.
Not sure, if anyone know this issue ?
Thanks
Jason
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl
Oh! what a miss!! Signs of excessive pressure!!! When I divide the program in
multiple files, I create one of the functions like this-
char *dh_sender_pub(DH *dhPar)
{
char *pubinHex=NULL;
DH_generate_key(dhPar);
pubinHex=BN_bn2hex(dhPar->pub_key);
return pubinHex;
}
An
Ø These built-in functions do not return the size of the binary data, so how
can I get the length of the binary data?
BN_num_bytes() which you already used in your initial posting?
--
Principal Security Engineer
Akamai Technology
Cambridge, MA
These built-in functions do not return the size of the binary data, so how can
I get the length of the binary data? I need the length in some other parts of
my program. Do I need to convert them to Hex everytime to get the length? Or is
there any direct method to get the length? I want to use di
As two other people have already said, you cannot use strlen() on binary data.
> >BN_bin2bn(parmp,strlen(parmp), dhPar2->p);
> >BN_bin2bn(parmg,strlen(parmg), dhPar2->g);
/r$
--
Principal Security Engineer
Akamai Technology
Cambridge, MA
to debug.
> You have not said what version of openssl you are running, so I have
> checked the standard default behaviour of Openssl 1.0.1f. DH_new does
I'm pretty sure this area hasn't changed in a long time.
> not allocate the BIGNUMs for p and g. They are set to NULL.
have not said what version of openssl you are running, so I have
> checked the standard default behaviour of Openssl 1.0.1f. DH_new does
I'm pretty sure this area hasn't changed in a long time.
> not allocate the BIGNUMs for p and g. They are set to NULL. The call
> to BN_bin2bn wil
aid what version of openssl you are running, so I have
checked the standard default behaviour of Openssl 1.0.1f. DH_new does
not allocate the BIGNUMs for p and g. They are set to NULL. The call
to BN_bin2bn will check the value of its 3rd argument. If it is null
it will allocate a BIGNUM and return i
armp), dhPar2->p);
BN_bin2bn(parmg,strlen(parmg), dhPar2->g);
DH_generate_key(dhPar);
DH_generate_key(dhPar2);
printf("Generate shared key in both \n");
dhSec1 = OPENSSL_malloc(sizeof(unsigned char) * DH_size(dhPar));
dhSec2 = OPENSSL_ma
Hello,
DH_generate_key and DH_compute_key seems to take lot of CPU for key and
secret generation respectively.
I think this is the most CPU intensive task in all of the IKEV2 exchanges.
Is there some way to optimize the same, particularly secret computation.
Regards,
Prashant
> From: owner-openssl-us...@openssl.org On Behalf Of ikuzar
> Sent: Thursday, 07 April, 2011 08:31
> I'd like to know if DH_compute_key( ) runs faster than
> DH_generate_key( ). DH_generate_key generate x and g^x,
> in my case ( x was not set when
Hello,
I'd like to know if DH_compute_key( ) runs faster than DH_generate_key( ).
DH_generate_key generate x and g^x, in my case ( x was not set when I call
this function ).
I only made measure for DH_generate_key and have got 0.00 ms ( CPU Intel
Core i7-740QM, 1.73Ghz / 6GB of memory ).
: Wednesday, March 02, 2011 6:53 AM
To: openssl-users@openssl.org
Subject: DH_generate_key issue
Hello, guys! I'm new to OpenSSL so sorry in advance if I get something wrong.
I'm using OpenSSL Diffie-Hellman key exchange in my project. In 'normal' mode
it works just perfect, but dur
);
RAND_bytes(random_bytes, 256/8);
tmp_ctx->priv_key = BN_bin2bn(random_bytes, 256/8, NULL);
ssl_res = DH_generate_key(tmp_ctx);
ck_assert_int_eq(1, ssl_res);
unsigned pub_key_size = BN_num_bytes(tmp_ctx->pub_key);
Hi All,
I was using DH_generate_key yo generate a shared key and it works well. I
had a question regarding the implementation of DH_generate_key. In my
project, I cannot link to any of the default C libraries etc., so when I do
DH_generate_key in my project it doesnt work, does it use some I/O
Koza wrote:
>
> I try to measure time of generating a key for DH. I have a code alike:
> startclk = clock();
> for (i=0;i DH_generate_key(a);
> stopclk = clock();
>
I know the anser now, it was my fault since not DH_generate_key tak
advance!!
Best regards,
Koza
--
View this message in context:
http://www.nabble.com/strange-behaviour-of-clock%28%29-with-DH_generate_key-tf4930945.html#a14113620
Sent from the OpenSSL - User mailing list archive at Nabble.com.
__
On 4/2/05 12:51 AM, "Nils Larsch" <[EMAIL PROTECTED]> wrote:
> ... BN_bin2bn should correctly handle leading zeros in binary input
Okay, great. Thanks for all the help.
__
OpenSSL Project http://
Bob Bradley wrote:
On 4/1/05 8:20 AM, "Nils Larsch" <[EMAIL PROTECTED]> wrote:
this of course reduces the key space for the private key, but if you
really need a fixed size public key you need to do it.
Would it reduce security or be unsafe to simply prepend zero bytes after
calling BN_bn2bin to
On 4/1/05 8:20 AM, "Nils Larsch" <[EMAIL PROTECTED]> wrote:
> this of course reduces the key space for the private key, but if you
> really need a fixed size public key you need to do it.
Would it reduce security or be unsafe to simply prepend zero bytes after
calling BN_bn2bin to make it fill 12
ize that. Thanks for the explanation.
Is it safe to BN_clear_free() and NULL out the pub_key and priv_key fields
of the DH structure and call DH_generate_key again until it generates a
128-byte key?
this of course reduces the key space for the private key, but if you
really need a fixed size publ
that. Thanks for the explanation.
Is it safe to BN_clear_free() and NULL out the pub_key and priv_key fields
of the DH structure and call DH_generate_key again until it generates a
128-byte key?
__
OpenSSL Project
Bob Bradley wrote:
I'm seeing DH_generate_key generate a public key that is 1 byte less than
expected (127 instead of 128 bytes for a 1024-bit key), but only
sporadically (about every 200-300 tries). I've written the following test
case that always fails for me in less than 300 iterat
I'm seeing DH_generate_key generate a public key that is 1 byte less than
expected (127 instead of 128 bytes for a 1024-bit key), but only
sporadically (about every 200-300 tries). I've written the following test
case that always fails for me in less than 300 iterations. I've only
build|install]kernel).
The error generated on the server is:
sshd: fatal: DH_generate_key (or something very similiar)
This error message existed before the recompile.
Looking through the sources I find the DH_generate_key stuff located
in the openssl hierarchy.
The machine is a Compaq Pro
Here is one problem. The value coming out of DH_generate_key() is mod p.
This induces the high-order bit to more likely to be a zero than a one. In
an extreme case, if p is a prime of the form 1 + 2^n, then the high-order
bit is almost certainly a zero. If this bit is one of the bits you use to
I do not think this is a bug. On average with truly random exponents, you
would expect that about 1/2 of the time the result of DH_generate_key() is
less than 1/2 of the modulus, 1/4 of the time it is less than 1/4 of the
modulus, ..., 2^-n of the time it is less than 2^-n * modulus. So if your
ug where if the DH parameters in the cert are null pointers
it'll call DH_generate_key(), but if that call fails it'll go ahead and try
to dereference the null pointers anyway (causing a core dump).
This patch fixes both bugs. With this change and appropriate tweaks in Tim's
SS
56 matches
Mail list logo
