From: Narayana, Sunil Kumar
Sent: Thursday, December 17, 2020 8:17 AM
To: Sands, Daniel ; openssl-users@openssl.org
Subject: [EXTERNAL] RE: DH_compute_key () - replacement in 3.0
Hi,
For the equivalent replacement of DH_compute_key in 3.0, we
tried to perform the steps
gctx, sharedSecret, &skeylen)
}
Note - EVP_PKEY_derive -- call fails what is wrong in the steps can you please g
From: Sands, Daniel
Sent: 16 December 2020 05:00
To: Narayana, Sunil Kumar ; openssl-users@openssl.org
Subject: RE: [EXTERNAL] RE: DH_compute_key (
Hi Daniel,
Thanks we will try it out.
One more doubt regarding DH_generate_key, as per earlier suggestion we tried
following changes to replicate the generate key, but we observe that the out
put key is not matching with the one that is obtained by DH_generate_key() of
older ver
a, Sunil Kumar ; openssl-users@openssl.org
Subject: RE: [EXTERNAL] RE: DH_compute_key () - replacement in 3.0
NOTICE: This email was received from an EXTERNAL sender
We do have generated the key using EVP_PKEY_gen as suggested in e
We do have generated the key using EVP_PKEY_gen as suggested in earlier emails,
but since this was a non-ephemeral and we wanted to store the key in "raw"
octet bytes, so we did extracted the whole DH priv/pub key pair out from the
key generated via EVP_PKEY_gen ( using as suggested…
EVP_PKEY
nt: 15 December 2020 05:16
To: Narayana, Sunil Kumar ; openssl-users@openssl.org
Subject: RE: DH_compute_key () - replacement in 3.0
NOTICE: This email was received from an EXTERNAL sender
to exactly replace this we are gene
to exactly replace this we are generating “pubparam_key/priparam_key” using
bn_publicKey/dh->priv_key as below
OSSL_PARAM_BLD *pubparamsbld = NULL, priparamsbld = NULL;
OSSL_PARAM *pubparams = NULL, priparams = NULL;
EVP_PKEY *pubparam_key = NULL, *priparam_key = NULL;
EVP_PKEY_CTX *pubctx =
Thanks Steve. Issue is fixed please ignore my previous email.
--
View this message in context:
http://openssl.6102.n7.nabble.com/DH-compute-key-query-tp13943p48186.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
_
it is BIGNUM->d not DH->d
--
View this message in context:
http://openssl.6102.n7.nabble.com/DH-compute-key-query-tp13943p48184.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
__
OpenSSL Project
Steve,
It is word aligned. I tried different ways to prepend the value in DH->d but
it is not working. When I dump the memory it shows leading zeros but when I
print the same DH->d using BN_print_fp it does not show zeros which is
expected but leading zeros are not increasing the num_bytes (BN_num
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_ke
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 th
Thanks Steve a ton. I think I was missing some basic design understanding.
-Prashant
On Fri, Jul 22, 2011 at 5:08 PM, Dr. Stephen Henson wrote:
> On Thu, Jul 21, 2011, Prashant Batra wrote:
>
> > Hello,
> >
> > I am using DH exchange in ikev2 for generating secret key b/w 2 parties.
> > I am obs
On Thu, Jul 21, 2011, Prashant Batra wrote:
> Hello,
>
> I am using DH exchange in ikev2 for generating secret key b/w 2 parties.
> I am observing some awkward thing,
> in some of the cases, the secret calculated by both the parties is not the
> same, although the input (public key, private key
Bug?? I do not think so.
I was able to get this result when giving it a zero value for the peer
public key. There is nothing cryptographically sensible about a zero public
key, but DH_compute_key() goes ahead and dutifully computes (0)^priv_key mod
p, which really is just 0.
15 matches
Mail list logo
