date:20171122

[openssl-users] ssl3_get_client_hello:no shared cipher

2017-11-22 Thread kavita jindal

Hi All,

I am using free radius 3.0.15  ,while using i am getting following error
I searched the forums ,some people have already raised the issue but i
could not find any solution.

 eap_tls: (other): before/accept initialization
(1) eap_tls: TLS_accept: before/accept initialization
(1) eap_tls: <<< recv TLS 1.2  [length 0042]
(1) eap_tls: >>> send TLS 1.2  [length 0002]
(1) eap_tls: ERROR: TLS Alert write:fatal:handshake failure
tls: TLS_accept: Error in error
tls: TLS_accept: Error in error
(1) eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1408A0C1:SSL
routines:ssl3_get_client_hello:no shared cipher
(1) eap_tls: ERROR: System call (I/O) error (-1)
(1) eap_tls: ERROR: TLS receive handshake failed during operation
(1) eap_tls: ERROR: [eaptls process] = fail
(1) eap: ERROR: Failed continuing EAP TLS (13) session.  EAP sub-module
failed
(1) eap: Sending EAP Failure (code 4) ID 96 length 4

Also when i use ,its shows my ciphersuite :

openssl ciphers 'ALL'  | grep ECDHE-ECDSA-AES128-GCM-SHA256

Regards
Kavita
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Non const input for EVP_EncryptUpdate and EVP_DecryptUpdate

2017-11-22 Thread Edward Diener


On 11/22/2017 10:46 AM, Matt Caswell wrote:

This is a bug in the docs. In the header files they are declared as const:

int EVP_EncryptUpdate(EVP_CIPHER_CTX *ctx, unsigned char *out, int *outl,
   const unsigned char *in, int inl);

int EVP_DecryptUpdate(EVP_CIPHER_CTX *ctx, unsigned char *out, int *outl,
   const unsigned char *in, int inl);

Please file a bug report!


I filed an issue. It is now the 333th open issue. Thanks for the 
information. I guess I should have looked myself.




https://github.com/openssl/openssl/issues

Matt


On 22/11/17 14:42, Edward Diener wrote:

When calling EVP_EncryptUpdate with some plaintext to be encrypted the
parameter for the plaintext is a pointer to a non-const array of
unsigned char, as in the function prototype:

int EVP_EncryptUpdate(EVP_CIPHER_CTX *ctx, unsigned char *out,
  int *outl, unsigned char *in, int inl);

Similarly when calling EVP_DecryptUpdate with some ciphertext to be
decrypted the parameter for the ciphertext is a pointer to a non-const
array of unsigned char, as in the function prototype:

int EVP_DecryptUpdate(EVP_CIPHER_CTX *ctx, unsigned char *out,
  int *outl, unsigned char *in, int inl);

I have taken both these function prototypes from the OpenSSL
documentation at
https://wiki.openssl.org/index.php/Manual:EVP_EncryptInit(3).

Does this mean that the input array in both cases actually is modified
in any way by the functions ? Or is this just an error in that if the
input remains unmodified the functions do not specify the parameter as
'const unsigned char * in' instead ?





--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Non const input for EVP_EncryptUpdate and EVP_DecryptUpdate

2017-11-22 Thread Matt Caswell

This is a bug in the docs. In the header files they are declared as const:

int EVP_EncryptUpdate(EVP_CIPHER_CTX *ctx, unsigned char *out, int *outl,
  const unsigned char *in, int inl);

int EVP_DecryptUpdate(EVP_CIPHER_CTX *ctx, unsigned char *out, int *outl,
  const unsigned char *in, int inl);

Please file a bug report!

https://github.com/openssl/openssl/issues

Matt


On 22/11/17 14:42, Edward Diener wrote:
> When calling EVP_EncryptUpdate with some plaintext to be encrypted the
> parameter for the plaintext is a pointer to a non-const array of
> unsigned char, as in the function prototype:
> 
> int EVP_EncryptUpdate(EVP_CIPHER_CTX *ctx, unsigned char *out,
>  int *outl, unsigned char *in, int inl);
> 
> Similarly when calling EVP_DecryptUpdate with some ciphertext to be
> decrypted the parameter for the ciphertext is a pointer to a non-const
> array of unsigned char, as in the function prototype:
> 
> int EVP_DecryptUpdate(EVP_CIPHER_CTX *ctx, unsigned char *out,
>  int *outl, unsigned char *in, int inl);
> 
> I have taken both these function prototypes from the OpenSSL
> documentation at
> https://wiki.openssl.org/index.php/Manual:EVP_EncryptInit(3).
> 
> Does this mean that the input array in both cases actually is modified
> in any way by the functions ? Or is this just an error in that if the
> input remains unmodified the functions do not specify the parameter as
> 'const unsigned char * in' instead ?
> 
> 
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Non const input for EVP_EncryptUpdate and EVP_DecryptUpdate

2017-11-22 Thread Edward Diener

When calling EVP_EncryptUpdate with some plaintext to be encrypted the 
parameter for the plaintext is a pointer to a non-const array of 
unsigned char, as in the function prototype:


int EVP_EncryptUpdate(EVP_CIPHER_CTX *ctx, unsigned char *out,
 int *outl, unsigned char *in, int inl);

Similarly when calling EVP_DecryptUpdate with some ciphertext to be 
decrypted the parameter for the ciphertext is a pointer to a non-const 
array of unsigned char, as in the function prototype:


int EVP_DecryptUpdate(EVP_CIPHER_CTX *ctx, unsigned char *out,
 int *outl, unsigned char *in, int inl);

I have taken both these function prototypes from the OpenSSL 
documentation at

https://wiki.openssl.org/index.php/Manual:EVP_EncryptInit(3).

Does this mean that the input array in both cases actually is modified 
in any way by the functions ? Or is this just an error in that if the 
input remains unmodified the functions do not specify the parameter as 
'const unsigned char * in' instead ?



--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Example code to add several CRL distribution points

2017-11-22 Thread Dave Coombs

Hi,

You can use X509V3_EXT_i2d(NID_crl_distribution_points, critical, sk) where sk 
is a STACK_OF(DIST_POINT) that you have previously filled with multiple URIs.

Cheers,
  -Dave


> On Nov 22, 2017, at 06:58, Dirk Menstermann  wrote:
> Hi,
> 
> can anybody share example code to add more than 1 CRL distribution point to a
> certificate?
> 
> The below works only for one URI:
> 
> X509_EXTENSION *ext = X509V3_EXT_conf_nid (NULL, ,
> NID_crl_distribution_points, (char*) "URI:http://exmaple.com/crl;);
> X509_add_ext (certificate, ext, -1);
> 
> Thanks a lot
> Dirk
> -- 
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Apparent Memory Leak When Executing EVP_PKEY_derive (MS vc14, 32 bit, OpenSSL 1.0.2h/m)

2017-11-22 Thread yahiaelsawiabd1974


Thanks for emailing me! No, I haven’t been hacked :)

I signed up for a spam filtering service called BitBounce. To deliver your 
email to my inbox, please click the link below. Thanks!

https://bitbounce.com/pay_bitbounce_fee/1808859525

BitBounce is a product by:

Turing Cloud
Turing-Cloud.com/bitbounce
Redwood City, CA


BitBounce integrates with:

CoinBase
CoinBase.com
San Francisco, CA
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Example code to add several CRL distribution points

2017-11-22 Thread Dirk Menstermann

Hi,

can anybody share example code to add more than 1 CRL distribution point to a
certificate?

The below works only for one URI:

X509_EXTENSION *ext = X509V3_EXT_conf_nid (NULL, ,
NID_crl_distribution_points, (char*) "URI:http://exmaple.com/crl;);
X509_add_ext (certificate, ext, -1);

Thanks a lot
Dirk
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Apparent Memory Leak When Executing EVP_PKEY_derive (MS vc14, 32 bit, OpenSSL 1.0.2h/m)

2017-11-22 Thread Seiberlich, Holger via openssl-users

Hi Matt:

Thank you very much for your answer! I did what you told me, and there's no 
longer an indication of a memory leak.

Sincerely,
Holger 

-Ursprüngliche Nachricht-
Von: Matt Caswell [mailto:m...@openssl.org] 
Gesendet: Mittwoch, 22. November 2017 11:50
An: Seiberlich, Holger; openssl-users@openssl.org
Betreff: Re: [openssl-users] Apparent Memory Leak When Executing 
EVP_PKEY_derive (MS vc14, 32 bit, OpenSSL 1.0.2h/m)

Before you close your application down try calling:

CRYPTO_cleanup_all_ex_data()

See:
https://wiki.openssl.org/index.php/Library_Initialization#Cleanup

The whole dance around init/de-init of the library becomes a whole lot easier 
in 1.1.0 (it should all happen automatically) - but in 1.0.2 you have to call 
several functions to properly de-initialise the library.

Matt

On 22/11/17 10:19, Seiberlich, Holger via openssl-users wrote:
> Dear OpenSSL community,
> 
> in a C++ (vc14, OpenSSL 1.0.2h/m) project, I'm trying to negotiate a 
> secret between two parties, using EC crypto. I've used 
> https://wiki.openssl.org/index.php/EVP_Key_Agreement
> as a recipe and wrapped memory allocations into unique_ptrs. The code 
> fulfills its purpose of deriving a shared secret, but memory leak detection 
> with
>   _CrtSetDbgFlag( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );
>   _CrtSetReportMode( _CRT_WARN, _CRTDBG_MODE_FILE );
>   _CrtSetReportFile( _CRT_WARN, _CRTDBG_FILE_STDOUT ); produces a 
> warning:
>   Detected memory leaks!
>   Dumping objects ->
>   {10316} normal block at 0x00307680, 12 bytes long.
>Data: < v0 > F0 76 30 00 00 00 00 00 0D 00 00 00
>   {10315} normal block at 0x00351068, 16 bytes long.
>Data: <> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
> 00
>   {10314} normal block at 0x00350F68, 20 bytes long.
>Data:  00 00 00 00 68 10 35 00 00 00 00 00 04 00 00 
> 00
>   {10313} normal block at 0x003076F0, 12 bytes long.
>Data:  0D 00 00 00 68 0F 35 00 00 00 00 00
>   {10312} normal block at 0x00310A70, 64 bytes long.
>Data: <> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
> 00
>   {10311} normal block at 0x00309E98, 96 bytes long.
>Data:  70 0A 31 00 90 41 20 0F A0 0D 27 0F 08 00 00 
> 00
>   Object dump complete.
> 
> Let me note two things:
> - The line without which the memory leak disappears is the line triggering 
> the actual secret derivation:
>   if(EVP_PKEY_derive(ctx.get(), skey.get(), ) <= 0)
> - The size of the leak is independent of how often I run the procedure of 
> generating two sets of keys and then calling DeriveSecret().
> 
> ***
> Therefore, I'm wondering whether I've missed a call to free that I must 
> trigger to deallocate this memory.
> ***
> 
> I have added an allocation hook to check, as an example, when the 96-byte 
> allocation occurs:
> 
>   [Name]  [Language]
>   libeay32.dll!default_malloc_ex(unsigned int num, const char * file, int 
> line) Line 79   C
>   libeay32.dll!CRYPTO_malloc(int num, const char * file, int line) Line 
> 342   C
>   libeay32.dll!lh_new(unsigned long(*)(const void *) h, int(*)(const void 
> *, const void *) c) Line 120C
>   libeay32.dll!ex_data_check() Line 279   C
>   libeay32.dll!def_get_class(int class_index) Line 316C
>   libeay32.dll!int_new_ex_data(int class_index, void * obj, 
> crypto_ex_data_st * ad) Line 421  C
>   libeay32.dll!CRYPTO_new_ex_data(int class_index, void * obj, 
> crypto_ex_data_st * ad) Line 583   C
>   libeay32.dll!ECDH_DATA_new_method(engine_st * engine) Line 165  C
>   libeay32.dll!ecdh_data_new() Line 178   C
>   libeay32.dll!ecdh_check(ec_key_st * key) Line 215   C
>   libeay32.dll!ECDH_compute_key(void * out, unsigned int outlen, const 
> ec_point_st * pub_key, ec_key_st * eckey, void *(*)(const void *, unsigned 
> int, void *, unsigned int *) KDF) Line 77   C
>   libeay32.dll!pkey_ec_derive(evp_pkey_ctx_st * ctx, unsigned char * key, 
> unsigned int * keylen) Line 237 C
>   libeay32.dll!pkey_ec_kdf_derive(evp_pkey_ctx_st * ctx, unsigned char * 
> key, unsigned int * keylen) Line 252 C
>   libeay32.dll!EVP_PKEY_derive(evp_pkey_ctx_st * ctx, unsigned char * 
> key, unsigned int * pkeylen) Line 345   C
>   [.]DeriveSecret() Line 802  C++
> 
> Please see below for how I call EVP_PKEY_derive. Can you tell me what I'm 
> missing? Do you need more info?
> 
> Thank you for looking into this and helping!
> 
> Regards,
> Holger
> 
> 
> template using deleted_unique_ptr = 
> std::unique_ptr>;
>   
> deleted_unique_ptr m_pOwnKey; deleted_unique_ptr 
> m_pPeerKey;
> 
> void [...]::DeriveSecret()
> {
>   if (!(m_pOwnKey && m_pOwnKey->pkey.ec))
>   {
> throw KeyUninitializedError("Secret cannot be derived if own key is 
> missing");
>   }
>   if (!m_pPeerKey)
>

Re: [openssl-users] Apparent Memory Leak When Executing EVP_PKEY_derive (MS vc14, 32 bit, OpenSSL 1.0.2h/m)

2017-11-22 Thread Matt Caswell

Before you close your application down try calling:

CRYPTO_cleanup_all_ex_data()

See:
https://wiki.openssl.org/index.php/Library_Initialization#Cleanup

The whole dance around init/de-init of the library becomes a whole lot
easier in 1.1.0 (it should all happen automatically) - but in 1.0.2 you
have to call several functions to properly de-initialise the library.

Matt

On 22/11/17 10:19, Seiberlich, Holger via openssl-users wrote:
> Dear OpenSSL community,
> 
> in a C++ (vc14, OpenSSL 1.0.2h/m) project, I'm trying to negotiate a secret 
> between two parties, using EC crypto. I've used
> https://wiki.openssl.org/index.php/EVP_Key_Agreement
> as a recipe and wrapped memory allocations into unique_ptrs. The code 
> fulfills its purpose of deriving a shared secret, but memory leak detection 
> with
>   _CrtSetDbgFlag( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );
>   _CrtSetReportMode( _CRT_WARN, _CRTDBG_MODE_FILE );
>   _CrtSetReportFile( _CRT_WARN, _CRTDBG_FILE_STDOUT );
> produces a warning:
>   Detected memory leaks!
>   Dumping objects ->
>   {10316} normal block at 0x00307680, 12 bytes long.
>Data: < v0 > F0 76 30 00 00 00 00 00 0D 00 00 00
>   {10315} normal block at 0x00351068, 16 bytes long.
>Data: <> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
> 00
>   {10314} normal block at 0x00350F68, 20 bytes long.
>Data:  00 00 00 00 68 10 35 00 00 00 00 00 04 00 00 
> 00
>   {10313} normal block at 0x003076F0, 12 bytes long.
>Data:  0D 00 00 00 68 0F 35 00 00 00 00 00
>   {10312} normal block at 0x00310A70, 64 bytes long.
>Data: <> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
> 00
>   {10311} normal block at 0x00309E98, 96 bytes long.
>Data:  70 0A 31 00 90 41 20 0F A0 0D 27 0F 08 00 00 
> 00
>   Object dump complete.
> 
> Let me note two things:
> - The line without which the memory leak disappears is the line triggering 
> the actual secret derivation:
>   if(EVP_PKEY_derive(ctx.get(), skey.get(), ) <= 0)
> - The size of the leak is independent of how often I run the procedure of 
> generating two sets of keys and then calling DeriveSecret().
> 
> ***
> Therefore, I'm wondering whether I've missed a call to free that I must 
> trigger to deallocate this memory.
> ***
> 
> I have added an allocation hook to check, as an example, when the 96-byte 
> allocation occurs:
> 
>   [Name]  [Language]
>   libeay32.dll!default_malloc_ex(unsigned int num, const char * file, int 
> line) Line 79   C
>   libeay32.dll!CRYPTO_malloc(int num, const char * file, int line) Line 
> 342   C
>   libeay32.dll!lh_new(unsigned long(*)(const void *) h, int(*)(const void 
> *, const void *) c) Line 120C
>   libeay32.dll!ex_data_check() Line 279   C
>   libeay32.dll!def_get_class(int class_index) Line 316C
>   libeay32.dll!int_new_ex_data(int class_index, void * obj, 
> crypto_ex_data_st * ad) Line 421  C
>   libeay32.dll!CRYPTO_new_ex_data(int class_index, void * obj, 
> crypto_ex_data_st * ad) Line 583   C
>   libeay32.dll!ECDH_DATA_new_method(engine_st * engine) Line 165  C
>   libeay32.dll!ecdh_data_new() Line 178   C
>   libeay32.dll!ecdh_check(ec_key_st * key) Line 215   C
>   libeay32.dll!ECDH_compute_key(void * out, unsigned int outlen, const 
> ec_point_st * pub_key, ec_key_st * eckey, void *(*)(const void *, unsigned 
> int, void *, unsigned int *) KDF) Line 77   C
>   libeay32.dll!pkey_ec_derive(evp_pkey_ctx_st * ctx, unsigned char * key, 
> unsigned int * keylen) Line 237 C
>   libeay32.dll!pkey_ec_kdf_derive(evp_pkey_ctx_st * ctx, unsigned char * 
> key, unsigned int * keylen) Line 252 C
>   libeay32.dll!EVP_PKEY_derive(evp_pkey_ctx_st * ctx, unsigned char * 
> key, unsigned int * pkeylen) Line 345   C
>   [.]DeriveSecret() Line 802  C++
> 
> Please see below for how I call EVP_PKEY_derive. Can you tell me what I'm 
> missing? Do you need more info?
> 
> Thank you for looking into this and helping!
> 
> Regards,
> Holger
> 
> 
> template using deleted_unique_ptr = 
> std::unique_ptr>;
>   
> deleted_unique_ptr m_pOwnKey;
> deleted_unique_ptr m_pPeerKey;
> 
> void [...]::DeriveSecret()
> {
>   if (!(m_pOwnKey && m_pOwnKey->pkey.ec))
>   {
> throw KeyUninitializedError("Secret cannot be derived if own key is 
> missing");
>   }
>   if (!m_pPeerKey)
>   {
> throw KeyUninitializedError("Secret cannot be derived if peer key is 
> missing");
>   }
>   
>   deleted_unique_ptr ctx(EVP_PKEY_CTX_new(m_pOwnKey.get(), 
> NULL), [](EVP_PKEY_CTX* obj)
>   {
> EVP_PKEY_CTX_free(obj);
>   });
> 
>   size_t skeylen;
>   if(!ctx)
>   {
> /* Error occurred */
> throw OpenSslError("Error creating EVP_PKEY_CTX");
>   }
>   if(EVP_PKEY_derive_init(ctx.get()) <= 0)
>   {
> /* Error */
>

Re: [openssl-users] Apparent Memory Leak When Executing EVP_PKEY_derive (MS vc14, 32 bit, OpenSSL 1.0.2h/m)

2017-11-22 Thread yahiaelsawiabd1974


Thanks for emailing me! No, I haven’t been hacked :)

I signed up for a spam filtering service called BitBounce. To deliver your 
email to my inbox, please click the link below. Thanks!

https://bitbounce.com/pay_bitbounce_fee/4093641092

BitBounce is a product by:

Turing Cloud
Turing-Cloud.com/bitbounce
Redwood City, CA


BitBounce integrates with:

CoinBase
CoinBase.com
San Francisco, CA
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Apparent Memory Leak When Executing EVP_PKEY_derive (MS vc14, 32 bit, OpenSSL 1.0.2h/m)

2017-11-22 Thread Seiberlich, Holger via openssl-users

Dear OpenSSL community,

in a C++ (vc14, OpenSSL 1.0.2h/m) project, I'm trying to negotiate a secret 
between two parties, using EC crypto. I've used
https://wiki.openssl.org/index.php/EVP_Key_Agreement
as a recipe and wrapped memory allocations into unique_ptrs. The code fulfills 
its purpose of deriving a shared secret, but memory leak detection with
_CrtSetDbgFlag( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );
_CrtSetReportMode( _CRT_WARN, _CRTDBG_MODE_FILE );
_CrtSetReportFile( _CRT_WARN, _CRTDBG_FILE_STDOUT );
produces a warning:
Detected memory leaks!
Dumping objects ->
{10316} normal block at 0x00307680, 12 bytes long.
 Data: < v0 > F0 76 30 00 00 00 00 00 0D 00 00 00
{10315} normal block at 0x00351068, 16 bytes long.
 Data: <> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00
{10314} normal block at 0x00350F68, 20 bytes long.
 Data:  00 00 00 00 68 10 35 00 00 00 00 00 04 00 00 
00
{10313} normal block at 0x003076F0, 12 bytes long.
 Data:  0D 00 00 00 68 0F 35 00 00 00 00 00
{10312} normal block at 0x00310A70, 64 bytes long.
 Data: <> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00
{10311} normal block at 0x00309E98, 96 bytes long.
 Data:  70 0A 31 00 90 41 20 0F A0 0D 27 0F 08 00 00 
00
Object dump complete.

Let me note two things:
- The line without which the memory leak disappears is the line triggering the 
actual secret derivation:
  if(EVP_PKEY_derive(ctx.get(), skey.get(), ) <= 0)
- The size of the leak is independent of how often I run the procedure of 
generating two sets of keys and then calling DeriveSecret().

***
Therefore, I'm wondering whether I've missed a call to free that I must trigger 
to deallocate this memory.
***

I have added an allocation hook to check, as an example, when the 96-byte 
allocation occurs:

[Name]  [Language]
libeay32.dll!default_malloc_ex(unsigned int num, const char * file, int 
line) Line 79   C
libeay32.dll!CRYPTO_malloc(int num, const char * file, int line) Line 
342   C
libeay32.dll!lh_new(unsigned long(*)(const void *) h, int(*)(const void 
*, const void *) c) Line 120C
libeay32.dll!ex_data_check() Line 279   C
libeay32.dll!def_get_class(int class_index) Line 316C
libeay32.dll!int_new_ex_data(int class_index, void * obj, 
crypto_ex_data_st * ad) Line 421  C
libeay32.dll!CRYPTO_new_ex_data(int class_index, void * obj, 
crypto_ex_data_st * ad) Line 583   C
libeay32.dll!ECDH_DATA_new_method(engine_st * engine) Line 165  C
libeay32.dll!ecdh_data_new() Line 178   C
libeay32.dll!ecdh_check(ec_key_st * key) Line 215   C
libeay32.dll!ECDH_compute_key(void * out, unsigned int outlen, const 
ec_point_st * pub_key, ec_key_st * eckey, void *(*)(const void *, unsigned int, 
void *, unsigned int *) KDF) Line 77   C
libeay32.dll!pkey_ec_derive(evp_pkey_ctx_st * ctx, unsigned char * key, 
unsigned int * keylen) Line 237 C
libeay32.dll!pkey_ec_kdf_derive(evp_pkey_ctx_st * ctx, unsigned char * 
key, unsigned int * keylen) Line 252 C
libeay32.dll!EVP_PKEY_derive(evp_pkey_ctx_st * ctx, unsigned char * 
key, unsigned int * pkeylen) Line 345   C
[.]DeriveSecret() Line 802  C++

Please see below for how I call EVP_PKEY_derive. Can you tell me what I'm 
missing? Do you need more info?

Thank you for looking into this and helping!

Regards,
Holger


template using deleted_unique_ptr = 
std::unique_ptr>;
  
deleted_unique_ptr m_pOwnKey;
deleted_unique_ptr m_pPeerKey;

void [...]::DeriveSecret()
{
  if (!(m_pOwnKey && m_pOwnKey->pkey.ec))
  {
throw KeyUninitializedError("Secret cannot be derived if own key is 
missing");
  }
  if (!m_pPeerKey)
  {
throw KeyUninitializedError("Secret cannot be derived if peer key is 
missing");
  }
  
  deleted_unique_ptr ctx(EVP_PKEY_CTX_new(m_pOwnKey.get(), NULL), 
[](EVP_PKEY_CTX* obj)
  {
EVP_PKEY_CTX_free(obj);
  });

  size_t skeylen;
  if(!ctx)
  {
/* Error occurred */
throw OpenSslError("Error creating EVP_PKEY_CTX");
  }
  if(EVP_PKEY_derive_init(ctx.get()) <= 0)
  {
/* Error */
throw OpenSslError("Error in EVP_PKEY_derive_init");
  }
  if(EVP_PKEY_derive_set_peer(ctx.get(), m_pPeerKey.get()) <= 0)
  {
/* Error */
throw OpenSslError("Error setting peer key in key negotiation");
  }
  /* Determine buffer length */
  if(EVP_PKEY_derive(ctx.get(), NULL, ) <= 0)
  {
/* Error */
throw OpenSslError("Error computing length of shared secret");
  }

  if (skeylen != secretSize)
  {
throw OpenSslError("Shared secret has unexpected size");
  }

  deleted_unique_ptr skey((unsigned 
char*)OPENSSL_malloc(skeylen), [](unsigned char* obj)
  {
OPENSSL_free(obj);

[openssl-users] ssl3_get_client_hello:no shared cipher

Re: [openssl-users] Non const input for EVP_EncryptUpdate and EVP_DecryptUpdate

Re: [openssl-users] Non const input for EVP_EncryptUpdate and EVP_DecryptUpdate

[openssl-users] Non const input for EVP_EncryptUpdate and EVP_DecryptUpdate

Re: [openssl-users] Example code to add several CRL distribution points

Re: [openssl-users] Apparent Memory Leak When Executing EVP_PKEY_derive (MS vc14, 32 bit, OpenSSL 1.0.2h/m)

[openssl-users] Example code to add several CRL distribution points

Re: [openssl-users] Apparent Memory Leak When Executing EVP_PKEY_derive (MS vc14, 32 bit, OpenSSL 1.0.2h/m)

Re: [openssl-users] Apparent Memory Leak When Executing EVP_PKEY_derive (MS vc14, 32 bit, OpenSSL 1.0.2h/m)

Re: [openssl-users] Apparent Memory Leak When Executing EVP_PKEY_derive (MS vc14, 32 bit, OpenSSL 1.0.2h/m)

[openssl-users] Apparent Memory Leak When Executing EVP_PKEY_derive (MS vc14, 32 bit, OpenSSL 1.0.2h/m)

11 matches

Site Navigation

Mail list logo

Footer information