Help on Diffie Hellman key exchange

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Help on Diffie Hellman key exchange

OpenSSL - User mailing list
Hi
  
   We have an application that does the Diffie Hellman key exchange (OpenSSL/1.1.0f).
   It works fine, but under heavy loaded conditions, sometimes an invalide secret been generated and other side couldn't decrypt the data (the secret seems offset by one).      

   The client side is c++ and the server side is java.

    DH_compute_key(secretKey, bnY, m_DH); 

   Someone in the openssl group also talks about a similar issue, but not sure if have a solution. 

Thanks for your help,
Jason
Reply | Threaded
Open this post in threaded view
|

Re: Help on Diffie Hellman key exchange

Tomas Mraz-2
On Mon, 2019-11-04 at 17:34 -0500, Jason Qian via openssl-users wrote:

> Hi
>  
>    We have an application that does the Diffie Hellman key exchange
> (OpenSSL/1.1.0f).
>    It works fine, but under heavy loaded conditions, sometimes an
> invalide secret been generated and other side couldn't decrypt the
> data (the secret seems offset by one).      
>
>    The client side is c++ and the server side is java.
>
>     DH_compute_key(secretKey, bnY, m_DH);
>
>    Someone in the openssl group also talks about a similar issue, but
> not sure if have a solution.

Could it be a padding issue? I.E. use DH_compute_key_padded() instead.

--
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]


Reply | Threaded
Open this post in threaded view
|

Re: Help on Diffie Hellman key exchange

OpenSSL - User mailing list
Thanks Tomas, 

I will try that.

On Tue, Nov 12, 2019 at 3:14 AM Tomas Mraz <[hidden email]> wrote:
On Mon, 2019-11-04 at 17:34 -0500, Jason Qian via openssl-users wrote:
> Hi
>   
>    We have an application that does the Diffie Hellman key exchange
> (OpenSSL/1.1.0f).
>    It works fine, but under heavy loaded conditions, sometimes an
> invalide secret been generated and other side couldn't decrypt the
> data (the secret seems offset by one).     
>
>    The client side is c++ and the server side is java.
>
>     DH_compute_key(secretKey, bnY, m_DH);
>
>    Someone in the openssl group also talks about a similar issue, but
> not sure if have a solution.

Could it be a padding issue? I.E. use DH_compute_key_padded() instead.

--
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]


Reply | Threaded
Open this post in threaded view
|

Re: Help on Diffie Hellman key exchange

OpenSSL - User mailing list
Hi Tomas,

   Using DH_compute_key_padded() seems fixed the problem.
   
  I have one more question regarding a similar issue but this time is about AES key generation.

 I think the problem is related to  RAND_seed or  RAND_bytes (someone also mentioned on another thread).

    RAND_seed(seed, ::strlen(seed));
    RAND_bytes(buf, keySize / 8);

  What other method do you suggest to use ?

Thanks
Jason


  

  



On Tue, Nov 12, 2019 at 10:50 AM Jason Qian <[hidden email]> wrote:
Thanks Tomas, 

I will try that.

On Tue, Nov 12, 2019 at 3:14 AM Tomas Mraz <[hidden email]> wrote:
On Mon, 2019-11-04 at 17:34 -0500, Jason Qian via openssl-users wrote:
> Hi
>   
>    We have an application that does the Diffie Hellman key exchange
> (OpenSSL/1.1.0f).
>    It works fine, but under heavy loaded conditions, sometimes an
> invalide secret been generated and other side couldn't decrypt the
> data (the secret seems offset by one).     
>
>    The client side is c++ and the server side is java.
>
>     DH_compute_key(secretKey, bnY, m_DH);
>
>    Someone in the openssl group also talks about a similar issue, but
> not sure if have a solution.

Could it be a padding issue? I.E. use DH_compute_key_padded() instead.

--
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]


Reply | Threaded
Open this post in threaded view
|

Re: Help on Diffie Hellman key exchange

Tomas Mraz-2
On Wed, 2019-11-13 at 11:11 -0500, Jason Qian wrote:

> Hi Tomas,
>
>    Using DH_compute_key_padded() seems fixed the problem.
>    
>   I have one more question regarding a similar issue but this time is
> about AES key generation.
>
>  I think the problem is related to  RAND_seed or  RAND_bytes (someone
> also mentioned on another thread).
>
>     RAND_seed(seed, ::strlen(seed));
>     RAND_bytes(buf, keySize / 8);
>

I do not understand what is the problem you have. But nevertheless -
you should not need to call RAND_seed() unless you are running the code
on some very special platform where no method of automatical seeding of
the OpenSSL RNG is available.

Your RAND_bytes() call should be fine to produce an AES key of bit
length keySize.

>
>  
>
>
>
> On Tue, Nov 12, 2019 at 10:50 AM Jason Qian <[hidden email]> wrote:
> > Thanks Tomas,
> >
> > I will try that.
> >
> > On Tue, Nov 12, 2019 at 3:14 AM Tomas Mraz <[hidden email]>
> > wrote:
> > > On Mon, 2019-11-04 at 17:34 -0500, Jason Qian via openssl-users
> > > wrote:
> > > > Hi
> > > >  
> > > >    We have an application that does the Diffie Hellman key
> > > exchange
> > > > (OpenSSL/1.1.0f).
> > > >    It works fine, but under heavy loaded conditions, sometimes
> > > an
> > > > invalide secret been generated and other side couldn't decrypt
> > > the
> > > > data (the secret seems offset by one).      
> > > >
> > > >    The client side is c++ and the server side is java.
> > > >
> > > >     DH_compute_key(secretKey, bnY, m_DH);
> > > >
> > > >    Someone in the openssl group also talks about a similar
> > > issue, but
> > > > not sure if have a solution.
> > >
> > > Could it be a padding issue? I.E. use DH_compute_key_padded()
> > > instead.
> > >
--
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]


Reply | Threaded
Open this post in threaded view
|

Re: Help on Diffie Hellman key exchange

OpenSSL - User mailing list
In reply to this post by OpenSSL - User mailing list

>    RAND_seed(seed, ::strlen(seed));
>    RAND_bytes(buf, keySize / 8);

 

I don’t know where you are getting the seed, but it is typically binary data, not a C string.

 

If you are using 1.1.0 or later, you do not need to seed things.

Reply | Threaded
Open this post in threaded view
|

Re: Help on Diffie Hellman key exchange

Viktor Dukhovni
In reply to this post by Tomas Mraz-2
> On Nov 12, 2019, at 3:14 AM, Tomas Mraz <[hidden email]> wrote:
>
> Could it be a padding issue? I.E. use DH_compute_key_padded() instead.

Do we have an open issue to document DH_compute_key_padded(3)?
It should be documented right next to DH_compute_key(3), with
some words to suggest that the caller needs to know whether
the peer expects a key octet string that is fixed width (same
as "p") or stripped of inessential leading zero octets.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: Help on Diffie Hellman key exchange

OpenSSL - User mailing list
In reply to this post by OpenSSL - User mailing list
Thanks Rich and Tomas,

Here is the code for creating the key (openssl-0.9.8h)

int AESCipher::createKey(unsigned char *buf, int keySize) {
char seed[256];
::sprintf(seed, "%ldXXX_XXX_H__xxxxx_xxxx_xxx_xxxxx_xxxxxxx__INCLUDED_", MiscUtils::generateId());
RAND_seed(seed, ::strlen(seed));

RAND_bytes(buf, keySize / 8);
return keySize / 8;
}

For using 1.1.0, we only need to call RAND_bytes() ?

Jason









On Wed, Nov 13, 2019 at 12:11 PM Salz, Rich <[hidden email]> wrote:

>    RAND_seed(seed, ::strlen(seed));
>    RAND_bytes(buf, keySize / 8);

 

I don’t know where you are getting the seed, but it is typically binary data, not a C string.

 

If you are using 1.1.0 or later, you do not need to seed things.

Reply | Threaded
Open this post in threaded view
|

Re: Help on Diffie Hellman key exchange

OpenSSL - User mailing list

>For using 1.1.0, we only need to call RAND_bytes() ?

 

Yes.  But do check the return value of RAND_bytes.

Reply | Threaded
Open this post in threaded view
|

Re: Help on Diffie Hellman key exchange

Viktor Dukhovni
In reply to this post by OpenSSL - User mailing list
On Wed, Nov 13, 2019 at 12:23:37PM -0500, Jason Qian via openssl-users wrote:

> Here is the code for creating the key (openssl-0.9.8h)

Is this is a new question?  It seems to no longer be related to DH
key agreement.

> int AESCipher::createKey(unsigned char *buf, int keySize) {
> char seed[256];
> ::sprintf(seed, "%ldXXX_XXX_H__xxxxx_xxxx_xxx_xxxxx_xxxxxxx__INCLUDED_",
> MiscUtils::generateId());
> RAND_seed(seed, ::strlen(seed));
>
> RAND_bytes(buf, keySize / 8);
> return keySize / 8;
> }
>
> For using 1.1.0, we only need to call RAND_bytes() ?

If the application running this code has no other sources of entropy,
and the above is the only "random" data stirred into the PRNG, then
you may be generating predictable AES keys in your 0.9.8h code.

It is likely that MiscUtils::generateId() does not generate
cryptographically secure random numbers, and even if it did, the
output is at most 64 bits (%ld), which is not long enough for an
AES key.

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: Help on Diffie Hellman key exchange

OpenSSL - User mailing list
In reply to this post by OpenSSL - User mailing list
Thanks Rich,

On Wed, Nov 13, 2019 at 12:34 PM Salz, Rich <[hidden email]> wrote:

>For using 1.1.0, we only need to call RAND_bytes() ?

 

Yes.  But do check the return value of RAND_bytes.