ECDH- NID_X9_62_prime256v1 - EVP_RAND_generate()

[Damodhar Boddukuri via openssl-users]

Hi,

I am implementing ECDH- Group19 (NID_X9_62_prime256v1). I followed the below 
sequence.

  1.  ecdh_group = EC_GROUP_new_by_curve_name(NID_X9_62_prime256v1); // 
NID_X9_62_prime256v1 or  NID_secp256k1
  2.  ecdh_keys = EC_KEY_new();
  3.  ret = EC_KEY_set_group(ecdh_keys, ecdh_group);
  4.  ret = EC_KEY_generate_key(ecdh_keys);
At 4th step, function EVP_RAND_generate ()  always returning '0'. Because of 
this reason 4th step is failing.

Could you please let me know the possible reasons for it.

Thanks & Regards,
Damodhar.



General

ECDH- NID_X9_62_prime256v1 - EVP_RAND_instantiate()

[Damodhar Boddukuri via openssl-users]

Hi,

I am implementing ECDH- Group19 (NID_X9_62_prime256v1). I followed the below 
sequence.

  1.  ecdh_group = EC_GROUP_new_by_curve_name(NID_X9_62_prime256v1); // 
NID_X9_62_prime256v1 or  NID_secp256k1
  2.  ecdh_keys = EC_KEY_new();
  3.  ret = EC_KEY_set_group(ecdh_keys, ecdh_group);
  4.  ret = EC_KEY_generate_key(ecdh_keys);
At 4th step, function EVP_RAND_instantiate()  returning '1' for the 1st time. 
Then 2nd time onward it's returning '0'. Because of this reason 4th step is 
failing.

Could you please let me know the possible reasons for it.

Thanks & Regards,
Damodhar.



General

Re: Own HW Supported RSA provider

[tomasz bartczak]

Hi Selva,
Thanks for your clear answer.
Regards
Tom
Temat: Re: Own HW Supported RSA provider
Data: 2024-07-20 19:08
Nadawca: "Selva Nair" selva.n...@gmail.com>
Adresat: 
DW: "openssl-users@openssl.org" openssl-users@openssl.org>; 




> 
> On Fri, Jul 19, 2024 at 4:55 PM tomasz bartczak tbar...@poczta.fm> wrote:
> 
>> 
>> If I use the crypto library I can provide desired properties like in 
>> EVP_ASYM_CIPHER_fetch function. However when I use the ssl library, how to 
>> make sure it calls the mentioned EVP_ASYM_CIPHER_fetch function with 
>> properties required by me?
>> 
> 
> You can set a property querywhile creating the SSL context using 
> SSL_CTX_new_ex(). Or set it on the libctx using 
> EVP_set_default_properties().
> 
> That said, what you are trying to do may work with no need for 
> propertyqueries or even with "?provider=default" to prefer "default" 
> when possible. When the private key is loaded using your provider and the key 
> is not exportable, your provider will get called for signature operation.
> 
> See the link below for a test program on how even "?provider=default" in the 
> signing contextfetches the correct signature operation for a key in a 
> different provider. It also has the rudiments of an external key signing 
> provider:
> 
> https://gist.github.com/selvanair/e4fd5fec6316fe894ad0fbaac68f4355
> 
> OR
> 
> https://github.com/openssl/openssl/commit/dd292ed62cc5d3eb0c529aa51a07ec1ed34a9a5f
> 
> Selva
> 

RE: compile openssl for Arm A9 & VxWorks - evp_rand_******_locked() API

[Damodhar Boddukuri via openssl-users]

Hi,

Thanks for your support.

I am porting ECDH Algorithm(Group 19) in to our target. Following are the API 
calls:


  1.  ecdh_group = EC_GROUP_new_by_curve_name(NID_X9_62_prime256v1); // 
NID_X9_62_prime256v1 or  NID_secp256k1


  1.  ecdh_keys = EC_KEY_new();


  1.  ret = EC_KEY_set_group(ecdh_keys, ecdh_group);


  1.  ret = EC_KEY_generate_key(ecdh_keys);

   // Get Private and Public Keys

  1.  const BIGNUM* pri_key = EC_KEY_get0_private_key(ecdh_keys);
  const EC_POINT* pub_key = EC_KEY_get0_public_key(ecdh_keys);


  1.  SharedSecretKey_Len = ECDH_compute_key(SharedSecretKey, 
(EC_GROUP_get_degree(ecdh_group) + 7) / 8, rtvPub_key, ecdh_keys, NULL);

At 4 (I.e. EC_KEY_generate_key), Its invoking API’s like 
evp_rand_instantiate_locked(), evp_rand_generate_locked(), 
evp_rand_resend_locked()…etc

These API’s returning negative response. They are pointing to function 
pointers. How to find them? Do I need to implement Mutex lock here?


Thanks & Regards,
Damodhar.
+91-7702191212



General

From: openssl-users  On Behalf Of Damodhar 
Boddukuri via openssl-users
Sent: Friday, July 26, 2024 5:33 PM
To: Neil Horman 
Cc: openssl-users@openssl.org
Subject: RE: compile openssl for Arm A9 & VxWorks


[External email: Use caution with links and attachments]





Hi,

Thanks for your support.

We are planning to use ECDH Algorithm(Group 19) with a minimal footprint in an 
Embedded System Product for the shared secret key generation.

I have few questions in my mind:

  1.  Is it recommended to use ECDH Algorithm (Group 19) for an embedded 
product ? does ECDH (Group 19) requires any hardware support(i.e. engine 
libraries/files)? We don’t have hardware/engine support in the target.
  2.  If ECDH Algorithm (Group 19) recommended, How will be the performance?
  3.  If ECDH Algorithm (Group 19) not recommended, What would be the simple & 
secure DH or ECDH algorithm for shared secret key generation?

When I go through the code, I could see many conditional compilation macros. 
What are the conditional macros I need to enable for minimal footprint? What 
are the source file I need to build?

OPENSSL_NO_ENGINE
OPENSSL_NO_AUTOLOAD_CONFIG
OPENSSL_NO_RDRAND
OPENSSL_NO_PADLOCKENG
OPENSSL_NO_AFALGENG
OPENSSL_NO_STATIC_ENGINE



Thanks & Regards,
Damodhar.
+91-7702191212



General
From: Neil Horman mailto:nhor...@openssl.org>>
Sent: Wednesday, July 24, 2024 11:04 PM
To: Damodhar Boddukuri 
mailto:damodhar.bodduk...@non.se.com>>
Cc: openssl-users@openssl.org
Subject: Re: compile openssl for Arm A9 & VxWorks


[External email: Use caution with links and attachments]




At this point you really are going to need to dig into the VxWorks 
documentation to figure out what compiler flags and include files you need to 
set to get this all to work.  It may require some openssl code changes to use 
your compiler/build environment



General
On Wed, Jul 24, 2024 at 12:51 PM Damodhar Boddukuri 
mailto:damodhar.bodduk...@non.se.com>> wrote:

Hi,

Thank you for your support. I have tried with the following target. Now, its 
invoking the compiler.

"vxworks-armv7a" => {
inherit_from => [ "BASE_Windows" ],
CC   => "ccarm",
cflags   => '-g -fno-builtin -t7 -mfpu=vfp -mfloat-abi=softfp -ansi 
-fno-zero-initialized-in-bss -Wall  -DCPU=_VX_ARMARCH7 -DTOOL_FAMILY=gnu 
-DTOOL=gnu -D_WRS_KERNEL -DARMEL -DCPU_CORTEXA8 -DARMMMU=ARMMMU_CORTEXA8 
-DARMCACHE=ARMCACHE_CORTEXA8 -DIP_PORT_VXWORKS=69 -DINET -D_WRS_VX_SMP 
-D_VSB_CONFIG_FILE=\"$(VSB_CONFIG_FILE)\" ',
sys_id   => "VXWORKS",
lflags   => add('-L$(VSB_DIR)\arm\ARMARCH7\gnu_standard 
-L$(VSB_DIR)\arm\ARMARCH7\gnu -L$(VSB_DIR)\arm\ARMARCH7\common 
-L$(VSB_DIR)\arm\ARMARCH7\gnu -L$(VSB_DIR)\arm\ARMARCH7\common 
-L$(WS_ROOT_DIR)\obj\vxworks-6.9\krnl\lib_smp\arm\ARMARCH7\gnu 
-L$(WS_ROOT_DIR)\obj\vxworks-6.9\krnl\lib_smp\arm\ARMARCH7\common 
-L$(WIND_HOME)\components\obj\vxworks-6.9\krnl\lib_smp\arm\ARMARCH7\gnu 
-L$(WIND_HOME)\components\obj\vxworks-6.9\krnl\lib_smp\arm\ARMARCH7\common'),
ex_libs  => add("-Wl,--defsym,__wrs_rtp_base=0xe000"),
AR   => add("ararm"),
ARFLAGS  => add("-rsv"),
includes => ["\$(WIND_BASE)/target/usr/h" ,"\$(WIND_BASE)/target/h" 
, "\$(VSB_INCLUDE_DIR)"],
},


With this, in  Makefile

  1.  LIBS= apps\libapps.lib  libcrypto.lib  libssl.lib  
providers\libcommon.lib  providers\libdefault.lib  providers\liblegacy.lib  
test\libtestutil.lib

Makefile generated library extension with .lib. But our target is expecting .a 
libraries & .o object files



  1.  It’s unable to find the include files even though path include path is 
correct.

Eg: apps\lib\libapps-lib-app_libctx.obj: apps\lib\app_libctx.c

  $(CC)  $(LIB_CFLAGS) -I"." -I"include" -I"apps\include" 
$(LIB_CPPFLAGS)  -c $(COUTFLAG)$@ 

RE: compile openssl for Arm A9 & VxWorks

[Damodhar Boddukuri via openssl-users]

Hi,

Thanks for your support.

We are planning to use ECDH Algorithm(Group 19) with a minimal footprint in an 
Embedded System Product for the shared secret key generation.

I have few questions in my mind:

  1.  Is it recommended to use ECDH Algorithm (Group 19) for an embedded 
product ? does ECDH (Group 19) requires any hardware support(i.e. engine 
libraries/files)? We don’t have hardware/engine support in the target.
  2.  If ECDH Algorithm (Group 19) recommended, How will be the performance?
  3.  If ECDH Algorithm (Group 19) not recommended, What would be the simple & 
secure DH or ECDH algorithm for shared secret key generation?

When I go through the code, I could see many conditional compilation macros. 
What are the conditional macros I need to enable for minimal footprint? What 
are the source file I need to build?

OPENSSL_NO_ENGINE
OPENSSL_NO_AUTOLOAD_CONFIG
OPENSSL_NO_RDRAND
OPENSSL_NO_PADLOCKENG
OPENSSL_NO_AFALGENG
OPENSSL_NO_STATIC_ENGINE



Thanks & Regards,
Damodhar.
+91-7702191212



General

From: Neil Horman 
Sent: Wednesday, July 24, 2024 11:04 PM
To: Damodhar Boddukuri 
Cc: openssl-users@openssl.org
Subject: Re: compile openssl for Arm A9 & VxWorks


[External email: Use caution with links and attachments]




At this point you really are going to need to dig into the VxWorks 
documentation to figure out what compiler flags and include files you need to 
set to get this all to work.  It may require some openssl code changes to use 
your compiler/build environment

On Wed, Jul 24, 2024 at 12:51 PM Damodhar Boddukuri 
mailto:damodhar.bodduk...@non.se.com>> wrote:

Hi,

Thank you for your support. I have tried with the following target. Now, its 
invoking the compiler.

"vxworks-armv7a" => {
inherit_from => [ "BASE_Windows" ],
CC   => "ccarm",
cflags   => '-g -fno-builtin -t7 -mfpu=vfp -mfloat-abi=softfp -ansi 
-fno-zero-initialized-in-bss -Wall  -DCPU=_VX_ARMARCH7 -DTOOL_FAMILY=gnu 
-DTOOL=gnu -D_WRS_KERNEL -DARMEL -DCPU_CORTEXA8 -DARMMMU=ARMMMU_CORTEXA8 
-DARMCACHE=ARMCACHE_CORTEXA8 -DIP_PORT_VXWORKS=69 -DINET -D_WRS_VX_SMP 
-D_VSB_CONFIG_FILE=\"$(VSB_CONFIG_FILE)\" ',
sys_id   => "VXWORKS",
lflags   => add('-L$(VSB_DIR)\arm\ARMARCH7\gnu_standard 
-L$(VSB_DIR)\arm\ARMARCH7\gnu -L$(VSB_DIR)\arm\ARMARCH7\common 
-L$(VSB_DIR)\arm\ARMARCH7\gnu -L$(VSB_DIR)\arm\ARMARCH7\common 
-L$(WS_ROOT_DIR)\obj\vxworks-6.9\krnl\lib_smp\arm\ARMARCH7\gnu 
-L$(WS_ROOT_DIR)\obj\vxworks-6.9\krnl\lib_smp\arm\ARMARCH7\common 
-L$(WIND_HOME)\components\obj\vxworks-6.9\krnl\lib_smp\arm\ARMARCH7\gnu 
-L$(WIND_HOME)\components\obj\vxworks-6.9\krnl\lib_smp\arm\ARMARCH7\common'),
ex_libs  => add("-Wl,--defsym,__wrs_rtp_base=0xe000"),
AR   => add("ararm"),
ARFLAGS  => add("-rsv"),
includes => ["\$(WIND_BASE)/target/usr/h" ,"\$(WIND_BASE)/target/h" 
, "\$(VSB_INCLUDE_DIR)"],
},


With this, in  Makefile

  1.  LIBS= apps\libapps.lib  libcrypto.lib  libssl.lib  
providers\libcommon.lib  providers\libdefault.lib  providers\liblegacy.lib  
test\libtestutil.lib

Makefile generated library extension with .lib. But our target is expecting .a 
libraries & .o object files



  1.  It’s unable to find the include files even though path include path is 
correct.

Eg: apps\lib\libapps-lib-app_libctx.obj: apps\lib\app_libctx.c

  $(CC)  $(LIB_CFLAGS) -I"." -I"include" -I"apps\include" 
$(LIB_CPPFLAGS)  -c $(COUTFLAG)$@ "apps\lib\app_libctx.c"

  cmd /C "  $(LIB_CFLAGS) -I"." -I"include" -I"apps\include" 
$(LIB_CPPFLAGS)  "apps\lib\app_libctx.c" > apps\lib\libapps-lib-app_libctx.d 
2>&1"




I have attached makefile & log captured while executing Config and nmke. Please 
have a look at & suggest me the way forward to resolve these issues.


Thanks in advance.

Log:
perl Configure vxworks-armv7a no-shared no-dso no-pic no-aria no-async 
no-autoload-config no-blake2 no-bf no-camellia no-cast no-chacha no-cmac no-cmp 
no-cms no-comp no-ct no-des no-dgram no-dtls no-engine no-filenames no-gost 
no-idea no-ktls no-mdc2 no-md2 no-md4 no-multiblock no-nextprotoneg no-ocsp 
no-ocb no-poly1305 no-psk no-rc2 no-rc4 no-rc5 no-rmd160 no-scrypt no-seed 
no-siphash no-siv no-sm2 no-sm3 no-sm4 no-srp no-srtp no-sse2 no-ssl3 
no-ssl3-method no-threads no-ts no-ui-console no-whirlpool no-asm 
-DOPENSSL_NO_SECURE_MEMORY -DOPENSSL_SMALL_FOOTPRINT

>nmake

"ccarm"  -g -fno-builtin -t7 -mfpu=vfp -mfloat-abi=softfp -ansi 
-fno-zero-initialized-in-bss -Wall  -DCPU=_VX_ARMARCH7 -DTOOL_FAMILY=gnu 
-DTOOL=gnu -D_WRS_KERNEL -DARMEL -DCPU_CORTEXA8 -DARMMMU=ARMMMU_CORTEXA8 
-DARMCACHE=ARMCACHE_CORTEXA8 -DIP_PORT_VXWORKS=69 -DINET -D_WRS_VX_SMP 
-D_VSB_CONFIG_FILE=\"\"  -I"." -I"include" -I"apps\include" 
-D"OPENSSLDIR=\"C:\\Program Files\\Common Files\\SSL\"" 
-D"ENGINESDIR=\"C:\\Program Files\\OpenSSL\\lib\\engines-3\"" 
-D"MODULESDIR=\"C:\\Program 

openSSL cross compilation for target "vxworks-armv7a" in Windows platform

[Damodhar Boddukuri via openssl-users]

Hi OpenSSL user,

I am trying to compile "openSSL cross compilation for target "vxworks-armv7a" 
in Windows platform":

The target compiler is ccarm.exe

Approach-1:
In Linux platform, Added the following target details in 10-main.conf file and 
ran the ./config . It generated the configdata.pm, 
configdata.pm, Makefile.in, Makefile, include/openssl/configuration.h files for 
the target "vxworks-armv7a". When I run the make, it generating the required 
files with perl script, But its unable to invoke the compiler ccarm.exe because 
it's a .exe file.

When I move entire source-code to windows platform try to run the make, its 
giving errors in the perl script.


"vxworks-armv7a" => {
inherit_from => [ "BASE_unix" ],
 CC   => "ccarm",
CFLAGS   => '-g -fno-builtin -t7 -mfpu=vfp -mfloat-abi=softfp 
-ansi -fno-zero-initialized-in-bss -Wall -I$(TGT_DIR)/config/all -I$(TGT_DIR)/h 
-I$(WIND_HOME)/components/windml-5.3/h 
-I$(WIND_HOME)/components/webservices-1.8/h 
-I$(WIND_HOME)/components/webcli-4.9/target/h 
-I$(WIND_HOME)/components/tcf_agent-1.4/agent 
-I$(WIND_HOME)/components/stacktrace-1.0/include 
-I$(WIND_HOME)/components/opc-3.2/h -I$(WIND_HOME)/components/dcom-2.3/h 
-I$(WIND_HOME)/components/cafe-0.1/hpc/include 
-I$(WIND_HOME)/components/cafe-0.1/cafe/include 
-I$(WIND_HOME)/components/ip_net2-6.9/ipcom/config 
-I$(WIND_HOME)/components/cafe-0.1/vxworks/include 
-I$(WIND_HOME)/components/windml-5.3/osconfig/vxworks/src 
-I$(WIND_HOME)/components/tcf_agent-1.4/osconfig/vxworks/src 
-I$(WIND_HOME)/components/stacktrace-1.0/osconfig/vxworks/src 
-I$(WIND_HOME)/components/ip_net2-6.9/osconfig/vxworks/src 
-I$(WIND_HOME)/components/cafe-0.1/osconfig/vxworks/src 
-I$(WIND_HOME)/components/windml-5.3/osconfig/vxworks/h 
-I$(WIND_HOME)/components/tcf_agent-1.4/osconfig/vxworks/h 
-I$(WIND_HOME)/components/stacktrace-1.0/osconfig/vxworks/h 
-I$(WIND_HOME)/components/ip_net2-6.9/osconfig/vxworks/h 
-I$(WIND_HOME)/components/cafe-0.1/osconfig/vxworks/h -I$(TGT_DIR)/src/hwif 
-I$(TGT_DIR)/src/hwif/h -I $(TGT_DIR)/3rdparty/pbcl/h -I. 
-I$(TGT_DIR)/h/wrn/coreip -I$(TGT_DIR)/src/config -I$(TGT_DIR)/config/comps/src 
-I$(TGT_DIR)/config/comps/src/dosfs2 -I$(TGT_DIR)/src/drv 
-I$(TGT_DIR)/src/hwif/h -DCPU=_VX_ARMARCH7 -DTOOL_FAMILY=gnu -DTOOL=gnu 
-D_WRS_KERNEL -DARMEL -DCPU_CORTEXA8 -DARMMMU=ARMMMU_CORTEXA8 
-DARMCACHE=ARMCACHE_CORTEXA8 -DIP_PORT_VXWORKS=69 -DINET -D_WRS_VX_SMP 
-D_VSB_CONFIG_FILE=\"$(VSB_CONFIG_FILE)\" -I$(VSB_INCLUDE_DIR)',
cflags   => '-g -fno-builtin -t7 -mfpu=vfp -mfloat-abi=softfp 
-ansi -fno-zero-initialized-in-bss -Wall -I$(TGT_DIR)/config/all -I$(TGT_DIR)/h 
-I$(WIND_HOME)/components/windml-5.3/h 
-I$(WIND_HOME)/components/webservices-1.8/h 
-I$(WIND_HOME)/components/webcli-4.9/target/h 
-I$(WIND_HOME)/components/tcf_agent-1.4/agent 
-I$(WIND_HOME)/components/stacktrace-1.0/include 
-I$(WIND_HOME)/components/opc-3.2/h -I$(WIND_HOME)/components/dcom-2.3/h 
-I$(WIND_HOME)/components/cafe-0.1/hpc/include 
-I$(WIND_HOME)/components/cafe-0.1/cafe/include 
-I$(WIND_HOME)/components/ip_net2-6.9/ipcom/config 
-I$(WIND_HOME)/components/cafe-0.1/vxworks/include 
-I$(WIND_HOME)/components/windml-5.3/osconfig/vxworks/src 
-I$(WIND_HOME)/components/tcf_agent-1.4/osconfig/vxworks/src 
-I$(WIND_HOME)/components/stacktrace-1.0/osconfig/vxworks/src 
-I$(WIND_HOME)/components/ip_net2-6.9/osconfig/vxworks/src 
-I$(WIND_HOME)/components/cafe-0.1/osconfig/vxworks/src 
-I$(WIND_HOME)/components/windml-5.3/osconfig/vxworks/h 
-I$(WIND_HOME)/components/tcf_agent-1.4/osconfig/vxworks/h 
-I$(WIND_HOME)/components/stacktrace-1.0/osconfig/vxworks/h 
-I$(WIND_HOME)/components/ip_net2-6.9/osconfig/vxworks/h 
-I$(WIND_HOME)/components/cafe-0.1/osconfig/vxworks/h -I$(TGT_DIR)/src/hwif 
-I$(TGT_DIR)/src/hwif/h -I $(TGT_DIR)/3rdparty/pbcl/h -I. 
-I$(TGT_DIR)/h/wrn/coreip -I$(TGT_DIR)/src/config -I$(TGT_DIR)/config/comps/src 
-I$(TGT_DIR)/config/comps/src/dosfs2 -I$(TGT_DIR)/src/drv 
-I$(TGT_DIR)/src/hwif/h -DCPU=_VX_ARMARCH7 -DTOOL_FAMILY=gnu -DTOOL=gnu 
-D_WRS_KERNEL -DARMEL -DCPU_CORTEXA8 -DARMMMU=ARMMMU_CORTEXA8 
-DARMCACHE=ARMCACHE_CORTEXA8 -DIP_PORT_VXWORKS=69 -DINET -D_WRS_VX_SMP 
-D_VSB_CONFIG_FILE=\"$(VSB_CONFIG_FILE)\" -I$(VSB_INCLUDE_DIR)',
cppflags => combine('-g -fno-builtin -t7 -mfpu=vfp 
-mfloat-abi=softfp -ansi -fno-zero-initialized-in-bss -Wall 
-I$(TGT_DIR)/config/all -I$(TGT_DIR)/h -I$(WIND_HOME)/components/windml-5.3/h 
-I$(WIND_HOME)/components/webservices-1.8/h 
-I$(WIND_HOME)/components/webcli-4.9/target/h 
-I$(WIND_HOME)/components/tcf_agent-1.4/agent 
-I$(WIND_HOME)/components/stacktrace-1.0/include 
-I$(WIND_HOME)/components/opc-3.2/h -I$(WIND_HOME)/components/dcom-2.3/h 
-I$(WIND_HOME)/components/cafe-0.1/hpc/include 
-I$(WIND_HOME)/components/cafe-0.1/cafe/include 
-I$(WIND_HOME)/components/ip_net2-6.9/ipcom/config 
-I$(WIND_HOME)/components/cafe-0.1/vxworks/include 

Re: openssl and DSA q size doubt

[Billy Brumley]

Howdy,


But  my question is why q is not 160 bits but instead 224 bits was used by 
openssl since the FIPS 186 standard clearly says to use q size 160 bits for p 
size 1024 bits?

Can someone familiar with the topic, clarify my doubt please? Maybe I missed 
some fine points in the standard.


I'd suggest using `genpkey` instead of `dsaparam`, like so:

openssl genpkey -genparam -algorithm DSA -pkeyopt pbits:1024 -pkeyopt 
qbits:160


Cheers,

BBB

smime.p7s
Description: S/MIME Cryptographic Signature

Re: compile openssl for Arm A9 & VxWorks

[Neil Horman]

At this point you really are going to need to dig into the VxWorks
documentation to figure out what compiler flags and include files you need
to set to get this all to work.  It may require some openssl code changes
to use your compiler/build environment

On Wed, Jul 24, 2024 at 12:51 PM Damodhar Boddukuri <
damodhar.bodduk...@non.se.com> wrote:

>
>
> Hi,
>
>
>
> Thank you for your support. I have tried with the following target. Now,
> its invoking the compiler.
>
>
>
> "vxworks-armv7a" => {
>
> inherit_from => [ "BASE_Windows" ],
>
> CC   => "ccarm",
>
> cflags   => '-g -fno-builtin -t7 -mfpu=vfp -mfloat-abi=softfp
> -ansi -fno-zero-initialized-in-bss -Wall  -DCPU=_VX_ARMARCH7
> -DTOOL_FAMILY=gnu -DTOOL=gnu -D_WRS_KERNEL -DARMEL -DCPU_CORTEXA8
> -DARMMMU=ARMMMU_CORTEXA8 -DARMCACHE=ARMCACHE_CORTEXA8 -DIP_PORT_VXWORKS=69
> -DINET -D_WRS_VX_SMP -D_VSB_CONFIG_FILE=\"$(VSB_CONFIG_FILE)\" ',
>
> sys_id   => "VXWORKS",
>
> lflags   => add('-L$(VSB_DIR)\arm\ARMARCH7\gnu_standard
> -L$(VSB_DIR)\arm\ARMARCH7\gnu -L$(VSB_DIR)\arm\ARMARCH7\common
> -L$(VSB_DIR)\arm\ARMARCH7\gnu -L$(VSB_DIR)\arm\ARMARCH7\common
> -L$(WS_ROOT_DIR)\obj\vxworks-6.9\krnl\lib_smp\arm\ARMARCH7\gnu
> -L$(WS_ROOT_DIR)\obj\vxworks-6.9\krnl\lib_smp\arm\ARMARCH7\common
> -L$(WIND_HOME)\components\obj\vxworks-6.9\krnl\lib_smp\arm\ARMARCH7\gnu
> -L$(WIND_HOME)\components\obj\vxworks-6.9\krnl\lib_smp\arm\ARMARCH7\common'),
>
> ex_libs  => add("-Wl,--defsym,__wrs_rtp_base=0xe000"),
>
> AR   => add("ararm"),
>
> ARFLAGS  => add("-rsv"),
>
> includes => ["\$(WIND_BASE)/target/usr/h"
> ,"\$(WIND_BASE)/target/h" , "\$(VSB_INCLUDE_DIR)"],
>
> },
>
>
>
>
>
> *With this, in  Makefile*
>
>1. *LIBS= apps\libapps.lib  libcrypto.lib  libssl.lib
>providers\libcommon.lib  providers\libdefault.lib  providers\liblegacy.lib
>test\libtestutil.lib*
>
> *Makefile generated library extension with .lib. But our target is
> expecting .a libraries & .o object files*
>
>
>
>2. *It’s unable to find the include files even though path include
>path is correct.*
>
> *Eg: apps\lib\libapps-lib-app_libctx.obj: apps\lib\app_libctx.c*
>
> *  $(CC)  $(LIB_CFLAGS) -I"." -I"include" -I"apps\include"
> $(LIB_CPPFLAGS)  -c $(COUTFLAG)$@ "apps\lib\app_libctx.c"*
>
> *  cmd /C "  $(LIB_CFLAGS) -I"." -I"include" -I"apps\include"
> $(LIB_CPPFLAGS)  "apps\lib\app_libctx.c" >
> apps\lib\libapps-lib-app_libctx.d 2>&1"*
>
>
>
>
>
> *I have attached makefile & log captured while executing Config and nmke.
> Please have a look at & suggest me the way forward to resolve these issues.*
>
>
>
> *Thanks in advance.*
>
>
>
> *Log:*
>
> *perl Configure vxworks-armv7a no-shared no-dso no-pic no-aria no-async
> no-autoload-config no-blake2 no-bf no-camellia no-cast no-chacha no-cmac
> no-cmp no-cms no-comp no-ct no-des no-dgram no-dtls no-engine no-filenames
> no-gost no-idea no-ktls no-mdc2 no-md2 no-md4 no-multiblock no-nextprotoneg
> no-ocsp no-ocb no-poly1305 no-psk no-rc2 no-rc4 no-rc5 no-rmd160 no-scrypt
> no-seed no-siphash no-siv no-sm2 no-sm3 no-sm4 no-srp no-srtp no-sse2
> no-ssl3 no-ssl3-method no-threads no-ts no-ui-console no-whirlpool no-asm
> -DOPENSSL_NO_SECURE_MEMORY -DOPENSSL_SMALL_FOOTPRINT*
>
>
>
> >nmake
>
>
>
> *"ccarm"  -g -fno-builtin -t7 -mfpu=vfp -mfloat-abi=softfp -ansi
> -fno-zero-initialized-in-bss -Wall  -DCPU=_VX_ARMARCH7 -DTOOL_FAMILY=gnu
> -DTOOL=gnu -D_WRS_KERNEL -DARMEL -DCPU_CORTEXA8 -DARMMMU=ARMMMU_CORTEXA8
> -DARMCACHE=ARMCACHE_CORTEXA8 -DIP_PORT_VXWORKS=69 -DINET -D_WRS_VX_SMP
> -D_VSB_CONFIG_FILE=\"\"  -I"." -I"include" -I"apps\include"
> -D"OPENSSLDIR=\"C:\\Program Files\\Common Files\\SSL\""
> -D"ENGINESDIR=\"C:\\Program Files\\OpenSSL\\lib\\engines-3\""
> -D"MODULESDIR=\"C:\\Program Files\\OpenSSL\\lib\\ossl-modules\""
> -D"OPENSSL_BUILDING_OPENSSL" -D"NDEBUG"
> -I"C:\Dev\WindRiverDSMPDDR_V18\vxworks-6.9/target/usr/h"
> -I"C:\Dev\WindRiverDSMPDDR_V18\vxworks-6.9/target/h" -I""
> -DOPENSSL_NO_SECURE_MEMORY -DOPENSSL_SMALL_FOOTPRINT  -c
> apps\lib\libapps-lib-app_libctx.obj "apps\lib\app_libctx.c"*
>
> *ccarm.EXE: apps\lib\libapps-lib-app_libctx.obj: No such file or directory*
>
> *In file included from
> c:\windriverdsmpddr_v18\gnu\4.3.3-vxworks-6.9\x86-win32\bin\../../lib/gcc/arm-wrs-vxworks/4.3.3/include-fixed/syslimits.h:7,*
>
> * from
> c:\windriverdsmpddr_v18\gnu\4.3.3-vxworks-6.9\x86-win32\bin\../../lib/gcc/arm-wrs-vxworks/4.3.3/include-fixed/limits.h:11,*
>
> * from include/openssl/types.h:26,*
>
> * from apps\include/app_libctx.h:13,*
>
> * from apps\lib\app_libctx.c:9:*
>
> *c:\windriverdsmpddr_v18\gnu\4.3.3-vxworks-6.9\x86-win32\bin\../../lib/gcc/arm-wrs-vxworks/4.3.3/include-fixed/limits.h:122:61:
> error: no include path in which to search for limits.h*
>
> *In file included from include/openssl/types.h:32,*
>
> 

RE: compile openssl for Arm A9 & VxWorks

[Damodhar Boddukuri via openssl-users]

Hi,

Thank you for your support. I have tried with the following target. Now, its 
invoking the compiler.

"vxworks-armv7a" => {
inherit_from => [ "BASE_Windows" ],
CC   => "ccarm",
cflags   => '-g -fno-builtin -t7 -mfpu=vfp -mfloat-abi=softfp -ansi 
-fno-zero-initialized-in-bss -Wall  -DCPU=_VX_ARMARCH7 -DTOOL_FAMILY=gnu 
-DTOOL=gnu -D_WRS_KERNEL -DARMEL -DCPU_CORTEXA8 -DARMMMU=ARMMMU_CORTEXA8 
-DARMCACHE=ARMCACHE_CORTEXA8 -DIP_PORT_VXWORKS=69 -DINET -D_WRS_VX_SMP 
-D_VSB_CONFIG_FILE=\"$(VSB_CONFIG_FILE)\" ',
sys_id   => "VXWORKS",
lflags   => add('-L$(VSB_DIR)\arm\ARMARCH7\gnu_standard 
-L$(VSB_DIR)\arm\ARMARCH7\gnu -L$(VSB_DIR)\arm\ARMARCH7\common 
-L$(VSB_DIR)\arm\ARMARCH7\gnu -L$(VSB_DIR)\arm\ARMARCH7\common 
-L$(WS_ROOT_DIR)\obj\vxworks-6.9\krnl\lib_smp\arm\ARMARCH7\gnu 
-L$(WS_ROOT_DIR)\obj\vxworks-6.9\krnl\lib_smp\arm\ARMARCH7\common 
-L$(WIND_HOME)\components\obj\vxworks-6.9\krnl\lib_smp\arm\ARMARCH7\gnu 
-L$(WIND_HOME)\components\obj\vxworks-6.9\krnl\lib_smp\arm\ARMARCH7\common'),
ex_libs  => add("-Wl,--defsym,__wrs_rtp_base=0xe000"),
AR   => add("ararm"),
ARFLAGS  => add("-rsv"),
includes => ["\$(WIND_BASE)/target/usr/h" ,"\$(WIND_BASE)/target/h" 
, "\$(VSB_INCLUDE_DIR)"],
},


With this, in  Makefile

  1.  LIBS= apps\libapps.lib  libcrypto.lib  libssl.lib  
providers\libcommon.lib  providers\libdefault.lib  providers\liblegacy.lib  
test\libtestutil.lib

Makefile generated library extension with .lib. But our target is expecting .a 
libraries & .o object files



  1.  It’s unable to find the include files even though path include path is 
correct.

Eg: apps\lib\libapps-lib-app_libctx.obj: apps\lib\app_libctx.c

  $(CC)  $(LIB_CFLAGS) -I"." -I"include" -I"apps\include" 
$(LIB_CPPFLAGS)  -c $(COUTFLAG)$@ "apps\lib\app_libctx.c"

  cmd /C "  $(LIB_CFLAGS) -I"." -I"include" -I"apps\include" 
$(LIB_CPPFLAGS)  "apps\lib\app_libctx.c" > apps\lib\libapps-lib-app_libctx.d 
2>&1"




I have attached makefile & log captured while executing Config and nmke. Please 
have a look at & suggest me the way forward to resolve these issues.


Thanks in advance.

Log:
perl Configure vxworks-armv7a no-shared no-dso no-pic no-aria no-async 
no-autoload-config no-blake2 no-bf no-camellia no-cast no-chacha no-cmac no-cmp 
no-cms no-comp no-ct no-des no-dgram no-dtls no-engine no-filenames no-gost 
no-idea no-ktls no-mdc2 no-md2 no-md4 no-multiblock no-nextprotoneg no-ocsp 
no-ocb no-poly1305 no-psk no-rc2 no-rc4 no-rc5 no-rmd160 no-scrypt no-seed 
no-siphash no-siv no-sm2 no-sm3 no-sm4 no-srp no-srtp no-sse2 no-ssl3 
no-ssl3-method no-threads no-ts no-ui-console no-whirlpool no-asm 
-DOPENSSL_NO_SECURE_MEMORY -DOPENSSL_SMALL_FOOTPRINT

>nmake

"ccarm"  -g -fno-builtin -t7 -mfpu=vfp -mfloat-abi=softfp -ansi 
-fno-zero-initialized-in-bss -Wall  -DCPU=_VX_ARMARCH7 -DTOOL_FAMILY=gnu 
-DTOOL=gnu -D_WRS_KERNEL -DARMEL -DCPU_CORTEXA8 -DARMMMU=ARMMMU_CORTEXA8 
-DARMCACHE=ARMCACHE_CORTEXA8 -DIP_PORT_VXWORKS=69 -DINET -D_WRS_VX_SMP 
-D_VSB_CONFIG_FILE=\"\"  -I"." -I"include" -I"apps\include" 
-D"OPENSSLDIR=\"C:\\Program Files\\Common Files\\SSL\"" 
-D"ENGINESDIR=\"C:\\Program Files\\OpenSSL\\lib\\engines-3\"" 
-D"MODULESDIR=\"C:\\Program Files\\OpenSSL\\lib\\ossl-modules\"" 
-D"OPENSSL_BUILDING_OPENSSL" -D"NDEBUG" 
-I"C:\Dev\WindRiverDSMPDDR_V18\vxworks-6.9/target/usr/h" 
-I"C:\Dev\WindRiverDSMPDDR_V18\vxworks-6.9/target/h" -I"" 
-DOPENSSL_NO_SECURE_MEMORY -DOPENSSL_SMALL_FOOTPRINT  -c 
apps\lib\libapps-lib-app_libctx.obj "apps\lib\app_libctx.c"
ccarm.EXE: apps\lib\libapps-lib-app_libctx.obj: No such file or directory
In file included from 
c:\windriverdsmpddr_v18\gnu\4.3.3-vxworks-6.9\x86-win32\bin\../../lib/gcc/arm-wrs-vxworks/4.3.3/include-fixed/syslimits.h:7,
 from 
c:\windriverdsmpddr_v18\gnu\4.3.3-vxworks-6.9\x86-win32\bin\../../lib/gcc/arm-wrs-vxworks/4.3.3/include-fixed/limits.h:11,
 from include/openssl/types.h:26,
 from apps\include/app_libctx.h:13,
 from apps\lib\app_libctx.c:9:
c:\windriverdsmpddr_v18\gnu\4.3.3-vxworks-6.9\x86-win32\bin\../../lib/gcc/arm-wrs-vxworks/4.3.3/include-fixed/limits.h:122:61:
 error: no include path in which to search for limits.h
In file included from include/openssl/types.h:32,
 from apps\include/app_libctx.h:13,
 from apps\lib\app_libctx.c:9:
include/openssl/e_os2.h:256:22: error: stdint.h: No such file or directory
In file included from include/openssl/types.h:32,
 from apps\include/app_libctx.h:13,
 from apps\lib\app_libctx.c:9:
include/openssl/e_os2.h:265: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before 'ossl_intmax_t'
include/openssl/e_os2.h:266: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before 'ossl_uintmax_t'
In file included from include/internal/e_os.h:17,

openssl and DSA q size doubt

[M K Saravanan]

Hi,

I am trying to learn how DSA works by reading the book "Understanding
Cryptography" by Christof Paar and  Jan Pelzl.

I also understand that DSA is now deprecated as per FIPS 186-5 (Feb, 2023)
and ECDSA is preferred.

However just for learning purpose I was experimenting with DSA param
generation, key generation and cert generation using openssl.

As per the book, the recommended size for p and q values are:

p = 1024 bits, q = 160 bits

p = 2048 bits, q = 224 bits

p = 3072 bits, q = 256 bits.

>From the book, I also understand that the length of the DSA signature r and
s size will be the same as q size.

Thus if q = 160 bits, then r size is also 160 bits and s size is also 160
bits.

I used openssl:

$ openssl version

OpenSSL 3.0.14 4 Jun 2024 (Library: OpenSSL 3.0.14 4 Jun 2024)


and created a dsaparam file for 1024 bit key size and using that param
file, generated a dsakey.

$ openssl dsaparam -in dsaparam.pem -text -noout

DSA-Parameters: (1024 bit)

P:

00:89:8b:28:2d:ae:59:55:19:de:ef:79:a8:f0:f1:

44:39:b4:ee:32:fc:48:38:7e:bd:4a:d0:d7:ea:02:

b1:e8:12:65:d4:f9:3e:ef:bb:03:d6:85:33:91:fa:

a0:0f:88:96:a2:06:16:84:e6:6d:8c:41:ad:f7:ab:

51:59:44:5d:df:c6:06:66:08:51:2b:f5:3c:1e:02:

35:2a:78:1a:9b:7e:0c:d1:65:e6:0a:c5:63:ca:3a:

58:84:6b:ff:b8:4a:9a:b7:97:a0:3d:6b:ba:e4:02:

a9:97:fb:e8:98:4e:a4:42:8f:31:20:3d:31:50:31:

00:7a:b0:01:37:80:f6:f8:15

Q:

00:d5:eb:71:18:25:4e:6c:b9:e0:20:92:02:f4:86:

5f:d9:cd:66:cc:ff:89:33:86:54:c6:19:90:f5

G:

52:02:50:73:17:4f:12:35:f6:11:ed:c6:c1:b8:01:

b4:e5:cf:5f:05:a4:6b:f8:d4:a5:d9:3e:a9:7a:97:

f3:d2:db:28:4a:57:2e:a3:f4:a7:fc:16:65:75:9a:

5d:67:b0:a8:ac:43:21:24:53:48:23:e3:13:52:ce:

a3:b7:7e:85:b9:0f:51:e8:fe:32:16:12:82:16:44:

29:85:83:eb:8e:3e:dd:9c:38:49:de:da:44:85:d1:

31:01:20:c7:43:1f:30:3e:f3:a6:50:36:ee:e5:66:

1c:40:a2:ca:1d:39:78:a5:4a:4a:04:83:15:df:4a:

69:1c:d2:4f:ac:36:74:78

===

Here the size of q is 28 bytes (ignore the leading 0x00 byte). so 28*8 =
224 bits.

I was expecting a q size of 160 bits, but here it is 224 bits.  Why?

Using above param, I generated a dsa key.

Using that key, I created a self signed cert for testing purpose.


-

$ openssl x509 -in ./dsacert.pem -text -nooout

Certificate:

Data:

Version: 3 (0x2)

Serial Number:

2f:40:b1:22:44:be:69:bc:36:01:25:a7:d0:c3:5d:33:0d:21:cc:eb

Signature Algorithm: dsa_with_SHA256

Issuer: C = SG, ST = SG, L = Suntec, O = F5, OU = ES, CN =
www.dsa1024eg.com, emailAddress = mksa...@gmail.com

Validity

Not Before: Jul 23 16:53:09 2024 GMT

Not After : Aug 22 16:53:09 2024 GMT

Subject: C = SG, ST = SG, L = Suntec, O = F5, OU = ES, CN =
www.dsa1024eg.com, emailAddress = mksa...@gmail.com

Subject Public Key Info:

Public Key Algorithm: dsaEncryption

Public-Key: (1024 bit)

pub:

0b:10:f8:f9:59:75:02:00:b3:b0:c7:4f:20:01:fe:

6b:6b:a0:1e:3c:44:b5:4c:e4:fb:16:39:1c:12:d8:

14:5d:ee:73:28:14:57:40:40:59:8f:37:54:7f:b8:

12:fd:55:5a:40:73:36:63:b7:1c:3f:39:87:76:56:

8b:8b:9c:df:41:a9:c6:56:ed:34:cb:5c:d2:db:55:

d4:37:d4:b1:59:25:b6:6a:7d:5c:61:9b:39:9a:6a:

a7:27:ac:2f:43:65:7f:53:76:bb:98:91:f0:f0:9c:

1d:99:88:43:44:4e:3c:c1:43:30:09:06:7b:c7:ad:

38:27:3a:6b:38:56:7e:38

P:

00:89:8b:28:2d:ae:59:55:19:de:ef:79:a8:f0:f1:

44:39:b4:ee:32:fc:48:38:7e:bd:4a:d0:d7:ea:02:

b1:e8:12:65:d4:f9:3e:ef:bb:03:d6:85:33:91:fa:

a0:0f:88:96:a2:06:16:84:e6:6d:8c:41:ad:f7:ab:

51:59:44:5d:df:c6:06:66:08:51:2b:f5:3c:1e:02:

35:2a:78:1a:9b:7e:0c:d1:65:e6:0a:c5:63:ca:3a:

58:84:6b:ff:b8:4a:9a:b7:97:a0:3d:6b:ba:e4:02:

a9:97:fb:e8:98:4e:a4:42:8f:31:20:3d:31:50:31:

00:7a:b0:01:37:80:f6:f8:15

Q:

00:d5:eb:71:18:25:4e:6c:b9:e0:20:92:02:f4:86:

5f:d9:cd:66:cc:ff:89:33:86:54:c6:19:90:f5

G:

52:02:50:73:17:4f:12:35:f6:11:ed:c6:c1:b8:01:

b4:e5:cf:5f:05:a4:6b:f8:d4:a5:d9:3e:a9:7a:97:

f3:d2:db:28:4a:57:2e:a3:f4:a7:fc:16:65:75:9a:

5d:67:b0:a8:ac:43:21:24:53:48:23:e3:13:52:ce:

a3:b7:7e:85:b9:0f:51:e8:fe:32:16:12:82:16:44:

29:85:83:eb:8e:3e:dd:9c:38:49:de:da:44:85:d1:

31:01:20:c7:43:1f:30:3e:f3:a6:50:36:ee:e5:66:

1c:40:a2:ca:1d:39:78:a5:4a:4a:04:83:15:df:4a:

69:1c:d2:4f:ac:36:74:78

X509v3 extensions:

X509v3 Subject Key 

Re: compile openssl for Arm A9 & VxWorks

[Neil Horman]

If you're trying to build on windows, you don't want to inherit from
BASE_unix, you want to inherit from BASE_Windows

On Tue, Jul 23, 2024 at 8:40 PM Damodhar Boddukuri <
damodhar.bodduk...@non.se.com> wrote:

>
>
> Hi,
>
>
>
> Thank you for the support.
>
>
>
> I am trying to compile “openSSL cross compilation for target
> "vxworks-armv7a" in Windows platform”:
>
>
>
> The target compiler is *ccarm.exe*
>
>
>
> *Approach-1:*
>
> In Linux platform, Added the following target details in * 10-main.conf *file
> and ran the *./config . *It generated* the
> configdata.pm , configdata.pm ,
> Makefile.in, Makefile, include/openssl/configuration.h *files for the
> target "vxworks-armv7a". When I run the make, it generating the required
> files with perl script, But its unable to invoke the compiler *ccarm.exe 
> *because
> it’s a .exe file.
>
>
>
> When I move entire source-code to windows platform try to run the make,
> its giving errors in the perl script.
>
>
>
>
>
> "vxworks-armv7a" => {
>
> inherit_from => [ "BASE_unix" ],
>
>  CC   => "ccarm",
>
> CFLAGS   => '-g -fno-builtin -t7 -mfpu=vfp
> -mfloat-abi=softfp -ansi -fno-zero-initialized-in-bss -Wall
> -I$(TGT_DIR)/config/all -I$(TGT_DIR)/h
> -I$(WIND_HOME)/components/windml-5.3/h
> -I$(WIND_HOME)/components/webservices-1.8/h
> -I$(WIND_HOME)/components/webcli-4.9/target/h
> -I$(WIND_HOME)/components/tcf_agent-1.4/agent
> -I$(WIND_HOME)/components/stacktrace-1.0/include
> -I$(WIND_HOME)/components/opc-3.2/h -I$(WIND_HOME)/components/dcom-2.3/h
> -I$(WIND_HOME)/components/cafe-0.1/hpc/include
> -I$(WIND_HOME)/components/cafe-0.1/cafe/include
> -I$(WIND_HOME)/components/ip_net2-6.9/ipcom/config
> -I$(WIND_HOME)/components/cafe-0.1/vxworks/include
> -I$(WIND_HOME)/components/windml-5.3/osconfig/vxworks/src
> -I$(WIND_HOME)/components/tcf_agent-1.4/osconfig/vxworks/src
> -I$(WIND_HOME)/components/stacktrace-1.0/osconfig/vxworks/src
> -I$(WIND_HOME)/components/ip_net2-6.9/osconfig/vxworks/src
> -I$(WIND_HOME)/components/cafe-0.1/osconfig/vxworks/src
> -I$(WIND_HOME)/components/windml-5.3/osconfig/vxworks/h
> -I$(WIND_HOME)/components/tcf_agent-1.4/osconfig/vxworks/h
> -I$(WIND_HOME)/components/stacktrace-1.0/osconfig/vxworks/h
> -I$(WIND_HOME)/components/ip_net2-6.9/osconfig/vxworks/h
> -I$(WIND_HOME)/components/cafe-0.1/osconfig/vxworks/h -I$(TGT_DIR)/src/hwif
> -I$(TGT_DIR)/src/hwif/h -I $(TGT_DIR)/3rdparty/pbcl/h -I.
> -I$(TGT_DIR)/h/wrn/coreip -I$(TGT_DIR)/src/config
> -I$(TGT_DIR)/config/comps/src -I$(TGT_DIR)/config/comps/src/dosfs2
> -I$(TGT_DIR)/src/drv -I$(TGT_DIR)/src/hwif/h -DCPU=_VX_ARMARCH7
> -DTOOL_FAMILY=gnu -DTOOL=gnu -D_WRS_KERNEL -DARMEL -DCPU_CORTEXA8
> -DARMMMU=ARMMMU_CORTEXA8 -DARMCACHE=ARMCACHE_CORTEXA8 -DIP_PORT_VXWORKS=69
> -DINET -D_WRS_VX_SMP -D_VSB_CONFIG_FILE=\"$(VSB_CONFIG_FILE)\"
> -I$(VSB_INCLUDE_DIR)',
>
> cflags   => '-g -fno-builtin -t7 -mfpu=vfp
> -mfloat-abi=softfp -ansi -fno-zero-initialized-in-bss -Wall
> -I$(TGT_DIR)/config/all -I$(TGT_DIR)/h
> -I$(WIND_HOME)/components/windml-5.3/h
> -I$(WIND_HOME)/components/webservices-1.8/h
> -I$(WIND_HOME)/components/webcli-4.9/target/h
> -I$(WIND_HOME)/components/tcf_agent-1.4/agent
> -I$(WIND_HOME)/components/stacktrace-1.0/include
> -I$(WIND_HOME)/components/opc-3.2/h -I$(WIND_HOME)/components/dcom-2.3/h
> -I$(WIND_HOME)/components/cafe-0.1/hpc/include
> -I$(WIND_HOME)/components/cafe-0.1/cafe/include
> -I$(WIND_HOME)/components/ip_net2-6.9/ipcom/config
> -I$(WIND_HOME)/components/cafe-0.1/vxworks/include
> -I$(WIND_HOME)/components/windml-5.3/osconfig/vxworks/src
> -I$(WIND_HOME)/components/tcf_agent-1.4/osconfig/vxworks/src
> -I$(WIND_HOME)/components/stacktrace-1.0/osconfig/vxworks/src
> -I$(WIND_HOME)/components/ip_net2-6.9/osconfig/vxworks/src
> -I$(WIND_HOME)/components/cafe-0.1/osconfig/vxworks/src
> -I$(WIND_HOME)/components/windml-5.3/osconfig/vxworks/h
> -I$(WIND_HOME)/components/tcf_agent-1.4/osconfig/vxworks/h
> -I$(WIND_HOME)/components/stacktrace-1.0/osconfig/vxworks/h
> -I$(WIND_HOME)/components/ip_net2-6.9/osconfig/vxworks/h
> -I$(WIND_HOME)/components/cafe-0.1/osconfig/vxworks/h -I$(TGT_DIR)/src/hwif
> -I$(TGT_DIR)/src/hwif/h -I $(TGT_DIR)/3rdparty/pbcl/h -I.
> -I$(TGT_DIR)/h/wrn/coreip -I$(TGT_DIR)/src/config
> -I$(TGT_DIR)/config/comps/src -I$(TGT_DIR)/config/comps/src/dosfs2
> -I$(TGT_DIR)/src/drv -I$(TGT_DIR)/src/hwif/h -DCPU=_VX_ARMARCH7
> -DTOOL_FAMILY=gnu -DTOOL=gnu -D_WRS_KERNEL -DARMEL -DCPU_CORTEXA8
> -DARMMMU=ARMMMU_CORTEXA8 -DARMCACHE=ARMCACHE_CORTEXA8 -DIP_PORT_VXWORKS=69
> -DINET -D_WRS_VX_SMP -D_VSB_CONFIG_FILE=\"$(VSB_CONFIG_FILE)\"
> -I$(VSB_INCLUDE_DIR)',
>
> cppflags => combine('-g -fno-builtin -t7 -mfpu=vfp
> -mfloat-abi=softfp -ansi -fno-zero-initialized-in-bss -Wall
> -I$(TGT_DIR)/config/all -I$(TGT_DIR)/h
> -I$(WIND_HOME)/components/windml-5.3/h
> -I$(WIND_HOME)/components/webservices-1.8/h
> 

OpenSSL New Governance Structure and Two New Projects

[Kajal Sapkota]

**

*We are announcing changes to the OpenSSL governance structure to 
enhance community engagement and strengthen our commitment to our 
Mission and Values . These changes are 
part of our ongoing journey to empower and provide more opportunities 
and mechanisms for active participation in decision-making processes.*


*

New Governance Framework

OpenSSL has two independent but co-equal entities to support the Mission:

 *

   The OpenSSL Foundation primarily
   focuses on non-commercial communities.

 *

   The OpenSSL Corporation primarily
   focuses on commercial communities.

This balanced approach ensures both entities can operate independently 
and make decisions autonomously.


Board of Directors

The OpenSSL Management Committee (OMC) has been dissolved, and boards of 
directors have been elected for the Foundation and the Corporation. 
There are ten voting members for each organization. These boards share 
all the responsibilities and authorities of the former OMC co-equally.


Community Advisory Committees

To further engage our communities, we are establishing two advisory 
committees for each entity: a Business Advisory Committee (BAC) and a 
Technical Advisory Committee (TAC). The communities will elect the 
members of the BACs and TACs, creating a direct channel for community 
input in roadmap development and reflecting the diverse perspectives of 
OpenSSL's communities.


New Projects Under the OpenSSL Mission

The Bouncy Castle and cryptlib 
projects have adopted the OpenSSL Mission and 
Values. Both projects are renowned cryptographic libraries that bring 
valuable expertise and resources to our mission, broadening the scope 
and impact of our work. Collaboration between the OpenSSL Library, 
Bouncy Castle, and cryptlib will benefit all our communities.


Support from the Foundation and the Corporation is available for all 
projects under the OpenSSL Mission on an opt-in (voluntary) basis.



Timeline and Future Plans

 *

   Business Advisory Committees for both entities will be established
   at the end of October 2024.

 *

   Technical Advisory Committees will be established by the end of
   April 2025.

 *

   The OpenSSL Technical Committee will be dissolved after establishing
   all the business and technical advisory committees.

 *

   An OpenSSL user conference in Europe will be held in the last
   quarter of 2025.

For more detailed information about these changes, including the current 
board of directors and advisory committees, visit our Blog 
.


If you have any questions or comments, reach out at mar...@openssl.org 
.


Thank you for your continued support and we look forward to working 
together as we redefine our work practices and empower our communities 
to shape the future of OpenSSL.


Best regards,

Kajal Sapkota*

*Marketing and Communications SpecialistOpenSSL teamka...@openssl.org*

Join Our Exclusive Webinar on Performance Tuning and Fetching with OpenSSL

[Kajal Sapkota]

*

Secure communication is vital in today's digital world, but it sometimes 
slows down your applications. We invite you to an insightful webinar on 
optimizing application performance using OpenSSL. This session is 
designed for individuals seeking to enhance the security and efficiency 
of their applications.



   Webinar Details:

Date:August 1, 2024Time:09:00 AM Pacific Time (US and 
Canada)Platform:ZoomTopic:Performance Tuning and Fetching with OpenSSL


Registration Link:Click here to register 




   Webinar Summary:

This webinar will address key techniques for accelerating secure 
communication within your applications. Topics will include:


 *

   Optimizing OpenSSL Build Time Options:Strategies for efficient
   OpenSSL configuration.

 *

   Enhancing OpenSSL Provider Support Performance:Methods to reclaim
   and maximize performance.

 *

   TLS Optimization:Insights into session caching, key exchange
   configuration, and cipher suite selection.

 *

   Practical Examples and Benchmarks:Real-life case studies
   illustrating the impact of these optimizations.

A live Q session will follow the presentation, providing an 
opportunity for direct interaction with our experts.



   Registration:

Ensure your place in this webinar by registering today:

Register Now 



Join us to learn how to keep your app both fast and secure. We look 
forward to seeing you there.


For more information email us at feedb...@openssl.org 
*

RE: compile openssl for Arm A9 & VxWorks

[Damodhar Boddukuri via openssl-users]

Hi,

Thank you for the support.

I am trying to compile “openSSL cross compilation for target "vxworks-armv7a" 
in Windows platform”:

The target compiler is ccarm.exe

Approach-1:
In Linux platform, Added the following target details in 10-main.conf file and 
ran the ./config . It generated the configdata.pm, 
configdata.pm, Makefile.in, Makefile, include/openssl/configuration.h files for 
the target "vxworks-armv7a". When I run the make, it generating the required 
files with perl script, But its unable to invoke the compiler ccarm.exe because 
it’s a .exe file.

When I move entire source-code to windows platform try to run the make, its 
giving errors in the perl script.


"vxworks-armv7a" => {
inherit_from => [ "BASE_unix" ],
 CC   => "ccarm",
CFLAGS   => '-g -fno-builtin -t7 -mfpu=vfp -mfloat-abi=softfp 
-ansi -fno-zero-initialized-in-bss -Wall -I$(TGT_DIR)/config/all -I$(TGT_DIR)/h 
-I$(WIND_HOME)/components/windml-5.3/h 
-I$(WIND_HOME)/components/webservices-1.8/h 
-I$(WIND_HOME)/components/webcli-4.9/target/h 
-I$(WIND_HOME)/components/tcf_agent-1.4/agent 
-I$(WIND_HOME)/components/stacktrace-1.0/include 
-I$(WIND_HOME)/components/opc-3.2/h -I$(WIND_HOME)/components/dcom-2.3/h 
-I$(WIND_HOME)/components/cafe-0.1/hpc/include 
-I$(WIND_HOME)/components/cafe-0.1/cafe/include 
-I$(WIND_HOME)/components/ip_net2-6.9/ipcom/config 
-I$(WIND_HOME)/components/cafe-0.1/vxworks/include 
-I$(WIND_HOME)/components/windml-5.3/osconfig/vxworks/src 
-I$(WIND_HOME)/components/tcf_agent-1.4/osconfig/vxworks/src 
-I$(WIND_HOME)/components/stacktrace-1.0/osconfig/vxworks/src 
-I$(WIND_HOME)/components/ip_net2-6.9/osconfig/vxworks/src 
-I$(WIND_HOME)/components/cafe-0.1/osconfig/vxworks/src 
-I$(WIND_HOME)/components/windml-5.3/osconfig/vxworks/h 
-I$(WIND_HOME)/components/tcf_agent-1.4/osconfig/vxworks/h 
-I$(WIND_HOME)/components/stacktrace-1.0/osconfig/vxworks/h 
-I$(WIND_HOME)/components/ip_net2-6.9/osconfig/vxworks/h 
-I$(WIND_HOME)/components/cafe-0.1/osconfig/vxworks/h -I$(TGT_DIR)/src/hwif 
-I$(TGT_DIR)/src/hwif/h -I $(TGT_DIR)/3rdparty/pbcl/h -I. 
-I$(TGT_DIR)/h/wrn/coreip -I$(TGT_DIR)/src/config -I$(TGT_DIR)/config/comps/src 
-I$(TGT_DIR)/config/comps/src/dosfs2 -I$(TGT_DIR)/src/drv 
-I$(TGT_DIR)/src/hwif/h -DCPU=_VX_ARMARCH7 -DTOOL_FAMILY=gnu -DTOOL=gnu 
-D_WRS_KERNEL -DARMEL -DCPU_CORTEXA8 -DARMMMU=ARMMMU_CORTEXA8 
-DARMCACHE=ARMCACHE_CORTEXA8 -DIP_PORT_VXWORKS=69 -DINET -D_WRS_VX_SMP 
-D_VSB_CONFIG_FILE=\"$(VSB_CONFIG_FILE)\" -I$(VSB_INCLUDE_DIR)',
cflags   => '-g -fno-builtin -t7 -mfpu=vfp -mfloat-abi=softfp 
-ansi -fno-zero-initialized-in-bss -Wall -I$(TGT_DIR)/config/all -I$(TGT_DIR)/h 
-I$(WIND_HOME)/components/windml-5.3/h 
-I$(WIND_HOME)/components/webservices-1.8/h 
-I$(WIND_HOME)/components/webcli-4.9/target/h 
-I$(WIND_HOME)/components/tcf_agent-1.4/agent 
-I$(WIND_HOME)/components/stacktrace-1.0/include 
-I$(WIND_HOME)/components/opc-3.2/h -I$(WIND_HOME)/components/dcom-2.3/h 
-I$(WIND_HOME)/components/cafe-0.1/hpc/include 
-I$(WIND_HOME)/components/cafe-0.1/cafe/include 
-I$(WIND_HOME)/components/ip_net2-6.9/ipcom/config 
-I$(WIND_HOME)/components/cafe-0.1/vxworks/include 
-I$(WIND_HOME)/components/windml-5.3/osconfig/vxworks/src 
-I$(WIND_HOME)/components/tcf_agent-1.4/osconfig/vxworks/src 
-I$(WIND_HOME)/components/stacktrace-1.0/osconfig/vxworks/src 
-I$(WIND_HOME)/components/ip_net2-6.9/osconfig/vxworks/src 
-I$(WIND_HOME)/components/cafe-0.1/osconfig/vxworks/src 
-I$(WIND_HOME)/components/windml-5.3/osconfig/vxworks/h 
-I$(WIND_HOME)/components/tcf_agent-1.4/osconfig/vxworks/h 
-I$(WIND_HOME)/components/stacktrace-1.0/osconfig/vxworks/h 
-I$(WIND_HOME)/components/ip_net2-6.9/osconfig/vxworks/h 
-I$(WIND_HOME)/components/cafe-0.1/osconfig/vxworks/h -I$(TGT_DIR)/src/hwif 
-I$(TGT_DIR)/src/hwif/h -I $(TGT_DIR)/3rdparty/pbcl/h -I. 
-I$(TGT_DIR)/h/wrn/coreip -I$(TGT_DIR)/src/config -I$(TGT_DIR)/config/comps/src 
-I$(TGT_DIR)/config/comps/src/dosfs2 -I$(TGT_DIR)/src/drv 
-I$(TGT_DIR)/src/hwif/h -DCPU=_VX_ARMARCH7 -DTOOL_FAMILY=gnu -DTOOL=gnu 
-D_WRS_KERNEL -DARMEL -DCPU_CORTEXA8 -DARMMMU=ARMMMU_CORTEXA8 
-DARMCACHE=ARMCACHE_CORTEXA8 -DIP_PORT_VXWORKS=69 -DINET -D_WRS_VX_SMP 
-D_VSB_CONFIG_FILE=\"$(VSB_CONFIG_FILE)\" -I$(VSB_INCLUDE_DIR)',
cppflags => combine('-g -fno-builtin -t7 -mfpu=vfp 
-mfloat-abi=softfp -ansi -fno-zero-initialized-in-bss -Wall 
-I$(TGT_DIR)/config/all -I$(TGT_DIR)/h -I$(WIND_HOME)/components/windml-5.3/h 
-I$(WIND_HOME)/components/webservices-1.8/h 
-I$(WIND_HOME)/components/webcli-4.9/target/h 
-I$(WIND_HOME)/components/tcf_agent-1.4/agent 
-I$(WIND_HOME)/components/stacktrace-1.0/include 
-I$(WIND_HOME)/components/opc-3.2/h -I$(WIND_HOME)/components/dcom-2.3/h 
-I$(WIND_HOME)/components/cafe-0.1/hpc/include 
-I$(WIND_HOME)/components/cafe-0.1/cafe/include 
-I$(WIND_HOME)/components/ip_net2-6.9/ipcom/config 
-I$(WIND_HOME)/components/cafe-0.1/vxworks/include 

Can I set the names of the DLLs/LIBs created during the build?

[BENTLEY Thom via openssl-users]

I want to have debug and optimized DLLs/LIBs for use by developers who need 
them to link their or open source code.
I can manually rename the LIBs, but I can't rename the DLLs since the LIBs 
provide the original name of the DLLs.

Any suggestions?  I know that the DCMTK team built their own DLLs and LIBS for 
OpenSSL 1.1.1w and they were able to do it.
I'm not sure what they did.  I've looked in the doc, but haven't noticed 
anything.

Thanks.



Thom Bentley | Senior Software Engineer | Medidata, a Dassault Systèmes 
company


This email and any attachments are intended solely for the use of the 
individual or entity to whom it is addressed and may be confidential and/or 
privileged.

If you are not one of the named recipients or have received this email in error,

(i) you should not read, disclose, or copy it,

(ii) please notify sender of your receipt by reply email and delete this email 
and all attachments,

(iii) Dassault Systèmes does not accept or assume any liability or 
responsibility for any use of or reliance on this email.


Please be informed that your personal data are processed according to our data 
privacy policy as described on our website. Should you have any questions 
related to personal data protection, please contact 3DS Data Protection Officer 
https://www.3ds.com/privacy-policy/contact/

Re: Own HW Supported RSA provider

[Selva Nair]

On Fri, Jul 19, 2024 at 4:55 PM tomasz bartczak  wrote:

> If I use the crypto library I can provide desired properties like in
> EVP_ASYM_CIPHER_fetch function. However when I use the ssl library, how to
> make sure it calls the mentioned EVP_ASYM_CIPHER_fetch function with
> properties required by me?
>

You can set a property query while creating the SSL context using
SSL_CTX_new_ex(). Or set it on  the libctx using
EVP_set_default_properties().

That said, what you are trying to do may work with no need for
property queries or even with "?provider=default" to prefer "default" when
possible. When the private key is loaded using your provider and the *key
is not exportable*, your provider will get called for signature operation.

See the link below for a test program on how even "?provider=default" in
the signing context fetches the correct signature operation for a key in a
different provider. It also has the rudiments of an external key signing
provider:

https://gist.github.com/selvanair/e4fd5fec6316fe894ad0fbaac68f4355
OR
https://github.com/openssl/openssl/commit/dd292ed62cc5d3eb0c529aa51a07ec1ed34a9a5f

Selva

Re: Building x32 libraries on x64 windows machine

[Neil Horman]

This error:
fatal error LNK1112: module machine type 'x64' conflicts with target
machine type 'x86'

says that you're set up for using x64 native tools, despite indicating you
have opened the x86 native tool command

Try running
vcvarsall.bat x32

Which should force your environment to build in 32 bit mode

Its also possible that you need to run make distclean again.  If you had
leftover 64 bit objects in your tree, this error would be the result

On Fri, Jul 19, 2024 at 3:48 PM BENTLEY Thom via openssl-users <
openssl-users@openssl.org> wrote:

> Hi All,
>
> I trying to build openssl 3.0.8  to generate x32/win32 libraries and
> header files.
> I used the following steps:
> Opened the x86 Native Tools Command Prompt  (Sets the environment to use
> 32-bit, x86-native tools to build 32-bit, x86-native code)
> perl Configure --debug --openssldir="C:\OpenSSLW32\CommonFiles\SSL"
> --prefix=C:\OpenSSLW32 VC-WIN32
>
> nmake
>
>
>
> However, I get the following error.
>
>
>
>cmd /C ""cl" /Zs /showIncludes  /Zi /Fdossl_static.pdb /Gs0 /GF /Gy
> /MDd /W3 /wd4090 /nologo /Od -I"." -I"include" -I"apps\include"
> -D"L_ENDIAN" -D"OPENSSL_PIC"
> -D"OPENSSLDIR=\"C:\\OpenSSLW32\\CommonFiles\\SSL\""
> -D"ENGINESDIR=\"C:\\OpenSSLW32\\lib\\engines-3\""
> -D"MODULESDIR=\"C:\\OpenSSLW32\\lib\\ossl-modules\""
> -D"OPENSSL_BUILDING_OPENSSL" -D"OPENSSL_SYS_WIN32" -D"WIN32_LEAN_AND_MEAN"
> -D"UNICODE" -D"_UNICODE" -D"_CRT_SECURE_NO_DEPRECATE"
> -D"_WINSOCK_DEPRECATED_NO_WARNINGS" -D"DEBUG" -D"_DEBUG"
> "apps\lib\tlssrp_depr.c" > apps\lib\libapps-lib-tlssrp_depr.d 2>&1"
>
> "lib" /nologo /out:apps\libapps.lib
> @C:\Users\user\AppData\Local\Temp\1\nmB79E.tmp
>
> apps\lib\libapps-lib-fmt.obj : fatal error LNK1112: module machine type
> 'x64' conflicts with target machine type 'x86'
>
> NMAKE : fatal error U1077: '"lib" /nologo /out:apps\libapps.lib
> @C:\Users\user\AppData\Local\Temp\1\nmB79E.tmp' : return code '0x458'
>
> Stop.
>
> NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual
> Studio\2022\Professional\VC\Tools\MSVC\14.38.33130\bin\HostX86\x86\nmake.exe"
> /   _build_sw' : return code '0x2'
>
> Stop.
>
>
>
> I also tried the x64_x86 Cross Tools Command Prompt - Sets the environment
> to use 64-bit, x64-native tools to build 32-bit, x86-native code.  That
> gave the same error.
>
>
>
> I would have expected that setup to be able to build the win32 version of
> the objects and libraries.
>
> What did I miss or is this not supported?
>
> Thanks.
>
>
>
> P.S.  This all worked fine when I setup to build x64.  Not errors and got
> libs and objects for x64.
>
>
>
>
>
> *Thom Bentley *| Senior Software Engineer | Medidata, a Dassault Systèmes
> company 
>
>
>
> This email and any attachments are intended solely for the use of the
> individual or entity to whom it is addressed and may be confidential and/or
> privileged.
>
> If you are not one of the named recipients or have received this email in
> error,
>
> (i) you should not read, disclose, or copy it,
>
> (ii) please notify sender of your receipt by reply email and delete this
> email and all attachments,
>
> (iii) Dassault Systèmes does not accept or assume any liability or
> responsibility for any use of or reliance on this email.
>
> Please be informed that your personal data are processed according to our
> data privacy policy as described on our website. Should you have any
> questions related to personal data protection, please contact 3DS Data
> Protection Officer https://www.3ds.com/privacy-policy/contact/
>
>
>

RE: Building x32 libraries on x64 windows machine

[BENTLEY Thom via openssl-users]

Sorry.  Friday afternoon brain.
Forgot to do a `nmake clean`




Thom Bentley | Senior Software Engineer | Medidata, a Dassault Systèmes 
company

From: BENTLEY Thom
Sent: Friday, July 19, 2024 3:48 PM
To: openssl-users@openssl.org
Subject: Building x32 libraries on x64 windows machine

Hi All,

I trying to build openssl 3.0.8  to generate x32/win32 libraries and header 
files.
I used the following steps:
Opened the x86 Native Tools Command Prompt  (Sets the environment to use 
32-bit, x86-native tools to build 32-bit, x86-native code)
perl Configure --debug --openssldir="C:\OpenSSLW32\CommonFiles\SSL" 
--prefix=C:\OpenSSLW32 VC-WIN32
nmake

However, I get the following error.

   cmd /C ""cl" /Zs /showIncludes  /Zi /Fdossl_static.pdb /Gs0 /GF /Gy /MDd 
/W3 /wd4090 /nologo /Od -I"." -I"include" -I"apps\include" -D"L_ENDIAN" 
-D"OPENSSL_PIC" -D"OPENSSLDIR=\"C:\\OpenSSLW32\\CommonFiles\\SSL\"" 
-D"ENGINESDIR=\"C:\\OpenSSLW32\\lib\\engines-3\"" 
-D"MODULESDIR=\"C:\\OpenSSLW32\\lib\\ossl-modules\"" 
-D"OPENSSL_BUILDING_OPENSSL" -D"OPENSSL_SYS_WIN32" -D"WIN32_LEAN_AND_MEAN" 
-D"UNICODE" -D"_UNICODE" -D"_CRT_SECURE_NO_DEPRECATE" 
-D"_WINSOCK_DEPRECATED_NO_WARNINGS" -D"DEBUG" -D"_DEBUG"   
"apps\lib\tlssrp_depr.c" > apps\lib\libapps-lib-tlssrp_depr.d 2>&1"
"lib" /nologo /out:apps\libapps.lib 
@C:\Users\user\AppData\Local\Temp\1\nmB79E.tmp
apps\lib\libapps-lib-fmt.obj : fatal error LNK1112: module machine type 'x64' 
conflicts with target machine type 'x86'
NMAKE : fatal error U1077: '"lib" /nologo /out:apps\libapps.lib 
@C:\Users\user\AppData\Local\Temp\1\nmB79E.tmp' : return code '0x458'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual 
Studio\2022\Professional\VC\Tools\MSVC\14.38.33130\bin\HostX86\x86\nmake.exe" / 
  _build_sw' : return code '0x2'
Stop.

I also tried the x64_x86 Cross Tools Command Prompt - Sets the environment to 
use 64-bit, x64-native tools to build 32-bit, x86-native code.  That gave the 
same error.

I would have expected that setup to be able to build the win32 version of the 
objects and libraries.
What did I miss or is this not supported?
Thanks.

P.S.  This all worked fine when I setup to build x64.  Not errors and got libs 
and objects for x64.


Thom Bentley | Senior Software Engineer | Medidata, a Dassault Systèmes 
company


This email and any attachments are intended solely for the use of the 
individual or entity to whom it is addressed and may be confidential and/or 
privileged.

If you are not one of the named recipients or have received this email in error,

(i) you should not read, disclose, or copy it,

(ii) please notify sender of your receipt by reply email and delete this email 
and all attachments,

(iii) Dassault Systèmes does not accept or assume any liability or 
responsibility for any use of or reliance on this email.


Please be informed that your personal data are processed according to our data 
privacy policy as described on our website. Should you have any questions 
related to personal data protection, please contact 3DS Data Protection Officer 
https://www.3ds.com/privacy-policy/contact/

Building x32 libraries on x64 windows machine

[BENTLEY Thom via openssl-users]

Hi All,

I trying to build openssl 3.0.8  to generate x32/win32 libraries and header 
files.
I used the following steps:
Opened the x86 Native Tools Command Prompt  (Sets the environment to use 
32-bit, x86-native tools to build 32-bit, x86-native code)
perl Configure --debug --openssldir="C:\OpenSSLW32\CommonFiles\SSL" 
--prefix=C:\OpenSSLW32 VC-WIN32
nmake

However, I get the following error.

   cmd /C ""cl" /Zs /showIncludes  /Zi /Fdossl_static.pdb /Gs0 /GF /Gy /MDd 
/W3 /wd4090 /nologo /Od -I"." -I"include" -I"apps\include" -D"L_ENDIAN" 
-D"OPENSSL_PIC" -D"OPENSSLDIR=\"C:\\OpenSSLW32\\CommonFiles\\SSL\"" 
-D"ENGINESDIR=\"C:\\OpenSSLW32\\lib\\engines-3\"" 
-D"MODULESDIR=\"C:\\OpenSSLW32\\lib\\ossl-modules\"" 
-D"OPENSSL_BUILDING_OPENSSL" -D"OPENSSL_SYS_WIN32" -D"WIN32_LEAN_AND_MEAN" 
-D"UNICODE" -D"_UNICODE" -D"_CRT_SECURE_NO_DEPRECATE" 
-D"_WINSOCK_DEPRECATED_NO_WARNINGS" -D"DEBUG" -D"_DEBUG"   
"apps\lib\tlssrp_depr.c" > apps\lib\libapps-lib-tlssrp_depr.d 2>&1"
"lib" /nologo /out:apps\libapps.lib 
@C:\Users\user\AppData\Local\Temp\1\nmB79E.tmp
apps\lib\libapps-lib-fmt.obj : fatal error LNK1112: module machine type 'x64' 
conflicts with target machine type 'x86'
NMAKE : fatal error U1077: '"lib" /nologo /out:apps\libapps.lib 
@C:\Users\user\AppData\Local\Temp\1\nmB79E.tmp' : return code '0x458'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual 
Studio\2022\Professional\VC\Tools\MSVC\14.38.33130\bin\HostX86\x86\nmake.exe" / 
  _build_sw' : return code '0x2'
Stop.

I also tried the x64_x86 Cross Tools Command Prompt - Sets the environment to 
use 64-bit, x64-native tools to build 32-bit, x86-native code.  That gave the 
same error.

I would have expected that setup to be able to build the win32 version of the 
objects and libraries.
What did I miss or is this not supported?
Thanks.

P.S.  This all worked fine when I setup to build x64.  Not errors and got libs 
and objects for x64.


Thom Bentley | Senior Software Engineer | Medidata, a Dassault Systèmes 
company


This email and any attachments are intended solely for the use of the 
individual or entity to whom it is addressed and may be confidential and/or 
privileged.

If you are not one of the named recipients or have received this email in error,

(i) you should not read, disclose, or copy it,

(ii) please notify sender of your receipt by reply email and delete this email 
and all attachments,

(iii) Dassault Systèmes does not accept or assume any liability or 
responsibility for any use of or reliance on this email.


Please be informed that your personal data are processed according to our data 
privacy policy as described on our website. Should you have any questions 
related to personal data protection, please contact 3DS Data Protection Officer 
https://www.3ds.com/privacy-policy/contact/

Re: Own HW Supported RSA provider

[tomasz bartczak]

Hi Levitte,Thanks for your answer. Just follow up question.If I use the 
crypto library I can provide desired properties like in EVP_ASYM_CIPHER_fetch 
function. However when I use the ssl library, how to make sure it calls the 
mentioned EVP_ASYM_CIPHER_fetch function with properties required by 
me?RegardsTomTemat: Own HW Supported RSA providerData: 2024-07-18 15:25Nadawca: 
"tomasz bartczak" tbar...@poczta.fmAdresat: openssl-users@openssl.org; 
 Hi,
 I want to implement my own provider that enables RSA encryption using
a HW chip. OpenSSL already comes with default provider that provides RSA
implementation. Could you please explain to me how to add my own provider
and make sure it is selected over the one from default provider and still
have access to other algorithms that come with the default provider.
 Thanks
 Tom
 

Re: Own HW Supported RSA provider

[Richard Levitte]

You can give your implementation the property "provider=myname" and for
fetching, you can use the conditional property query string
"?provider=myname".  That will ensure that, for whatever the app is
fetching, it will pick what your provider offers first, and fall back to
using stuff from any other provider (including the default provider).

"myname" can be anything you like

On Thu, Jul 18, 2024 at 3:25 PM tomasz bartczak  wrote:

> Hi,
> I want to implement my own provider that enables RSA encryption using a HW
> chip. OpenSSL already comes with default provider that provides RSA
> implementation. Could you please explain to me how to add my own provider
> and make sure it is selected over the one from default provider and still
> have access to other algorithms that come with the default provider.
> Thanks
> Tom
>

Own HW Supported RSA provider

[tomasz bartczak]

Hi,
I want to implement my own provider that enables RSA encryption using a HW 
chip. OpenSSL already comes with default provider that provides RSA 
implementation. Could you please explain to me how to add my own provider and 
make sure it is selected over the one from default provider and still have 
access to other algorithms that come with the default provider.
Thanks
Tom

OpenSSL Mailing Lists Are Moving to Google Groups

[Dmitry Misharov]

We are announcing a change in how communication and collaboration will take
place within
the OpenSSL community. Effective August 1st, 2024, the OpenSSL mailing
lists will migrate
to Google Groups. This transition is designed to streamline communication
channels and
simplify our infrastructure.

## Why the change?

Over the years, the combination of Postfix and Mailman has served us well,
but it's time to move on
and explore better options. Google Groups offers several advantages that
align with our goals:

* **Enhanced Collaboration**: in addition to email Google Groups provides a
modern interface and a
  more intuitive user experience, making it easier for community members to
engage in discussions,
  share ideas, and contribute to ongoing projects.

* **Simplified Management**: by migrating to Google Groups, we can reduce
the administrative
  overhead associated with maintaining our mailing list infrastructure.
This allows our team to
  focus more on developing and improving the OpenSSL library.

* **Improved Accessibility**: Google Groups offers robust search
capabilities, better spam
  protection, and easy access to archives, ensuring that valuable
information is readily available
  and easily searchable.

## What you need to know

The official migration will take place on **August 1st, 2024**. After this
date, the MTA hostname
will take place in Google Groups. The mailing lists archives
on https://mta.openssl.org will be preserved and stay online but will not be
updated.

Current subscribers to our mailing lists will be automatically migrated to
the new Google Groups.
You will receive an invitation to join the respective Google Group(s)
corresponding to your existing
subscriptions.

You do not have to have a Google account to interact with Google Groups.
You can
subscribe and unsubscribe purely via email from any address.

## Looking ahead

This migration marks a positive step forward in enhancing our community
engagement and
support. Thank you for your continued support and contributions to the
OpenSSL project.

Best regards,
The OpenSSL Team

Re: sqlog partial

[jean-frederic clere]

On 7/18/24 10:04 AM, Tomas Mraz wrote:

You could try calling fcloseall() before the exit() call.


That doesn't help. In fact I have changed ssl/quic/qlog.c:
 static void qlog_event_epilogue(QLOG *qlog)
 {
+int ret;
 ossl_json_object_end(>json);

 ossl_json_key(>json, "time");
@@ -390,6 +391,11 @@ static void qlog_event_epilogue(QLOG *qlog)
 }

 ossl_json_object_end(>json);
+ossl_qlog_flush(qlog); /* best effort */
+ret = BIO_flush(qlog->bio);
+if (ret) {
+  printf("rate!\n");
+}
 }

Now I have my trace:
+++
{"packet_type":"1RTT","packet_number":9,"dcid":"868bbbcafeca0b7b"},"datagram_id":7,"frames":[{"frame_type":"ack","ack_delay":0,"acked_ranges":[[0,5]],"length":5}]},"time":1}
^^{"name":"transport:packet_received","data":{"header":{"packet_type":"1RTT","packet_number":10,"dcid":"868bbbcafeca0b7b"},"datagram_id":8,"frames":[{"frame_type":"ack","ack_delay":0,"acked_ranges":[[0,7]],"length":5}]},"time":0}
^^{"name":"transport:packet_received","data":{"header":{"packet_type":"1RTT","packet_number":11,"dcid":"868bbbcafeca0b7b"},"datagram_id":9,"frames":[{"frame_type":"stream","stream_id":2,"offset":58,"payload_length":12,"explicit_length":true,"length":4}]},"time":12840}
+++
So chrome is sending a setting which the ossl-nghttp3-demo-server 
doesn't like :-(




Tomas Mraz, OpenSSL

On Wed, 2024-07-17 at 20:30 +0200, jean-frederic clere wrote:

Hi,

I have built with enable-unstable-qlog, but when I exit (via exit(1))
the sqlog files are truncated:
+++
^^{"name":"transport:packet_received","data":{"header":{"packet_type"
:"1RTT","packet_number":5,"dcid":"1f6cb8c5033c1937"},"datagram_id":3,
"frames":[{"frame_type":"stream","stream_id":2,"offset":0,"payload_le
ngth":0,"explicit_length":false,"length":2}]},"time":0}
^^{"name":"transport:packet_received","data":{"header":{"packet_type"
:"1RTT","packet_number":6,"dcid":"1f6cb8c5033c1937"},"datagram_id":4,
"frames":[{"frame_type":"stream","stream_id":2,"offset":45,"payload_l
ength":12,"explicit_length":true,"length":4}]},"time":0}
^^{"name":"transport:packet_sen
+++
Is there a way to write the files before exiting?





--
Cheers

Jean-Frederic

Re: sqlog partial

[Tomas Mraz]

You could try calling fcloseall() before the exit() call.

Tomas Mraz, OpenSSL

On Wed, 2024-07-17 at 20:30 +0200, jean-frederic clere wrote:
> Hi,
> 
> I have built with enable-unstable-qlog, but when I exit (via exit(1))
> the sqlog files are truncated:
> +++
> ^^{"name":"transport:packet_received","data":{"header":{"packet_type"
> :"1RTT","packet_number":5,"dcid":"1f6cb8c5033c1937"},"datagram_id":3,
> "frames":[{"frame_type":"stream","stream_id":2,"offset":0,"payload_le
> ngth":0,"explicit_length":false,"length":2}]},"time":0}
> ^^{"name":"transport:packet_received","data":{"header":{"packet_type"
> :"1RTT","packet_number":6,"dcid":"1f6cb8c5033c1937"},"datagram_id":4,
> "frames":[{"frame_type":"stream","stream_id":2,"offset":45,"payload_l
> ength":12,"explicit_length":true,"length":4}]},"time":0}
> ^^{"name":"transport:packet_sen
> +++
> Is there a way to write the files before exiting?
> 

-- 
Tomáš Mráz, OpenSSL

Re: compile openssl for Arm A9 & VxWorks

[Neil Horman]

There are already several targets defined for vxworks.  First step I would
think would be cloning one of those targets in Configurations/10-main.conf
for your purposes and adjusting the settings accordingly:

"vxworks-ppc60x" => {<= Change this to "vxworks-arm9' or some such
inherit_from => [ "BASE_unix" ],<= Leave this alone I
imagine
CC   => "ccppc", <= set the appropriate compiler
command here
CFLAGS   => "-O2 -Wall -fstrength-reduce", <= For this and
below, adjust as needed
cflags   => "-mrtp -mhard-float -mstrict-align
-fno-implicit-fp -fno-builtin -fno-strict-aliasing",
cppflags => combine("-D_REENTRANT -DPPC32_fp60x
-DCPU=PPC32",
"_DTOOL_FAMILY=gnu -DTOOL=gnu",
"-I\$(WIND_BASE)/target/usr/h",

"-I\$(WIND_BASE)/target/usr/h/wrn/coreip"),
sys_id   => "VXWORKS", <= leave this alone
lflags   => add("-L
\$(WIND_BASE)/target/usr/lib/ppc/PPC32/common"), <= Set this to your
vxworks library path
ex_libs  => add("-Wl,--defsym,__wrs_rtp_base=0xe000"),
<= Probably leave this alone too
},

On Wed, Jul 17, 2024 at 12:42 PM Damodhar Boddukuri via openssl-users <
openssl-users@openssl.org> wrote:

> Hi openSSL users,
>
>
>
> I would like to port openssl for Arm A9 & VxWorks Target. If someone can
> share the details, Its really helpful for me.
>
>
>
> Thanks in advance.
>
>
>
>
>
> Thanks & Regards,
>
> Damodhar.
>
> +91-7702191212
>
>
>
> General
>

sqlog partial

[jean-frederic clere]

Hi,

I have built with enable-unstable-qlog, but when I exit (via exit(1)) 
the sqlog files are truncated:

+++
^^{"name":"transport:packet_received","data":{"header":{"packet_type":"1RTT","packet_number":5,"dcid":"1f6cb8c5033c1937"},"datagram_id":3,"frames":[{"frame_type":"stream","stream_id":2,"offset":0,"payload_length":0,"explicit_length":false,"length":2}]},"time":0}
^^{"name":"transport:packet_received","data":{"header":{"packet_type":"1RTT","packet_number":6,"dcid":"1f6cb8c5033c1937"},"datagram_id":4,"frames":[{"frame_type":"stream","stream_id":2,"offset":45,"payload_length":12,"explicit_length":true,"length":4}]},"time":0}
^^{"name":"transport:packet_sen
+++
Is there a way to write the files before exiting?

--
Cheers

Jean-Frederic

compile openssl for Arm A9 & VxWorks

[Damodhar Boddukuri via openssl-users]

Hi openSSL users,

I would like to port openssl for Arm A9 & VxWorks Target. If someone can share 
the details, Its really helpful for me.

Thanks in advance.


Thanks & Regards,
Damodhar.
+91-7702191212



General

ECDH Algoritm (Group 19)

[Damodhar Boddukuri via openssl-users]

Hi OpenSSL users,

We are planning to use ECDH Algorithm(Group 19) in an Embedded System Product 
for the shared secret key generation.
When I go through the code, I understand that it requires  engine 
libraries/files from the following folders:

\openssl-3_1_3\crypto\engine\
\openssl-3_1_3\engines\
\openssl-3_1_3\apps\lib\

When I am trying to generate shared secret key using following API's:
EC_GROUP_new_by_curve_name(NID_X9_62_prime256v1);
EC_KEY_new();
EC_KEY_set_group();
EC_KEY_generate_key();

These API's uses/Access assembly code(directly or indirectly) by following 
conditional compilation macros:
OPENSSL_NO_ENGINE
OPENSSL_NO_AUTOLOAD_CONFIG
OPENSSL_NO_RDRAND
OPENSSL_NO_PADLOCKENG
OPENSSL_NO_AFALGENG
OPENSSL_NO_STATIC_ENGINE

I have few questions in my mind:

  1.  Is it recommended to use ECDH Algorithm (Group 19) for an embedded 
product ? does ECDH (Group 19) requires any hardware support?
  2.  If ECDH Algorithm (Group 19) recommended, How will be the performance?
  3.  If ECDH Algorithm (Group 19) not recommended, What would be the simple & 
secure DH or ECDH algorithm for shared secret key generation?

Thanks for your help.

Thanks & Regards,
Damodhar.
+91-7702191212



General

Re: Application segfaults after upgrade from 3.0.11 to 3.0.13

[Tomas Mraz]

Please update to 3.0.14. The change that most likely caused this
regression for you was reverted in that release by the following pull
request: https://github.com/openssl/openssl/pull/23063

Tomas Mraz, OpenSSL

On Wed, 2024-07-17 at 08:47 +0300, Victor Wagner wrote:
> On Tue, 16 Jul 2024 14:40:59 -0400
> Neil Horman  wrote:
> 
> > Can you post the stack trace of the segv here?
> 
> Sure:
> 
> Core was generated by `osslsigncode sign -pkcs11module
> /usr/lib/librtpkcs11ecp.so -pkcs11cert pkcs11:o'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0  0x7fe9e87862d2 in pkcs11_getattr_var (
> --Type  for more, q to quit, c to continue without paging--
>     ctx=ctx@entry=0x9d33983bac913f76, session=session@entry=1,
>     object=object@entry=3292546510, type=type@entry=288,
>     value=value@entry=0x0, size=size@entry=0x7ffe166572f0)
>     at ./src/p11_attr.c:46
> 46  ./src/p11_attr.c: No such file or directory.
> (gdb) bt
> #0  0x7fe9e87862d2 in pkcs11_getattr_var (
>     ctx=ctx@entry=0x9d33983bac913f76, session=session@entry=1,
>     object=object@entry=3292546510, type=type@entry=288,
>     value=value@entry=0x0, size=size@entry=0x7ffe166572f0)
>     at ./src/p11_attr.c:46
> #1  0x7fe9e87863cc in pkcs11_getattr_alloc (
>     ctx=ctx@entry=0x9d33983bac913f76, session=1,
>     object=object@entry=3292546510, type=type@entry=288,
>     value=value@entry=0x7ffe16657348, size=size@entry=0x7ffe16657350)
>     at ./src/p11_attr.c:66
> #2  0x7fe9e87864e0 in pkcs11_getattr_bn
> (ctx=ctx@entry=0x9d33983bac913f76,
>     session=, object=object@entry=3292546510,
>     type=type@entry=288, bn=bn@entry=0x7ffe16657380) at
> ./src/p11_attr.c:92
> #3  0x7fe9e8788d77 in pkcs11_get_rsa (key=0x55c5c9711950)
>     at ./src/p11_rsa.c:197
> #4  0x7fe9e87896d3 in pkcs11_get_evp_key_rsa (key=0x55c5c9711950)
>     at ./src/p11_rsa.c:265
> #5  0x7fe9e8788222 in pkcs11_get_key
> (key0=key0@entry=0x55c5c9711950,
>     object_class=) at ./src/p11_key.c:450
> #6  0x7fe9e878933f in pkcs11_rsa (key=key@entry=0x55c5c9711950)
>     at ./src/p11_rsa.c:34
> #7  pkcs11_get_key_size (key=key@entry=0x55c5c9711950) at
> ./src/p11_rsa.c:332
> #8  0x7fe9e87893c4 in pkcs11_private_encrypt (flen=51,
>     from=0x55c5c96e9e60 "010\r\006\t`\206H\001e\003\004\002\001\005",
>     to=0x55c5c969f8f0 "\377\3613\225\300U", key=0x55c5c9711950,
> padding=1)
>     at ./src/p11_rsa.c:91
> #9  0x7fe9e847f9bd in RSA_sign (type=,
>     m=m@entry=0x7ffe166578b0
> "\266\307O\326\361\367\033\262\357\t,U\220\032\002E\207\342o
> \352e̝\350\257\342o/\255", ,
>     m_len=m_len@entry=32,
>     sigret=sigret@entry=0x55c5c969f8f0 "\377\3613\225\300U",
>     siglen=siglen@entry=0x7ffe16657844, rsa=rsa@entry=0x55c5c9711ac0)
>     at ../crypto/rsa/rsa_sign.c:309
> #10 0x7fe9e847e154 in pkey_rsa_sign (ctx=0x55c5c96bc0e0,
>     sig=0x55c5c969f8f0 "\377\3613\225\300U", siglen=0x7ffe16657950,
>     tbs=0x7ffe166578b0
> "\266\307O\326\361\367\033\262\357\t,U\220\032\002E\207\342o
> \352e̝\350\257\342o/\255", , tbslen=32)
>     at ../crypto/rsa/rsa_pmeth.c:176
> #11 0x7fe9e841648e in EVP_DigestSignFinal
> (ctx=ctx@entry=0x55c5c96a5a00,
>     sigret=0x55c5c969f8f0 "\377\3613\225\300U",
>     siglen=siglen@entry=0x7ffe16657950) at
> ../crypto/evp/m_sigver.c:560
> #12 0x7fe9e8460468 in PKCS7_SIGNER_INFO_sign
> (si=si@entry=0x55c5c96a8650)
>     at ../crypto/pkcs7/pk7_doit.c:945
> #13 0x7fe9e8460702 in do_pkcs7_signed_attrib
> (mctx=0x55c5c96a57d0,
>     si=0x55c5c96a8650) at ../crypto/pkcs7/pk7_doit.c:721
> #14 PKCS7_dataFinal (p7=p7@entry=0x55c5c96f39e0,
> bio=bio@entry=0x55c5c96a5620)
>     at ../crypto/pkcs7/pk7_doit.c:843
> #15 0x55c5c89f7490 in pkcs7_sign_content
> (p7=p7@entry=0x55c5c96f39e0,
>     data=0x55c5c97089c2
> "04\006\n+\006\001\004\001\2027\002\001\0170&\003\002\a\200\240
> \242\036\200\034", len=105) at ./helpers.c:397
> #16 0x55c5c89f75b1 in sign_spc_indirect_data_content (
>     p7=p7@entry=0x55c5c96f39e0, content=content@entry=0x55c5c96d5320)
>     at ./helpers.c:280
> #17 0x55c5c89fcfc9 in pe_pkcs7_signature_new (ctx= out>,
>     hash=0x55c5c96da260) at ./pe.c:407
> #18 0x55c5c89ee460 in main (argc=, argv= out>)
>     at ./osslsigncode.c:4955
> (gdb) q
> 
> Following debugger output may be also of interest:
> 
> (gdb) p *ctx
> Cannot access memory at address 0x9d33983bac913f76
> (gdb) up 3
> #3  0x7fe9e8788d77 in pkcs11_get_rsa (key=0x55c5c9711950)
>     at ./src/p11_rsa.c:197
> 197 ./src/p11_rsa.c: No such file or directory.
> (gdb) p *slot
> $1 = {refcnt = 1549571800, ctx = 0x9d33983bac913f76, lock = {__data =
> {
>   __lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0,
>   __spins = 0, __elision = 0, __list = {__prev = 0x0, __next =
> 0x0}}, 
>     __size = '\000' , __align = 0}, cond = {__data
> = {
> (gdb) dir /usr/src/debug/libp11-0.4.12
> Source directories searched: /usr/src/debug/libp11-0.4.12:$cdir:$cwd
> (gdb) l 185
> 180  */
> 181  

Re: Application segfaults after upgrade from 3.0.11 to 3.0.13

[Victor Wagner]

On Tue, 16 Jul 2024 14:40:59 -0400
Neil Horman  wrote:

> Can you post the stack trace of the segv here?

Sure:

Core was generated by `osslsigncode sign -pkcs11module 
/usr/lib/librtpkcs11ecp.so -pkcs11cert pkcs11:o'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x7fe9e87862d2 in pkcs11_getattr_var (
--Type  for more, q to quit, c to continue without paging--
ctx=ctx@entry=0x9d33983bac913f76, session=session@entry=1,
object=object@entry=3292546510, type=type@entry=288,
value=value@entry=0x0, size=size@entry=0x7ffe166572f0)
at ./src/p11_attr.c:46
46  ./src/p11_attr.c: No such file or directory.
(gdb) bt
#0  0x7fe9e87862d2 in pkcs11_getattr_var (
ctx=ctx@entry=0x9d33983bac913f76, session=session@entry=1,
object=object@entry=3292546510, type=type@entry=288,
value=value@entry=0x0, size=size@entry=0x7ffe166572f0)
at ./src/p11_attr.c:46
#1  0x7fe9e87863cc in pkcs11_getattr_alloc (
ctx=ctx@entry=0x9d33983bac913f76, session=1,
object=object@entry=3292546510, type=type@entry=288,
value=value@entry=0x7ffe16657348, size=size@entry=0x7ffe16657350)
at ./src/p11_attr.c:66
#2  0x7fe9e87864e0 in pkcs11_getattr_bn (ctx=ctx@entry=0x9d33983bac913f76,
session=, object=object@entry=3292546510,
type=type@entry=288, bn=bn@entry=0x7ffe16657380) at ./src/p11_attr.c:92
#3  0x7fe9e8788d77 in pkcs11_get_rsa (key=0x55c5c9711950)
at ./src/p11_rsa.c:197
#4  0x7fe9e87896d3 in pkcs11_get_evp_key_rsa (key=0x55c5c9711950)
at ./src/p11_rsa.c:265
#5  0x7fe9e8788222 in pkcs11_get_key (key0=key0@entry=0x55c5c9711950,
object_class=) at ./src/p11_key.c:450
#6  0x7fe9e878933f in pkcs11_rsa (key=key@entry=0x55c5c9711950)
at ./src/p11_rsa.c:34
#7  pkcs11_get_key_size (key=key@entry=0x55c5c9711950) at ./src/p11_rsa.c:332
#8  0x7fe9e87893c4 in pkcs11_private_encrypt (flen=51,
from=0x55c5c96e9e60 "010\r\006\t`\206H\001e\003\004\002\001\005",
to=0x55c5c969f8f0 "\377\3613\225\300U", key=0x55c5c9711950, padding=1)
at ./src/p11_rsa.c:91
#9  0x7fe9e847f9bd in RSA_sign (type=,
m=m@entry=0x7ffe166578b0 
"\266\307O\326\361\367\033\262\357\t,U\220\032\002E\207\342o 
\352e̝\350\257\342o/\255", ,
m_len=m_len@entry=32,
sigret=sigret@entry=0x55c5c969f8f0 "\377\3613\225\300U",
siglen=siglen@entry=0x7ffe16657844, rsa=rsa@entry=0x55c5c9711ac0)
at ../crypto/rsa/rsa_sign.c:309
#10 0x7fe9e847e154 in pkey_rsa_sign (ctx=0x55c5c96bc0e0,
sig=0x55c5c969f8f0 "\377\3613\225\300U", siglen=0x7ffe16657950,
tbs=0x7ffe166578b0 
"\266\307O\326\361\367\033\262\357\t,U\220\032\002E\207\342o 
\352e̝\350\257\342o/\255", , tbslen=32)
at ../crypto/rsa/rsa_pmeth.c:176
#11 0x7fe9e841648e in EVP_DigestSignFinal (ctx=ctx@entry=0x55c5c96a5a00,
sigret=0x55c5c969f8f0 "\377\3613\225\300U",
siglen=siglen@entry=0x7ffe16657950) at ../crypto/evp/m_sigver.c:560
#12 0x7fe9e8460468 in PKCS7_SIGNER_INFO_sign (si=si@entry=0x55c5c96a8650)
at ../crypto/pkcs7/pk7_doit.c:945
#13 0x7fe9e8460702 in do_pkcs7_signed_attrib (mctx=0x55c5c96a57d0,
si=0x55c5c96a8650) at ../crypto/pkcs7/pk7_doit.c:721
#14 PKCS7_dataFinal (p7=p7@entry=0x55c5c96f39e0, bio=bio@entry=0x55c5c96a5620)
at ../crypto/pkcs7/pk7_doit.c:843
#15 0x55c5c89f7490 in pkcs7_sign_content (p7=p7@entry=0x55c5c96f39e0,
data=0x55c5c97089c2 
"04\006\n+\006\001\004\001\2027\002\001\0170&\003\002\a\200\240 
\242\036\200\034", len=105) at ./helpers.c:397
#16 0x55c5c89f75b1 in sign_spc_indirect_data_content (
p7=p7@entry=0x55c5c96f39e0, content=content@entry=0x55c5c96d5320)
at ./helpers.c:280
#17 0x55c5c89fcfc9 in pe_pkcs7_signature_new (ctx=,
hash=0x55c5c96da260) at ./pe.c:407
#18 0x55c5c89ee460 in main (argc=, argv=)
at ./osslsigncode.c:4955
(gdb) q

Following debugger output may be also of interest:

(gdb) p *ctx
Cannot access memory at address 0x9d33983bac913f76
(gdb) up 3
#3  0x7fe9e8788d77 in pkcs11_get_rsa (key=0x55c5c9711950)
at ./src/p11_rsa.c:197
197 ./src/p11_rsa.c: No such file or directory.
(gdb) p *slot
$1 = {refcnt = 1549571800, ctx = 0x9d33983bac913f76, lock = {__data = {
  __lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, 
  __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, 
__size = '\000' , __align = 0}, cond = {__data = {
(gdb) dir /usr/src/debug/libp11-0.4.12
Source directories searched: /usr/src/debug/libp11-0.4.12:$cdir:$cwd
(gdb) l 185
180  */
181 static RSA *pkcs11_get_rsa(PKCS11_OBJECT_private *key)
182 {
183 CK_OBJECT_CLASS class_public_key = CKO_PUBLIC_KEY;
184 PKCS11_SLOT_private *slot = key->slot;
185 PKCS11_CTX_private *ctx = slot->ctx;
186 PKCS11_OBJECT_private *pubkey;
187 PKCS11_TEMPLATE tmpl = {0};
188 CK_OBJECT_HANDLE object = key->object;
189 CK_SESSION_HANDLE session;


> 
> On Tue, Jul 16, 2024 at 12:43 PM Victor Wagner 
> 

Re: Application segfaults after upgrade from 3.0.11 to 3.0.13

[Neil Horman]

Can you post the stack trace of the segv here?

On Tue, Jul 16, 2024 at 12:43 PM Victor Wagner  wrote:

> Hi!
>
> I'm using osslsigncode application on Debian 12 system (amd64) to sign
> stuff with RSA key stored on hardware token with PKCS11 interface.
>
> osslsigncode (https://github.com/mtrojnar/osslsigncode) seems to be
> well-behaved openssl application, which uses digest BIO and PKCS7 API,
> does no poking into opaque structures etc.
>
> Application was compiled from source in February, when openssl version
> in Debian was 3.0.11-1~deb12u1
>
> Unfortunately, when security update of libssl3 (debian package for
> openssl libraries) version 3.0.13-1~deb12u1 was installed, osslsigncode
> begin to crash with SIGSEGV.
>
> Quick debugging session shows that application is able to initialize
> token and correctly obtain private key handle and certificate for it.
> But when trying to sign, it receives invalid pointer to
> PKCS11_CTX_private structure. (segfault happens inside pkcs11.so)
> This pointer is contained in PKCS11_SLOT_private structure, which
> has refcount field before this pointer, and this field also seems to be
> filled with garbage (i expect refcount to be less than 10 in so small
> program, which handles just one signature and it is some 32-bit value
> with second high order bit set).
>
> Downgrade to previous version of openssl libraries fixes the problem.
>
> I suspect that problem is in application, which somehow misuses openssl
> API but have no idea how to look for problem. Really, it seems to to be
> good idea to track memory writes to PKCS11_SLOT object, but it is
> hidden inside so many levels of opaque structures.
>
> I've thought about checking what change in openssl may affect problem,
> but don't see anything appropriate in changelog between 3.0.11 and
> 3.0.13 (and debian maintainers seems to add nothing new over upstream
> changes).
> --
>

Application segfaults after upgrade from 3.0.11 to 3.0.13

[Victor Wagner]

Hi!

I'm using osslsigncode application on Debian 12 system (amd64) to sign
stuff with RSA key stored on hardware token with PKCS11 interface.

osslsigncode (https://github.com/mtrojnar/osslsigncode) seems to be
well-behaved openssl application, which uses digest BIO and PKCS7 API,
does no poking into opaque structures etc.

Application was compiled from source in February, when openssl version
in Debian was 3.0.11-1~deb12u1

Unfortunately, when security update of libssl3 (debian package for
openssl libraries) version 3.0.13-1~deb12u1 was installed, osslsigncode
begin to crash with SIGSEGV.

Quick debugging session shows that application is able to initialize
token and correctly obtain private key handle and certificate for it.
But when trying to sign, it receives invalid pointer to
PKCS11_CTX_private structure. (segfault happens inside pkcs11.so)
This pointer is contained in PKCS11_SLOT_private structure, which
has refcount field before this pointer, and this field also seems to be
filled with garbage (i expect refcount to be less than 10 in so small
program, which handles just one signature and it is some 32-bit value
with second high order bit set).

Downgrade to previous version of openssl libraries fixes the problem.

I suspect that problem is in application, which somehow misuses openssl
API but have no idea how to look for problem. Really, it seems to to be
good idea to track memory writes to PKCS11_SLOT object, but it is
hidden inside so many levels of opaque structures.

I've thought about checking what change in openssl may affect problem,
but don't see anything appropriate in changelog between 3.0.11 and
3.0.13 (and debian maintainers seems to add nothing new over upstream
changes).
-- 

Re: receiving fatal error from server

[Lokesh Chakka]

Server supports 1.3
If I do 127.0.1.1 in Firefox, I'm getting response. It's TLS 1.3

Regards.
Lokesh.

On Mon, Jul 15, 2024, 18:23 Alexandr Nedvedicky  wrote:

> Hello,
>
> I just took a look at the packet dump. The client hello
> in packet dump is TLS 1.3
>
> the alert sent by server is Alert Message TLS 1.2
>
> could it be that server does not support TLS 1.3?
>
> better chance to better understand what's going on is to get
> hands on the server and get some logs.
>
> may be someone else on mailing list will be able to take a look
> and fill some details which I could miss.
>
> thanks and
> regards
> sasha
>
>
> On Sat, Jul 13, 2024 at 12:58:07PM +0530, Lokesh Chakka wrote:
> >Hi,
> >Please find the attached capture file.
> >I'm trying to craft a minimal custom client hello packet. I'm seeing
> >that the contents of the entire packet are proper. But it seems some
> >more data is missing. Can someone help me understand why the apache2
> >server(Ubuntu platform) is sending fatal error.
> >Thanks & Regards
> >--
> >Lokesh Chakka.
>
>
>

Re: receiving fatal error from server

[Alexandr Nedvedicky]

Hello,

I just took a look at the packet dump. The client hello
in packet dump is TLS 1.3

the alert sent by server is Alert Message TLS 1.2

could it be that server does not support TLS 1.3?

better chance to better understand what's going on is to get
hands on the server and get some logs.

may be someone else on mailing list will be able to take a look
and fill some details which I could miss.

thanks and
regards
sasha


On Sat, Jul 13, 2024 at 12:58:07PM +0530, Lokesh Chakka wrote:
>Hi,
>Please find the attached capture file.
>I'm trying to craft a minimal custom client hello packet. I'm seeing
>that the contents of the entire packet are proper. But it seems some
>more data is missing. Can someone help me understand why the apache2
>server(Ubuntu platform) is sending fatal error.
>Thanks & Regards
>--
>Lokesh Chakka.

Re: Non-Programmatic Deterministic Key Generation for ED25519 and ED448 Keys

[Billy Brumley]

Howdy,


I notice that OpenSSL has the 'asn1parse' utility for reading PEM and
DER formatted keys. Is there an analogue that allows to write back a new
value for the secret integers in private keys? Or can I encode data
with 'asn1parse' and then output it in PEM format to build a key?


asn1parse works "both ways", if that's what you mean; check the "genstr" 
and "genconf" parts of the man page.


Also, not my project but

https://github.com/wllm-rbnt/asn1template

is awesome! Sometimes, you start with a PEM / DER and working backwards 
towards the format asn1parse expects is super tedious. That tool is a huge 
time saver.


Cheers,

BBB

PS You can totally make keygen deterministic like that, but ofc you are 
deep into roll-your-own at that point. So ... tread lightly

smime.p7s
Description: S/MIME Cryptographic Signature

Re: Non-Programmatic Deterministic Key Generation for ED25519 and ED448 Keys

[Neil Horman]

I've never tried, but you might try replacing /dev/random with a pipe that
reads data from an input file to make the entropy fetch deterministic.

Note that's probably dangerous, so I'd recommend doing this in a container
to isolate it from your running system

On Sat, Jul 13, 2024, 8:52 PM Syfer Shock! via openssl-users <
openssl-users@openssl.org> wrote:

> I need a non-programmatic method for using seeds to generate ED25519
> and ED448 (Goldilocks) key pairs. This means using only shell-accessible
> tools within OpenSSL rather than binding programmatically.
>
> While reading the documentation it seems that neither 'genpkey' nor
> 'pkeyutl' have a facility for using a deterministic seed to generate
> the keys. Maybe I am missing something.
>
> I notice that OpenSSL has the 'asn1parse' utility for reading PEM and
> DER formatted keys. Is there an analogue that allows to write back a new
> value for the secret integers in private keys? Or can I encode data
> with 'asn1parse' and then output it in PEM format to build a key?
>
> Trying to de-serialize and reconstruct keys outside of OpenSSL is a pain
> and might hinder portability and require re-writing the same code to
> different targets. I would rather try to find a way to use the native
> shell commands so I may set it and forget it.
>
> --
>   www.sybershock.com | sci.crypt | alt.sources.crypto | alt.lite.bulb
>

Non-Programmatic Deterministic Key Generation for ED25519 and ED448 Keys

[Syfer Shock! via openssl-users]

I need a non-programmatic method for using seeds to generate ED25519
and ED448 (Goldilocks) key pairs. This means using only shell-accessible
tools within OpenSSL rather than binding programmatically.

While reading the documentation it seems that neither 'genpkey' nor
'pkeyutl' have a facility for using a deterministic seed to generate
the keys. Maybe I am missing something.

I notice that OpenSSL has the 'asn1parse' utility for reading PEM and
DER formatted keys. Is there an analogue that allows to write back a new
value for the secret integers in private keys? Or can I encode data
with 'asn1parse' and then output it in PEM format to build a key?

Trying to de-serialize and reconstruct keys outside of OpenSSL is a pain
and might hinder portability and require re-writing the same code to
different targets. I would rather try to find a way to use the native
shell commands so I may set it and forget it.

-- 
  www.sybershock.com | sci.crypt | alt.sources.crypto | alt.lite.bulb

receiving fatal error from server

[Lokesh Chakka]

Hi,

Please find the attached capture file.

I'm trying to craft a minimal custom client hello packet. I'm seeing that
the contents of the entire packet are proper. But it seems some more data
is missing. Can someone help me understand why the apache2 server(Ubuntu
platform) is sending fatal error.


Thanks & Regards
--
Lokesh Chakka.


client_hello.pcapng
Description: Binary data

ECDH - Group19 example code

[Damodhar Boddukuri via openssl-users]

Hi,

I am looking for a example code for ECDH - Group19, There are many API's in the 
lib. If you could help me with a simple code with:


  1.  Initializing the context if any?
  2.  Selecting ECDH Group 19
  3.  Private/Public Key Generation
  4.  Shared secret Key Generation
Or any other exact sequence.

Thanks & Regards,
Damodhar.
+91-7702191212



General

Re: Library and DLL names on Windows X64

[J Decker]

On Fri, Jul 12, 2024 at 9:03 AM BENTLEY Thom via openssl-users <
openssl-users@openssl.org> wrote:

> Hi All,
>
>
>
> I had to change the names of the .lib files to:
>"dcmtkcrypto_d.lib" - debug version
>
>"dcmtkcrypto_o.lib" - release version (optimized)
>
>"dcmtkssl_d.lib"- debug version
>
>"dcmtkssl_o.lib"- release version (optimized)
>

what were the names previously?  And why was the change required?

This was required by the DCMTK team’s CMake configuration steps.
>
> Without doing this the configuration failed to find the correct parts of
> OpenSSL.
>
> See:
> https://github.com/DCMTK/dcmtk/blob/59f75a8b50e50ae1bb1ff12098040c6327500740/INSTALL#L634
>
> I noticed that their OpenSSL 1.1.1w zip file has DLLs with different
> names, too.
> They are named:
> dcmtkcrypto-1_1-x64.dll
>
> dcmtkcrypto_d-1_1-x64.dll
>
> dcmtkssl-1_1-x64.dll
>
> dcmtkssl_d-1_1-x64.dll
>
>
>
> Is there a option when building my own OpenSSL 3.0.8 libraries that will
> name the libraries and DLLs like this?
>
> Is renaming them manually going to be OK?  Will the DLL be found when the
> application that requires it attempts to load it?
> I’m just getting back into Windows development after many years.
>

Windows will only link to A DLL... the name of which comes from a .lib file
at link time, unless you're using LoadLibraryEx() (equivalent of dlopen)
and loading possible options yourself so No, it will not be found.

renaming them manually is fine, as long as they are renamed before linking
to other build products.




>
> Thanks
>
>
>
>
>
> *Thom Bentley *| Senior Software Engineer | Medidata, a Dassault Systèmes
> company 
>
>
>
> This email and any attachments are intended solely for the use of the
> individual or entity to whom it is addressed and may be confidential and/or
> privileged.
>
> If you are not one of the named recipients or have received this email in
> error,
>
> (i) you should not read, disclose, or copy it,
>
> (ii) please notify sender of your receipt by reply email and delete this
> email and all attachments,
>
> (iii) Dassault Systèmes does not accept or assume any liability or
> responsibility for any use of or reliance on this email.
>
> Please be informed that your personal data are processed according to our
> data privacy policy as described on our website. Should you have any
> questions related to personal data protection, please contact 3DS Data
> Protection Officer https://www.3ds.com/privacy-policy/contact/
>
>
>

Library and DLL names on Windows X64

[BENTLEY Thom via openssl-users]

Hi All,

I had to change the names of the .lib files to:
   "dcmtkcrypto_d.lib" - debug version
   "dcmtkcrypto_o.lib" - release version (optimized)
   "dcmtkssl_d.lib"- debug version
   "dcmtkssl_o.lib"- release version (optimized)
This was required by the DCMTK team's CMake configuration steps.
Without doing this the configuration failed to find the correct parts of 
OpenSSL.
See: 
https://github.com/DCMTK/dcmtk/blob/59f75a8b50e50ae1bb1ff12098040c6327500740/INSTALL#L634

I noticed that their OpenSSL 1.1.1w zip file has DLLs with different names, too.
They are named:
dcmtkcrypto-1_1-x64.dll
dcmtkcrypto_d-1_1-x64.dll
dcmtkssl-1_1-x64.dll
dcmtkssl_d-1_1-x64.dll

Is there a option when building my own OpenSSL 3.0.8 libraries that will name 
the libraries and DLLs like this?

Is renaming them manually going to be OK?  Will the DLL be found when the 
application that requires it attempts to load it?
I'm just getting back into Windows development after many years.

Thanks


Thom Bentley | Senior Software Engineer | Medidata, a Dassault Systèmes 
company


This email and any attachments are intended solely for the use of the 
individual or entity to whom it is addressed and may be confidential and/or 
privileged.

If you are not one of the named recipients or have received this email in error,

(i) you should not read, disclose, or copy it,

(ii) please notify sender of your receipt by reply email and delete this email 
and all attachments,

(iii) Dassault Systèmes does not accept or assume any liability or 
responsibility for any use of or reliance on this email.


Please be informed that your personal data are processed according to our data 
privacy policy as described on our website. Should you have any questions 
related to personal data protection, please contact 3DS Data Protection Officer 
https://www.3ds.com/privacy-policy/contact/

Re: Macro definitions

[Richard Levitte]

They are generated, using providers/common/der/oids_to_c.pm, and
template files like providers/common/der/der_ec_gen.c.in, where you can
see the .asn1 files that are used as sources.

Cheers,
Richard

Damodhar Boddukuri via openssl-users  writes:

> Hi OpenSSL,
>
>  
>
> I am compiling OpenSSL 3.1.3 for ARM A9. It’s unable get the following macro 
> definitions. They are used in
> der_ec_sig.c
>
>  
>
> ossl_der_oid_ecdsa_with_SHA1
>
> ossl_der_oid_ecdsa_with_SHA224
>
> ossl_der_oid_ecdsa_with_SHA256
>
> ossl_der_oid_ecdsa_with_SHA384
>
> ossl_der_oid_ecdsa_with_SHA512
>
> ossl_der_oid_id_ecdsa_with_sha3_224
>
> ossl_der_oid_id_ecdsa_with_sha3_256
>
> ossl_der_oid_id_ecdsa_with_sha3_384
>
> ossl_der_oid_id_ecdsa_with_sha3_512
>
>  
>
> +++ Compiling
> C:/Dev/WindRiverDSMPDDR_V19_OSSL_313/components/ip_net2-6.9/ipcrypto/openssl-3_1_3/providers/common/der/der_ec_sig.c
>
>
> C:/Dev/WindRiverDSMPDDR_V19_OSSL_313/components/ip_net2-6.9/ipcrypto/openssl-3_1_3/providers/common/der/der_ec_sig.c:
> In function 'ossl_DER_w_algorithmIdentifier_ECDSA_with_MD':
>
> C:/Dev/WindRiverDSMPDDR_V19_OSSL_313/components/ip_net2-6.9/ipcrypto/openssl-3_1_3/providers/common/der/der_ec_sig.c:34:
> error: 'ossl_der_oid_ecdsa_with_SHA1' undeclared (first use in this function)
>
> C:/Dev/WindRiverDSMPDDR_V19_OSSL_313/components/ip_net2-6.9/ipcrypto/openssl-3_1_3/providers/common/der/der_ec_sig.c:34:
> error: (Each undeclared identifier is reported only once
>
> C:/Dev/WindRiverDSMPDDR_V19_OSSL_313/components/ip_net2-6.9/ipcrypto/openssl-3_1_3/providers/common/der/der_ec_sig.c:34:
> error: for each function it appears in.)
>
> C:/Dev/WindRiverDSMPDDR_V19_OSSL_313/components/ip_net2-6.9/ipcrypto/openssl-3_1_3/providers/common/der/der_ec_sig.c:35:
> error: 'ossl_der_oid_ecdsa_with_SHA224' undeclared (first use in this 
> function)
>
> C:/Dev/WindRiverDSMPDDR_V19_OSSL_313/components/ip_net2-6.9/ipcrypto/openssl-3_1_3/providers/common/der/der_ec_sig.c:36:
> error: 'ossl_der_oid_ecdsa_with_SHA256' undeclared (first use in this 
> function)
>
> C:/Dev/WindRiverDSMPDDR_V19_OSSL_313/components/ip_net2-6.9/ipcrypto/openssl-3_1_3/providers/common/der/der_ec_sig.c:37:
> error: 'ossl_der_oid_ecdsa_with_SHA384' undeclared (first use in this 
> function)
>
> C:/Dev/WindRiverDSMPDDR_V19_OSSL_313/components/ip_net2-6.9/ipcrypto/openssl-3_1_3/providers/common/der/der_ec_sig.c:38:
> error: 'ossl_der_oid_ecdsa_with_SHA512' undeclared (first use in this 
> function)
>
> C:/Dev/WindRiverDSMPDDR_V19_OSSL_313/components/ip_net2-6.9/ipcrypto/openssl-3_1_3/providers/common/der/der_ec_sig.c:39:
> error: 'ossl_der_oid_id_ecdsa_with_sha3_224' undeclared (first use in this 
> function)
>
> C:/Dev/WindRiverDSMPDDR_V19_OSSL_313/components/ip_net2-6.9/ipcrypto/openssl-3_1_3/providers/common/der/der_ec_sig.c:40:
> error: 'ossl_der_oid_id_ecdsa_with_sha3_256' undeclared (first use in this 
> function)
>
> declared (first use in this function)
>
> C:/Dev/WindRiverDSMPDDR_V19_OSSL_313/components/ip_net2-6.9/ipcrypto/openssl-3_1_3/providers/common/der/der_ec_sig.c:41:
> error: 'ossl_der_oid_id_ecdsa_with_sha3_384' undeclared (first use in this 
> function)
>
> C:/Dev/WindRiverDSMPDDR_V19_OSSL_313/components/ip_net2-6.9/ipcrypto/openssl-3_1_3/providers/common/der/der_ec_sig.c:42:
> error: 'ossl_der_oid_id_ecdsa_with_sha3_512' undeclared (first use in this 
> function)
>
>  
>
>  
>
> Thanks & Regards,
>
> Damodhar.
>
> +91-7702191212
>
>  
>
> General
>

-- 
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Macro definitions

[Damodhar Boddukuri via openssl-users]

Hi OpenSSL,

I am compiling OpenSSL 3.1.3 for ARM A9. It's unable get the following macro 
definitions. They are used in der_ec_sig.c

ossl_der_oid_ecdsa_with_SHA1
ossl_der_oid_ecdsa_with_SHA224
ossl_der_oid_ecdsa_with_SHA256
ossl_der_oid_ecdsa_with_SHA384
ossl_der_oid_ecdsa_with_SHA512
ossl_der_oid_id_ecdsa_with_sha3_224
ossl_der_oid_id_ecdsa_with_sha3_256
ossl_der_oid_id_ecdsa_with_sha3_384
ossl_der_oid_id_ecdsa_with_sha3_512

+++ Compiling 
C:/Dev/WindRiverDSMPDDR_V19_OSSL_313/components/ip_net2-6.9/ipcrypto/openssl-3_1_3/providers/common/der/der_ec_sig.c
C:/Dev/WindRiverDSMPDDR_V19_OSSL_313/components/ip_net2-6.9/ipcrypto/openssl-3_1_3/providers/common/der/der_ec_sig.c:
 In function 'ossl_DER_w_algorithmIdentifier_ECDSA_with_MD':
C:/Dev/WindRiverDSMPDDR_V19_OSSL_313/components/ip_net2-6.9/ipcrypto/openssl-3_1_3/providers/common/der/der_ec_sig.c:34:
 error: 'ossl_der_oid_ecdsa_with_SHA1' undeclared (first use in this function)
C:/Dev/WindRiverDSMPDDR_V19_OSSL_313/components/ip_net2-6.9/ipcrypto/openssl-3_1_3/providers/common/der/der_ec_sig.c:34:
 error: (Each undeclared identifier is reported only once
C:/Dev/WindRiverDSMPDDR_V19_OSSL_313/components/ip_net2-6.9/ipcrypto/openssl-3_1_3/providers/common/der/der_ec_sig.c:34:
 error: for each function it appears in.)
C:/Dev/WindRiverDSMPDDR_V19_OSSL_313/components/ip_net2-6.9/ipcrypto/openssl-3_1_3/providers/common/der/der_ec_sig.c:35:
 error: 'ossl_der_oid_ecdsa_with_SHA224' undeclared (first use in this function)
C:/Dev/WindRiverDSMPDDR_V19_OSSL_313/components/ip_net2-6.9/ipcrypto/openssl-3_1_3/providers/common/der/der_ec_sig.c:36:
 error: 'ossl_der_oid_ecdsa_with_SHA256' undeclared (first use in this function)
C:/Dev/WindRiverDSMPDDR_V19_OSSL_313/components/ip_net2-6.9/ipcrypto/openssl-3_1_3/providers/common/der/der_ec_sig.c:37:
 error: 'ossl_der_oid_ecdsa_with_SHA384' undeclared (first use in this function)
C:/Dev/WindRiverDSMPDDR_V19_OSSL_313/components/ip_net2-6.9/ipcrypto/openssl-3_1_3/providers/common/der/der_ec_sig.c:38:
 error: 'ossl_der_oid_ecdsa_with_SHA512' undeclared (first use in this function)
C:/Dev/WindRiverDSMPDDR_V19_OSSL_313/components/ip_net2-6.9/ipcrypto/openssl-3_1_3/providers/common/der/der_ec_sig.c:39:
 error: 'ossl_der_oid_id_ecdsa_with_sha3_224' undeclared (first use in this 
function)
C:/Dev/WindRiverDSMPDDR_V19_OSSL_313/components/ip_net2-6.9/ipcrypto/openssl-3_1_3/providers/common/der/der_ec_sig.c:40:
 error: 'ossl_der_oid_id_ecdsa_with_sha3_256' undeclared (first use in this 
function)
declared (first use in this function)
C:/Dev/WindRiverDSMPDDR_V19_OSSL_313/components/ip_net2-6.9/ipcrypto/openssl-3_1_3/providers/common/der/der_ec_sig.c:41:
 error: 'ossl_der_oid_id_ecdsa_with_sha3_384' undeclared (first use in this 
function)
C:/Dev/WindRiverDSMPDDR_V19_OSSL_313/components/ip_net2-6.9/ipcrypto/openssl-3_1_3/providers/common/der/der_ec_sig.c:42:
 error: 'ossl_der_oid_id_ecdsa_with_sha3_512' undeclared (first use in this 
function)


Thanks & Regards,
Damodhar.
+91-7702191212



General

RE: Can we provide --debug and --release on a single build?

[BENTLEY Thom via openssl-users]

Thanks for the confirmation.



Thom Bentley | Senior Software Engineer | Medidata, a Dassault Systèmes 
company

From: Neil Horman 
Sent: Wednesday, July 10, 2024 1:56 PM
To: BENTLEY Thom 
Cc: openssl-users@openssl.org
Subject: Re: Can we provide --debug and --release on a single build?

yeah, then you need to build twice, once with each set of compiler flags. 
Renaming is a manual process IIRC On Wed, Jul 10, 2024 at 1: 43 PM BENTLEY Thom 
 wrote: Thanks Neil. I just want to end up having a 
debug and

yeah, then you need to build twice, once with each set of compiler flags.  
Renaming is a manual process IIRC

On Wed, Jul 10, 2024 at 1:43 PM BENTLEY Thom 
mailto:thom.bent...@3ds.com>> wrote:
Thanks Neil.
I just want to end up having a debug and release version of each library.
I need to rename them for use with DCMTK to the following.
 openssl:
   "dcmtkcrypto_d.lib" - debug version
   "dcmtkcrypto_o.lib" - release version (optimized)
   "dcmtkssl_d.lib"- debug version
   "dcmtkssl_o.lib"- release version (optimized)

It seems they expect those file names and use them when generating a build 
system with CMake.


Thom Bentley | Senior Software Engineer | Medidata, a Dassault Systèmes 
company

From: Neil Horman mailto:nhor...@openssl.org>>
Sent: Wednesday, July 10, 2024 1:32 PM
To: BENTLEY Thom mailto:thom.bent...@3ds.com>>
Subject: Re: Can we provide --debug and --release on a single build?

you can supply both, but they don't create separate libraries. The --debug and 
--release just set different optimization flags on the compiler (-g -O0 vs -O3) 
If you want to be able to provide an optimized production build, and supply a
you can supply both, but they don't create separate libraries. The --debug and 
--release just set different optimization flags on the compiler (-g -O0 vs -O3)

If you want to be able to provide an optimized production build, and supply a 
level of debugability (though not as good as building with -O0), you're best 
bet, is to build with -g and -O3, then use objcopy to separate the debug 
sections into their own file, then strip the debug info from the initial dso.  
This is how most distributions create their debuginfo packages

On Wed, Jul 10, 2024 at 1:22 PM BENTLEY Thom via openssl-users 
mailto:openssl-users@openssl.org>> wrote:
Hi,
I was wondering if the build scripts could handling providing –debug and 
–release for a build.
Would this create release and debug libraries in a single build?
Thanks.

P.S.  I know I could try it, but I thought others might want to know later too. 
 Perhaps an update in the INSTALL.md file.



Thom Bentley | Senior Software Engineer | Medidata, a Dassault Systèmes 
company


This email and any attachments are intended solely for the use of the 
individual or entity to whom it is addressed and may be confidential and/or 
privileged.

If you are not one of the named recipients or have received this email in error,

(i) you should not read, disclose, or copy it,

(ii) please notify sender of your receipt by reply email and delete this email 
and all attachments,

(iii) Dassault Systèmes does not accept or assume any liability or 
responsibility for any use of or reliance on this email.


Please be informed that your personal data are processed according to our data 
privacy policy as described on our website. Should you have any questions 
related to personal data protection, please contact 3DS Data Protection Officer 
https://www.3ds.com/privacy-policy/contact/



This email and any attachments are intended solely for the use of the 
individual or entity to whom it is addressed and may be confidential and/or 
privileged.

If you are not one of the named recipients or have received this email in error,

(i) you should not read, disclose, or copy it,

(ii) please notify sender of your receipt by reply email and delete this email 
and all attachments,

(iii) Dassault Systèmes does not accept or assume any liability or 
responsibility for any use of or reliance on this email.


Please be informed that your personal data are processed according to our data 
privacy policy as described on our website. Should you have any questions 
related to personal data protection, please contact 3DS Data Protection Officer 
https://www.3ds.com/privacy-policy/contact/



This email and any attachments are intended solely for the use of the 
individual or entity to whom it is addressed and may be confidential and/or 
privileged.

If you are not one of the named recipients or have received this email in error,

(i) you should not read, disclose, or copy it,

(ii) please notify sender of your receipt by reply email and delete this email 
and all attachments,

(iii) Dassault Systèmes does not accept or assume any liability or 
responsibility for any use of or reliance on this email.


Please be informed that your personal data are processed according to our data 
privacy 

Re: Can we provide --debug and --release on a single build?

[Neil Horman]

yeah, then you need to build twice, once with each set of compiler flags.
Renaming is a manual process IIRC

On Wed, Jul 10, 2024 at 1:43 PM BENTLEY Thom  wrote:

> Thanks Neil.
> I just want to end up having a debug and release version of each library.
> I need to rename them for use with DCMTK to the following.
>
>  openssl:
>
>"dcmtkcrypto_d.lib" - debug version
>
>"dcmtkcrypto_o.lib" - release version (optimized)
>
>"dcmtkssl_d.lib"- debug version
>
>"dcmtkssl_o.lib"- release version (optimized)
>
>
>
> It seems they expect those file names and use them when generating a build
> system with CMake.
>
>
>
>
>
> *Thom Bentley *| Senior Software Engineer | Medidata, a Dassault Systèmes
> company 
>
>
>
> *From:* Neil Horman 
> *Sent:* Wednesday, July 10, 2024 1:32 PM
> *To:* BENTLEY Thom 
> *Subject:* Re: Can we provide --debug and --release on a single build?
>
>
>
> you can supply both, but they don't create separate libraries. The --debug
> and --release just set different optimization flags on the compiler (-g -O0
> vs -O3) If you want to be able to provide an optimized production build,
> and supply a
>
> you can supply both, but they don't create separate libraries. The --debug
> and --release just set different optimization flags on the compiler (-g -O0
> vs -O3)
>
>
>
> If you want to be able to provide an optimized production build, and
> supply a level of debugability (though not as good as building with -O0),
> you're best bet, is to build with -g and -O3, then use objcopy to separate
> the debug sections into their own file, then strip the debug info from the
> initial dso.  This is how most distributions create their debuginfo packages
>
>
>
> On Wed, Jul 10, 2024 at 1:22 PM BENTLEY Thom via openssl-users <
> openssl-users@openssl.org> wrote:
>
> Hi,
> I was wondering if the build scripts could handling providing –debug and
> –release for a build.
> Would this create release and debug libraries in a single build?
> Thanks.
>
>
>
> P.S.  I know I could try it, but I thought others might want to know later
> too.  Perhaps an update in the INSTALL.md file.
>
>
>
>
>
>
>
> *Thom Bentley *| Senior Software Engineer | Medidata, a Dassault Systèmes
> company 
>
>
>
> *This email and any attachments are intended solely for the use of the
> individual or entity to whom it is addressed and may be confidential and/or
> privileged.*
>
> *If you are not one of the named recipients or have received this email in
> error,*
>
> *(i) you should not read, disclose, or copy it,*
>
> *(ii) please notify sender of your receipt by reply email and delete this
> email and all attachments,*
>
> *(iii) Dassault Systèmes does not accept or assume any liability or
> responsibility for any use of or reliance on this email.*
>
>
>
> *Please be informed that your personal data are processed according to our
> data privacy policy as described on our website. Should you have any
> questions related to personal data protection, please contact 3DS Data
> Protection Officer https://www.3ds.com/privacy-policy/contact/
> *
>
>
>
> This email and any attachments are intended solely for the use of the
> individual or entity to whom it is addressed and may be confidential and/or
> privileged.
>
> If you are not one of the named recipients or have received this email in
> error,
>
> (i) you should not read, disclose, or copy it,
>
> (ii) please notify sender of your receipt by reply email and delete this
> email and all attachments,
>
> (iii) Dassault Systèmes does not accept or assume any liability or
> responsibility for any use of or reliance on this email.
>
> Please be informed that your personal data are processed according to our
> data privacy policy as described on our website. Should you have any
> questions related to personal data protection, please contact 3DS Data
> Protection Officer https://www.3ds.com/privacy-policy/contact/
>
>
>

RE: Can we provide --debug and --release on a single build?

[BENTLEY Thom via openssl-users]

Thanks Neil.
I just want to end up having a debug and release version of each library.
I need to rename them for use with DCMTK to the following.
 openssl:
   "dcmtkcrypto_d.lib" - debug version
   "dcmtkcrypto_o.lib" - release version (optimized)
   "dcmtkssl_d.lib"- debug version
   "dcmtkssl_o.lib"- release version (optimized)

It seems they expect those file names and use them when generating a build 
system with CMake.


Thom Bentley | Senior Software Engineer | Medidata, a Dassault Systèmes 
company

From: Neil Horman 
Sent: Wednesday, July 10, 2024 1:32 PM
To: BENTLEY Thom 
Subject: Re: Can we provide --debug and --release on a single build?

you can supply both, but they don't create separate libraries. The --debug and 
--release just set different optimization flags on the compiler (-g -O0 vs -O3) 
If you want to be able to provide an optimized production build, and supply a

you can supply both, but they don't create separate libraries. The --debug and 
--release just set different optimization flags on the compiler (-g -O0 vs -O3)

If you want to be able to provide an optimized production build, and supply a 
level of debugability (though not as good as building with -O0), you're best 
bet, is to build with -g and -O3, then use objcopy to separate the debug 
sections into their own file, then strip the debug info from the initial dso.  
This is how most distributions create their debuginfo packages

On Wed, Jul 10, 2024 at 1:22 PM BENTLEY Thom via openssl-users 
mailto:openssl-users@openssl.org>> wrote:
Hi,
I was wondering if the build scripts could handling providing –debug and 
–release for a build.
Would this create release and debug libraries in a single build?
Thanks.

P.S.  I know I could try it, but I thought others might want to know later too. 
 Perhaps an update in the INSTALL.md file.



Thom Bentley | Senior Software Engineer | Medidata, a Dassault Systèmes 
company


This email and any attachments are intended solely for the use of the 
individual or entity to whom it is addressed and may be confidential and/or 
privileged.

If you are not one of the named recipients or have received this email in error,

(i) you should not read, disclose, or copy it,

(ii) please notify sender of your receipt by reply email and delete this email 
and all attachments,

(iii) Dassault Systèmes does not accept or assume any liability or 
responsibility for any use of or reliance on this email.


Please be informed that your personal data are processed according to our data 
privacy policy as described on our website. Should you have any questions 
related to personal data protection, please contact 3DS Data Protection Officer 
https://www.3ds.com/privacy-policy/contact/



This email and any attachments are intended solely for the use of the 
individual or entity to whom it is addressed and may be confidential and/or 
privileged.

If you are not one of the named recipients or have received this email in error,

(i) you should not read, disclose, or copy it,

(ii) please notify sender of your receipt by reply email and delete this email 
and all attachments,

(iii) Dassault Systèmes does not accept or assume any liability or 
responsibility for any use of or reliance on this email.


Please be informed that your personal data are processed according to our data 
privacy policy as described on our website. Should you have any questions 
related to personal data protection, please contact 3DS Data Protection Officer 
https://www.3ds.com/privacy-policy/contact/

Can we provide --debug and --release on a single build?

[BENTLEY Thom via openssl-users]

Hi,
I was wondering if the build scripts could handling providing -debug and 
-release for a build.
Would this create release and debug libraries in a single build?
Thanks.

P.S.  I know I could try it, but I thought others might want to know later too. 
 Perhaps an update in the INSTALL.md file.



Thom Bentley | Senior Software Engineer | Medidata, a Dassault Systèmes 
company


This email and any attachments are intended solely for the use of the 
individual or entity to whom it is addressed and may be confidential and/or 
privileged.

If you are not one of the named recipients or have received this email in error,

(i) you should not read, disclose, or copy it,

(ii) please notify sender of your receipt by reply email and delete this email 
and all attachments,

(iii) Dassault Systèmes does not accept or assume any liability or 
responsibility for any use of or reliance on this email.


Please be informed that your personal data are processed according to our data 
privacy policy as described on our website. Should you have any questions 
related to personal data protection, please contact 3DS Data Protection Officer 
https://www.3ds.com/privacy-policy/contact/

Using s_client to send additional (spurious) certificates

[Andrew Lee-Thorp]

Hello,

Can s_client be used to send additional certificates (i.e. certificates that 
are not part of the chain for the current connection)

I am trying to do the following (pseudocode):

s_client -key myclient.key -cert myclient.cer -verifyCAfile expectedserverCA 
-connect server:port -fileAdditionalCertsToSend othercerts

The -fileAdditionalCertsToSend does not exist but I'd like to mimic this if 
possible.

The options -cert_chain and -build_chain don't seem to be what I want because I 
want s_client to send the additional certificates regardless, not attempt to 
build any chain using them.

-cert_chain
A file or URI of untrusted certificates to use when attempting to build the 
certificate chain related to the certificate specified via the -cert option. 
The input can be in PEM, DER, or PKCS#12 format.

-build_chain
Specify whether the application should build the client certificate chain to be 
provided to the server.

For additional context - the server is expecting the chain [client1,ca1] but 
the extended verification logic suggests I might be able to connect using 
[client2, ca2] - because of the way the server builds and validates a chain 
from the list of untrusted certs presented by the client.
 
My pseudo usage of s_client equates to:

s_client -key client2.key -cert client2.cer -verifyCAfile expectedserverCA 
-connect server:port -fileAdditionalCertsToSend [client1, ca1]

Kind regards
Andrew

RE: Missing header file ts_local.h in install location.

[BENTLEY Thom via openssl-users]

Is it possible that OPENSSL_NO_DEPRECATED_3_0 is defined and that’s what’s 
causing the issue with DCMTK configuration?
>From ts.h:
# ifndef OPENSSL_NO_DEPRECATED_3_0
#  define TS_VERIFY_CTS_set_certs(ctx, cert) TS_VERIFY_CTX_set_certs(ctx,cert)
# endif
STACK_OF(X509) *TS_VERIFY_CTX_set_certs(TS_VERIFY_CTX *ctx, STACK_OF(X509) 
*certs);



Thom Bentley | Senior Software Engineer | Medidata, a Dassault Systèmes 
company

From: Tomas Mraz 
Sent: Monday, July 1, 2024 4:12 AM
To: BENTLEY Thom ; Matt Caswell ; 
openssl-users@openssl.org
Subject: Re: Missing header file ts_local.h in install location.

Yes, they should search for TS_VERIFY_CTX_set_certs or TS_VERIFY_CTX_set_flags 
(that would work for 1. 1. 1 as well). Tomas Mraz, OpenSS On Fri, 2024-06-28 at 
20: 04 +, BENTLEY Thom wrote: > > > > Does this Bing CoPilot response


Yes, they should search for TS_VERIFY_CTX_set_certs or

TS_VERIFY_CTX_set_flags (that would work for 1.1.1 as well).



Tomas Mraz, OpenSS



On Fri, 2024-06-28 at 20:04 +, BENTLEY Thom wrote:

>

>

>

> Does this Bing CoPilot response suggest that DCMTK’s CMake

> configuration should be searching for a different function name?

>

> The HAVE_OPENSSL_PROTOTYPE_TS_VERIFY_CTS_SET_CERTS is a macro that

> checks for the existence of the TS_VERIFY_CTS_set_certs function in

> OpenSSL1. This function is used to set the server’s certificate chain

> when verifying a TimeStampToken (TST)1.

>

> However, starting from OpenSSL 3.0.0, the correct spelling of the

> function is TS_VERIFY_CTX_set_certs, and the misspelled

> version TS_VERIFY_CTS_set_certs has been retained for compatibility

> reasons, but it is deprecated1.

>

> This could potentially cause issues if DCMTK 3.6.8 is not properly

> configured to handle this change in OpenSSL 3.0.8.

>

>

>

>

>

>

> Thom Bentley| Senior Software Engineer |

> Medidata, a Dassault Systèmes company

>

>

>

> From: Matt Caswell mailto:m...@openssl.org>>

> Sent: Friday, June 28, 2024 11:54 AM

> To: BENTLEY Thom mailto:thom.bent...@3ds.com>>; Tomas 
> Mraz

> mailto:to...@openssl.org>>; 
> openssl-users@openssl.org

> Subject: Re: Missing header file ts_local.h in install location.

>

>

>

> On 28/06/2024 16: 29, BENTLEY Thom via openssl-users wrote: > Thanks.

> Yes, I saw that they became opaque. > The code I’m building works

> fine with 1. 1. 1w but we need to move to > 3. 0. 8 at least. > Here

> are the errors I see. > >

>

>

>

> On 28/06/2024 16:29, BENTLEY Thom via openssl-users wrote:

> > Thanks.  Yes, I saw that they became opaque.

> > The code I’m building works fine with 1.1.1w but we need to move to

> > 3.0.8 at least.

> > Here are the errors I see.

> >

> > dcmdsig:

> > 16:34:48:290

> > 19>C:\repos\mmi-director-dcmtk-3.6.8\dcmtk-

> > 3.6.8\dcmsign\libsrc\sitstamp.cc(1342,5): error C2027: use of

> > undefined type 'TS_verify_ctx'

> > 16:34:48:290

> > 19>C:\repos\mmi-director-dcmtk-3.6.8\openssl-

> > 3.0.8\include\openssl\ts.h(405,16):

> > 16:34:48:290 19>see declaration of 'TS_verify_ctx'

>

>

> It looks to me like DCMTK needs updating to use OpenSSL 3.x

>

> This particular error occurs because line 1342 of sitstamp.cc looks

> like

> this:

>

>  TS_VERIFY_CTS_set_certs(ctx, NULL);

>

> Earlier on in that file we see this:

>

> #ifndef HAVE_OPENSSL_PROTOTYPE_TS_VERIFY_CTS_SET_CERTS

> #define TS_VERIFY_CTS_set_certs(x,y) ((x)->certs = (y))

> #endif

>

> So if HAVE_OPENSSL_PROTOTYPE_TS_VERIFY_CTS_SET_CERTS isn't defined

> then

> it will attempt to look inside the TS_VERIFY_CTX structure - which is

> not allowed from 1.1.1 onwards because it is opaque.

>

> My guess is the setting of

> HAVE_OPENSSL_PROTOTYPE_TS_VERIFY_CTS_SET_CERTS is going wrong with

> OpenSSL 3.X

>

> It seems to get defined by Cmake/dcmtkPrepare.cmake:

>

>CHECK_FUNCTIONWITHHEADER_EXISTS("TS_VERIFY_CTS_set_certs(0,0)"

> "openssl/ts.h" HAVE_OPENSSL_PROTOTYPE_TS_VERIFY_CTS_SET_CERTS)

>

> Indeed that function header does *not* exist in 3.x because it is

> instead a macro:

>

> # ifndef OPENSSL_NO_DEPRECATED_3_0

> #  define TS_VERIFY_CTS_set_certs(ctx, cert)

> TS_VERIFY_CTX_set_certs(ctx,cert)

> # endif

>

> In 1.1.1 this was a full C function so the cmake detection would have

> worked correctly there.

>

> Matt

>

>

>

> >

> > dcmpstat:

> > 16:36:48:689

> > 34>C:\repos\mmi-director-dcmtk-3.6.8\openssl-

> > 3.0.8\include\openssl\types.h(104,30): error C2371: 'EVP_MD_CTX':

> > redefinition; different basic types

> > 16:36:48:753 34>(compiling source file

> > '../../../dcmtk-3.6.8/dcmpstat/libsrc/dvsighdl.cc')

> > 16:36:48:753

> > 34>C:\repos\mmi-director-dcmtk-3.6.8\dcmtk-

> > 3.6.8\dcmsign\include\dcmtk\dcmsign\simdmac.h(39,30):

> > 16:36:48:753 34>see declaration of 'EVP_MD_CTX'

> >

> > dcmtls:

> > 16:35:16:392

> > 26>C:\repos\mmi-director-dcmtk-3.6.8\dcmtk-

> > 3.6.8\dcmtls\libsrc\tlsciphr.cc(238,32): error C2027: use of

> > 

Re: ECDH Group 19 (256-bit Elliptic curve) key length

[Tomas Mraz]

You should use some Key Derivation Function (KDF) to derive a key from
this shared secret. For example TLS-1.3 uses HKDF for that.

The best way would be to use TLS-1.3 (or some other standardized secure
protocol) directly instead of inventing and implementing your own
protocol though.

Tomas Mraz, OpenSSL


On Mon, 2024-07-08 at 12:47 +, Vishal Kevat via openssl-users
wrote:
> 
> 
> 
> Hi OpenSSL,
>  
> I am using group 19 which is ECDH elliptic curve group
> (NID_X9_62_prime256v1)and is giving 32 bytes/256 bit of shared secret
> key.
>  
> I want to use it to work with AES-128 CBC encryption algorithm. As
> the key length generated by ECDH is 32 bytes, is there any way to
> generate the key length of 16 bytes/128 bit with group 19 ECDH
> algorithm?
>  
> On one of the article, it is mentioned that encryption or
> authentication algorithms with a 128-bit key to be used for Diffie-
> Hellman groups 5, 14, 19, 20 or 24.
> Link:
> https://community.cisco.com/t5/security-knowledge-base/diffie-hellman-groups/ta-p/3147010
> Please let me know if group 19 can generate 128 bit key length by any
> means.
>  
> Regards,
> Vishal Kevat
>  
>  
> 
> General

-- 
Tomáš Mráz, OpenSSL

ECDH Group 19 (256-bit Elliptic curve) key length

[Vishal Kevat via openssl-users]

Hi OpenSSL,

I am using group 19 which is ECDH elliptic curve group (NID_X9_62_prime256v1) 
and is giving 32 bytes/256 bit of shared secret key.

I want to use it to work with AES-128 CBC encryption algorithm. As the key 
length generated by ECDH is 32 bytes, is there any way to generate the key 
length of 16 bytes/128 bit with group 19 ECDH algorithm?

On one of the article, it is mentioned that encryption or authentication 
algorithms with a 128-bit key to be used for Diffie-Hellman groups 5, 14, 19, 
20 or 24.
Link: 
https://community.cisco.com/t5/security-knowledge-base/diffie-hellman-groups/ta-p/3147010
[cid:image001.png@01DAD162.CFD84BB0]
Please let me know if group 19 can generate 128 bit key length by any means.

Regards,
Vishal Kevat




General

FIPS with Openssl 3.1

[Stiju]

Hi,

I am working to package OpenSSL 3.1.x with my product.
As I prefer to be FIPS complaint, I would like to use FIPS module from
OpenSSL 3.0.9.

1) From the Documentation(
https://github.com/openssl/openssl/blob/master/README-FIPS.md)  , what I
understood is,
   I need to build and install OpenSSL 3.1.x to the location. and then
install fips from OpenSSL3.0.9 overlaying the 3.1.x install.  Am I right
with my understanding? or is there any other way 3.1.x built with FIPS
module from 3.0.9. like in OpenSSL 1.0.x ( like using --with-fipsdir etc).


2) Also , I need conformation on FOM FIPS certification
   I build fips.so from 3.0.9  source , can I claim FIPS
compliance directly based on the certificate (
https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/4282)
given to the FOM. I am building OpenSSL on Alma Linux.
  I assume its a yes, Please let me know if I am wrong.



-- 


  Stiju Easo


 The unexamined life is not worth living for man.
  Socrates, in Plato, Dialogues, Apology
  Greek philosopher in Athens (469 BC - 399 BC)

OpenSSL provider question

[tomasz bartczak]

Hi,I want to develop a RSA provider that uses an external HW chip to do the RSA 
encryption/decryption. The HW chip supports several RSA keys. 1) How can pass 
information to the provider which key to use? How about information about which 
key public or private should be used?2) Asymmetrical algorithm function has the 
following parameters:encrypt_init(void *ctx, void *key, const OSSL_PARAM 
params[])But I do not know what openssl core provides by the key pointer3) How 
to make sure that my RSA provider takes precedence over the built-in one?I 
would appreciate your helpTom

RE: Maximum encryption key length supported by AES-128 CBC

[Vishal Kevat via openssl-users]

That answers my questions.

Thanks Viktor.


General
-Original Message-
From: openssl-users  On Behalf Of Viktor 
Dukhovni
Sent: Friday, July 5, 2024 08:01 AM
To: openssl-users@openssl.org
Subject: Re: Maximum encryption key length supported by AES-128 CBC

[External email: Use caution with links and attachments]





On Thu, Jul 04, 2024 at 06:20:25PM +, Vishal Kevat via openssl-users wrote:

> I want to know what length of encryption key does AES-128 CBC supports?

Exactly 128 bits, no more, no less.

> I believe that it supports key length max upto 128 bits that is 16 bytes.

It makes little sense to speak of a "maximum" or "minimum", since the key 
length is always exactly 128-bits.  You can derive a 128-bit key using various 
Password-Based-Key-Derivation-Functions (PBKDFs) from passwords of various 
lengths, but the key must in the end be exactly
128 bits (or, equivalently, 16 bytes as you noted).

> What happens if I give the input key of more than 16 bytes?

You must provide a 16 byte key.  If some API functions accept longer keys, the 
excess bytes will be ignored.

If you're using some variant of EVP_EncryptInit(), the key length is implicit, 
and the provided byte array as required and assumed to be of the expected 
length, there is no mechanism by which OpenSSL would be aware of any additional 
bytes, or whether the array is too short (leading to undefined behaviour).

> This question I am asking because, when I give the key more than 16
> bytes to AES 128 CBC, it still works without throwing any error.

In that case, the excess bytes were ignored.

> Similarly, what is the max key length for AES-256 CBC?

Exactly 32 bytes (256 bits), no more, no less.

--
Viktor.

Re: Maximum encryption key length supported by AES-128 CBC

[Viktor Dukhovni]

On Thu, Jul 04, 2024 at 06:20:25PM +, Vishal Kevat via openssl-users wrote:

> I want to know what length of encryption key does AES-128 CBC supports?

Exactly 128 bits, no more, no less.

> I believe that it supports key length max upto 128 bits that is 16 bytes.

It makes little sense to speak of a "maximum" or "minimum", since the
key length is always exactly 128-bits.  You can derive a 128-bit key
using various Password-Based-Key-Derivation-Functions (PBKDFs) from
passwords of various lengths, but the key must in the end be exactly
128 bits (or, equivalently, 16 bytes as you noted).

> What happens if I give the input key of more than 16 bytes?

You must provide a 16 byte key.  If some API functions accept longer
keys, the excess bytes will be ignored.

If you're using some variant of EVP_EncryptInit(), the key length is
implicit, and the provided byte array as required and assumed to be of
the expected length, there is no mechanism by which OpenSSL would be
aware of any additional bytes, or whether the array is too short
(leading to undefined behaviour).

> This question I am asking because, when I give the key more than 16
> bytes to AES 128 CBC, it still works without throwing any error.

In that case, the excess bytes were ignored.

> Similarly, what is the max key length for AES-256 CBC?

Exactly 32 bytes (256 bits), no more, no less.

-- 
Viktor.

openssl-enc: needs additional base64 garbage check?

[Steffen Nurpmeso]

Hello.

  #?1|kent:tmp$ x=U2FsdGVkX19hzr7eekkcCcfeydWYK7HAeLr2lRPThis
[  ^ $? of last command]

  #?0|kent:tmp$ printf ${x}= | openssl enc -aes256 -k "dubidada" -a -A -pbkdf2 
-d
  #?0|kent:tmp$ printf ${x}=t | openssl enc -aes256 -k "dubidada" -a -A -pbkdf2 
-d
  #?0|kent:tmp$ printf ${x}=to | openssl enc -aes256 -k "dubidada" -a -A 
-pbkdf2 -d
  #?0|kent:tmp$ printf ${x}=tor | openssl enc -aes256 -k "dubidada" -a -A 
-pbkdf2 -d
  #?0|kent:tmp$ printf ${x}=tory | openssl enc -aes256 -k "dubidada" -a -A 
-pbkdf2 -d
  bad decrypt
  8908367F:error:1C80006B:Provider 
routines:ossl_cipher_generic_block_final:wrong final block 
length:providers/implementations/ciphers/ciphercommon.c:443:

  #?1|kent:tmp$ printf ${x} | openssl enc -aes256 -k "dubidada" -a -A -pbkdf2 -d
  bad decrypt
  80105031D77F:error:1C80006B:Provider 
routines:ossl_cipher_generic_block_final:wrong final block 
length:providers/implementations/ciphers/ciphercommon.c:443:

  #?1|kent:tmp$ printf 0${x} | openssl enc -aes256 -k "dubidada" -a -A -pbkdf2 
-d
  bad magic number

  #?1|kent:tmp$ printf 0${x}= | openssl enc -aes256 -k "dubidada" -a -A -pbkdf2 
-d
  bad magic number

  #?1|kent:tmp$ printf ${x}= | openssl enc -aes256 -k "dubidada" -a -A -pbkdf2 
-d

github issue?

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Maximum encryption key length supported by AES-128 CBC

[Vishal Kevat via openssl-users]

Hi OpenSLL users,

I want to know what length of encryption key does AES-128 CBC supports?

I believe that it supports key length max upto 128 bits that is 16 bytes.

What happens if I give the input key of more than 16 bytes? Will the AES-128 
drop the remaining bytes and consider only first 16 bytes?
This question I am asking because, when I give the key more than 16 bytes to 
AES 128 CBC, it still works without throwing any error.

Similarly, what is the max key length for AES-256 CBC?

Regards,
Vishal Kevat


General

Programmatic way to get x509 to be signed digest

[Kenneth Goldman]

I have an X509 object with the usual public components filled in (subject
validity issuer algorithm public key), I want to serialize the data to be
hashed and signed.

Is i2d_X509() the proper way? 

It doesn't seem to work. I sign and add the signature to the x509 object,
but it doesn't verify. I wonder if i2d_x509 is adding some extra content at
the end where the signature should be.

--
Work 1-914-945-2415




smime.p7s
Description: S/MIME cryptographic signature

Re: Certificate verification with cross signed CAs (James)

[James]

Certificates below

server_cert.pem 
-BEGIN CERTIFICATE-
MIICFzCCAb2gAwIBAgIUFo8PqHmoZGe0LnNc3eRT4awebw8wCgYIKoZIzj0EAwIw
RzELMAkGA1UEBhMCR0IxDTALBgNVBAoMBEFjbWUxDzANBgNVBAcMBkxvbmRvbjEY
MBYGA1UEAwwPSW50ZXJtZWRpYXRlIENBMB4XDTI0MDcwMjA5MDIyN1oXDTI0MDgw
MTA5MDIyN1owQDELMAkGA1UEBhMCR0IxDTALBgNVBAoMBEFjbWUxDzANBgNVBAcM
BkxvbmRvbjERMA8GA1UEAwwIMDAwMDAwMDAwWTATBgcqhkjOPQIBBggqhkjOPQMB
BwNCAARW7Cjuhx8AqP7QF/Id1TesVlhjH5v0lP/h1DOqJuo/Ls80TciG2xAk2MUs
dCBY58yt9Bp88mH/6LZ4SESDXyVLo4GNMIGKMB0GA1UdDgQWBBTg+r275a3XNLYN
0iIsHyto5si+LTAfBgNVHSMEGDAWgBTHMX4i9nENo9w05iL9zzkj2TAKCzALBgNV
HQ8EBAMCA6gwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMBwGA1UdEQQV
MBOHBMCo9QGCC3d3dy5hY21lLnVrMAoGCCqGSM49BAMCA0gAMEUCIQDrfSfTN4pW
SJTYGtvU4qedkFWxpmmgcBzvjA+9sgnSSwIgNk9WYtIBXL9TpdKS6LVEFXC4ryLJ
cHYkEQLjz3oivps=
-END CERTIFICATE-

ca_cert.pem 
-BEGIN CERTIFICATE-
MIICWzCCAgCgAwIBAgIUW0O6fufb4ckE6qXytNUo/3pd0w4wCgYIKoZIzj0EAwIw
STELMAkGA1UEBhMCR0IxDTALBgNVBAoMBEFjbWUxDzANBgNVBAcMBkxvbmRvbjEa
MBgGA1UEAwwRUm9vdCBUcnVzdCBBbmNob3IwHhcNMjQwNzAyMDkwMjI3WhcNMjQw
ODAxMDkwMjI3WjBHMQswCQYDVQQGEwJHQjENMAsGA1UECgwEQWNtZTEPMA0GA1UE
BwwGTG9uZG9uMRgwFgYDVQQDDA9JbnRlcm1lZGlhdGUgQ0EwWTATBgcqhkjOPQIB
BggqhkjOPQMBBwNCAATXQh8PlfPAaGb+xIM62RZx4Kw1x9SrPENRdnmChSLKpml/
QH7hwXe/0AM1it/fpmbM5kcu3K4bxuWdTqxo3NTlo4HHMIHEMB0GA1UdDgQWBBTH
MX4i9nENo9w05iL9zzkj2TAKCzCBhAYDVR0jBH0we4AU5Qe6URj2vUTLCdOU0w3/
hOqOY3ehTaRLMEkxCzAJBgNVBAYTAkdCMQ0wCwYDVQQKDARBY21lMQ8wDQYDVQQH
DAZMb25kb24xGjAYBgNVBAMMEVJvb3QgVHJ1c3QgQW5jaG9yghRwa07vsimpdN0b
osty7a5UxseGOTAPBgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBBjAKBggqhkjO
PQQDAgNJADBGAiEA8dZPzN/jiamDMg/PiEzitQ6/4MtgkZU8Ctm23D0Rh6ECIQCr
qgXI45OWrkeKohs3nI4x3chnV5aJIbY6zfEuHNCoPA==
-END CERTIFICATE——

cross_ca_cert.pem 
-BEGIN CERTIFICATE-
MIICYTCCAgegAwIBAgIUaAw01+4GK4YbGj+xmrscuaAHGHMwCgYIKoZIzj0EAwIw
TDELMAkGA1UEBhMCREUxDTALBgNVBAoMBEFjbWUxEjAQBgNVBAcMCUZyYW5rZnVy
dDEaMBgGA1UEAwwRUm9vdCBUcnVzdCBBbmNob3IwHhcNMjQwNzAyMDkwMjI3WhcN
MjQwODAxMDkwMjI3WjBHMQswCQYDVQQGEwJHQjENMAsGA1UECgwEQWNtZTEPMA0G
A1UEBwwGTG9uZG9uMRgwFgYDVQQDDA9JbnRlcm1lZGlhdGUgQ0EwWTATBgcqhkjO
PQIBBggqhkjOPQMBBwNCAATXQh8PlfPAaGb+xIM62RZx4Kw1x9SrPENRdnmChSLK
pml/QH7hwXe/0AM1it/fpmbM5kcu3K4bxuWdTqxo3NTlo4HLMIHIMB0GA1UdDgQW
BBTHMX4i9nENo9w05iL9zzkj2TAKCzCBiAYDVR0jBIGAMH6AFG9KNmMUwPYTelRU
DqhD+oufhyJVoVCkTjBMMQswCQYDVQQGEwJERTENMAsGA1UECgwEQWNtZTESMBAG
A1UEBwwJRnJhbmtmdXJ0MRowGAYDVQQDDBFSb290IFRydXN0IEFuY2hvcoIUBzYe
sKSNrEum7scNDVEUbi2WTXMwDwYDVR0TAQH/BAUwAwEB/zALBgNVHQ8EBAMCAQYw
CgYIKoZIzj0EAwIDSAAwRQIhAMw1H3sl4QLLzBXnkbVBq+ccZXYROhxBEL3IT7+8
CFoEAiBpYLC/KtGfnrZ/C36kn6POtMWkLXwXw15KbCAcP5y2EA==
-END CERTIFICATE-

ta_primary_cert.pem 
-BEGIN CERTIFICATE-
MIICXjCCAgWgAwIBAgIUcGtO77IpqXTdG6LLcu2uVMbHhjkwCgYIKoZIzj0EAwIw
STELMAkGA1UEBhMCR0IxDTALBgNVBAoMBEFjbWUxDzANBgNVBAcMBkxvbmRvbjEa
MBgGA1UEAwwRUm9vdCBUcnVzdCBBbmNob3IwHhcNMjQwNzAyMDkwMjI3WhcNMjQw
ODAxMDkwMjI3WjBJMQswCQYDVQQGEwJHQjENMAsGA1UECgwEQWNtZTEPMA0GA1UE
BwwGTG9uZG9uMRowGAYDVQQDDBFSb290IFRydXN0IEFuY2hvcjBZMBMGByqGSM49
AgEGCCqGSM49AwEHA0IABB5yyiQtTa6dA2BKH0Khy3uP0yzKBFhFI+xWFeS/w1/i
7gXsp36YVFtEWsWhkdqNED2b8A4nATMvUucHpk8SdTGjgcowgccwHQYDVR0OBBYE
FOUHulEY9r1EywnTlNMN/4TqjmN3MIGEBgNVHSMEfTB7gBTlB7pRGPa9RMsJ05TT
Df+E6o5jd6FNpEswSTELMAkGA1UEBhMCR0IxDTALBgNVBAoMBEFjbWUxDzANBgNV
BAcMBkxvbmRvbjEaMBgGA1UEAwwRUm9vdCBUcnVzdCBBbmNob3KCFHBrTu+yKal0
3Ruiy3LtrlTGx4Y5MBIGA1UdEwEB/wQIMAYBAf8CAQIwCwYDVR0PBAQDAgEGMAoG
CCqGSM49BAMCA0cAMEQCICshpNb/ov0f4aqkQIW5/aF1h4NnxKpDC3jIKMphkOoS
AiBLf0BTAuUIYXSqR2sRmlN3m9LhZjIcmHcZe8gKDO10Vw==
-END CERTIFICATE-

ta_secondary_cert.pem 
-BEGIN CERTIFICATE-
MIICaDCCAg+gAwIBAgIUBzYesKSNrEum7scNDVEUbi2WTXMwCgYIKoZIzj0EAwIw
TDELMAkGA1UEBhMCREUxDTALBgNVBAoMBEFjbWUxEjAQBgNVBAcMCUZyYW5rZnVy
dDEaMBgGA1UEAwwRUm9vdCBUcnVzdCBBbmNob3IwHhcNMjQwNzAyMDkwMjI3WhcN
MjQwODAxMDkwMjI3WjBMMQswCQYDVQQGEwJERTENMAsGA1UECgwEQWNtZTESMBAG
A1UEBwwJRnJhbmtmdXJ0MRowGAYDVQQDDBFSb290IFRydXN0IEFuY2hvcjBZMBMG
ByqGSM49AgEGCCqGSM49AwEHA0IABK79uhF9Q3Zex0V2qmlBeFRMfdOL1alKnXXe
T5UhfpIa9i1rOB1xq+KcsQSKfMDRobPRXS05WEEL6Li2PSPO3Eqjgc4wgcswHQYD
VR0OBBYEFG9KNmMUwPYTelRUDqhD+oufhyJVMIGIBgNVHSMEgYAwfoAUb0o2YxTA
9hN6VFQOqEP6i5+HIlWhUKROMEwxCzAJBgNVBAYTAkRFMQ0wCwYDVQQKDARBY21l
MRIwEAYDVQQHDAlGcmFua2Z1cnQxGjAYBgNVBAMMEVJvb3QgVHJ1c3QgQW5jaG9y
ghQHNh6wpI2sS6buxw0NURRuLZZNczASBgNVHRMBAf8ECDAGAQH/AgECMAsGA1Ud
DwQEAwIBBjAKBggqhkjOPQQDAgNHADBEAiAcUUlPZ9gHwRfsY1yzLrdCLW2Jz52A
2Bwa/hgH36PYrAIgZi2VS9PJanSLJQsETdBhlPcSKHWC3ifufXrW+RKSHnc=
-END CERTIFICATE-


> On 2 Jul 2024, at 10:52, Martin Bonner via openssl-users 
>  wrote:
> 
> From: James 
> To: mailto:openssl-users@openssl.org
> Subject: Re: Certificate verification with cross signed CAs
> Message-ID: 
> Content-Type: text/plain; charset="utf-8"
> 
>> The certificates are attached below.
> 
> They got stripped.  Can you include them in a text format in the body
> of your email please?
> 
> --
> Martin Bonner
> Any email and files/attachments 

Re: Certificate verification with cross signed CAs (James)

[Martin Bonner via openssl-users]

From: James 
To: mailto:openssl-users@openssl.org
Subject: Re: Certificate verification with cross signed CAs
Message-ID: 
Content-Type: text/plain; charset="utf-8"

> The certificates are attached below.

They got stripped.  Can you include them in a text format in the body
of your email please?

--
Martin Bonner
Any email and files/attachments transmitted with it are intended solely for the 
use of the individual or entity to whom they are addressed. If this message has 
been sent to you in error, you must not copy, distribute or disclose of the 
information it contains. Please notify Entrust immediately and delete the 
message from your system.

Re: Certificate verification with cross signed CAs

[James]

The certificates are attached below.The use case is client A only has ta_primary_cert.pem and client B only has ta_secondary_cert.pemI’m trying to build a chain that the server can use (in the server hello) so that both client A and client B can successfully connect.Since openssl verify -trusted ta_secondary_cert.pem -untrusted cross_ca_cert.pem server_cert.pem works, I not sure why adding the other untrusted ca certificate would cause verification to fail - there is still a valid path from the leaf to a trusted root.$ openssl versionOpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022)$ openssl verify -trusted ta_primary_cert.pem -untrusted ca_cert.pem server_cert.pem server_cert.pem: OK$ openssl verify -trusted ta_secondary_cert.pem -untrusted cross_ca_cert.pem server_cert.pem server_cert.pem: OK$ openssl verify -trusted ta_secondary_cert.pem -untrusted ca_cert.pem -untrusted cross_ca_cert.pem server_cert.pem C = GB, O = Acme, L = London, CN = Intermediate CAerror 20 at 1 depth lookup: unable to get local issuer certificateerror server_cert.pem: verification failed$ openssl verify -trusted ta_secondary_cert.pem -untrusted cross_ca_cert.pem -untrusted ca_cert.pem server_cert.pem server_cert.pem: OK

ca_cert.pem
Description: application/x509-ca-cert


cross_ca_cert.pem
Description: application/x509-ca-cert


server_cert.pem
Description: application/x509-ca-cert


ta_primary_cert.pem
Description: application/x509-ca-cert


ta_secondary_cert.pem
Description: application/x509-ca-cert
On 2 Jul 2024, at 01:55, Viktor Dukhovni  wrote:Please post the actual certificates in question.  Verification shouldsucceed regardless of which of "ca" or "alt_ca" is listed first,*provided* both roots are trusted, your mistake is specifying only oneroot, with both intermediate issuers.If the CAs are internal CAs you control, the CA could issue certificatescontaining an authority key identifier (AKID) which specifies the theCA's issuer DN (the root CA subject).  This would ensure that the rightissuer is chosen.  In practice, you'd still want to trust both roots.--     Viktor.

Re: Certificate verification with cross signed CAs

[Viktor Dukhovni]

On Mon, Jul 01, 2024 at 03:54:46PM +0100, James Chapman wrote:

> I’ve been using openssl verify to check some certificate chains:
> 
> server -> ca -> roota
> server -> alt_ca-> rootb
> 
> Certificates ca and alt_ca have the same subject and public key and different 
> issuers.
> 
>   openssl verify -trusted roota.pem -untrusted ca.pem server.pem 
>   openssl verify -trusted rootb.pem -untrusted alt_ca.pem server.pem 
> 
> Work fine, however if I include both the intermediate CAs then verify only 
> succeeds when the correct untrusted CA is first in the list
> 
>   openssl verify -trusted roota.pem -untrusted ca.pem -untrusted alt_ca.pem 
> server.pem (OK)
>   openssl verify -trusted rootb.pem -untrusted ca.pem -untrusted alt_ca.pem 
> server.pem (FAIL: error 20 at 1 depth lookup: unable to get local issuer 
> certificate)
> 
> Is there a mechanism to support both ca.pem and alt_ca.pem without knowing 
> which root the client has?

Please post the actual certificates in question.  Verification should
succeed regardless of which of "ca" or "alt_ca" is listed first,
*provided* both roots are trusted, your mistake is specifying only one
root, with both intermediate issuers.

If the CAs are internal CAs you control, the CA could issue certificates
containing an authority key identifier (AKID) which specifies the the
CA's issuer DN (the root CA subject).  This would ensure that the right
issuer is chosen.  In practice, you'd still want to trust both roots.

-- 
Viktor.

Certificate verification with cross signed CAs

[James Chapman]

I’ve been using openssl verify to check some certificate chains:

server -> ca -> roota
server -> alt_ca-> rootb

Certificates ca and alt_ca have the same subject and public key and different 
issuers.

openssl verify -trusted roota.pem -untrusted ca.pem server.pem 
openssl verify -trusted rootb.pem -untrusted alt_ca.pem server.pem 

Work fine, however if I include both the intermediate CAs then verify only 
succeeds when the correct untrusted CA is first in the list

openssl verify -trusted roota.pem -untrusted ca.pem -untrusted alt_ca.pem 
server.pem (OK)
openssl verify -trusted rootb.pem -untrusted ca.pem -untrusted alt_ca.pem 
server.pem (FAIL: error 20 at 1 depth lookup: unable to get local issuer 
certificate)

Is there a mechanism to support both ca.pem and alt_ca.pem without knowing 
which root the client has?

Many thanks
James

Re: Missing header file ts_local.h in install location.

[Tomas Mraz]

Yes, they should search for TS_VERIFY_CTX_set_certs or
TS_VERIFY_CTX_set_flags (that would work for 1.1.1 as well).

Tomas Mraz, OpenSS

On Fri, 2024-06-28 at 20:04 +, BENTLEY Thom wrote:
> 
> 
> 
> Does this Bing CoPilot response suggest that DCMTK’s CMake
> configuration should be searching for a different function name?
> 
> The HAVE_OPENSSL_PROTOTYPE_TS_VERIFY_CTS_SET_CERTS is a macro that
> checks for the existence of the TS_VERIFY_CTS_set_certs function in
> OpenSSL1. This function is used to set the server’s certificate chain
> when verifying a TimeStampToken (TST)1.
> 
> However, starting from OpenSSL 3.0.0, the correct spelling of the
> function is TS_VERIFY_CTX_set_certs, and the misspelled
> version TS_VERIFY_CTS_set_certs has been retained for compatibility
> reasons, but it is deprecated1.
> 
> This could potentially cause issues if DCMTK 3.6.8 is not properly
> configured to handle this change in OpenSSL 3.0.8.
>  
>  
> 
> 
>  
>  
> Thom Bentley| Senior Software Engineer |
> Medidata, a Dassault Systèmes company
>  
> 
> 
> From: Matt Caswell 
> Sent: Friday, June 28, 2024 11:54 AM
> To: BENTLEY Thom ; Tomas Mraz
> ; openssl-users@openssl.org
> Subject: Re: Missing header file ts_local.h in install location.
>  
> 
> 
> On 28/06/2024 16: 29, BENTLEY Thom via openssl-users wrote: > Thanks.
> Yes, I saw that they became opaque. > The code I’m building works
> fine with 1. 1. 1w but we need to move to > 3. 0. 8 at least. > Here
> are the errors I see. > > 
> 
>  
>  
> On 28/06/2024 16:29, BENTLEY Thom via openssl-users wrote:
> > Thanks.  Yes, I saw that they became opaque.
> > The code I’m building works fine with 1.1.1w but we need to move to
> > 3.0.8 at least.
> > Here are the errors I see.
> > 
> > dcmdsig:
> > 16:34:48:290 
> > 19>C:\repos\mmi-director-dcmtk-3.6.8\dcmtk-
> > 3.6.8\dcmsign\libsrc\sitstamp.cc(1342,5): error C2027: use of
> > undefined type 'TS_verify_ctx'
> > 16:34:48:290 
> > 19>C:\repos\mmi-director-dcmtk-3.6.8\openssl-
> > 3.0.8\include\openssl\ts.h(405,16):
> > 16:34:48:290 19>see declaration of 'TS_verify_ctx'
>  
>  
> It looks to me like DCMTK needs updating to use OpenSSL 3.x
>  
> This particular error occurs because line 1342 of sitstamp.cc looks
> like 
> this:
>  
>  TS_VERIFY_CTS_set_certs(ctx, NULL);
>  
> Earlier on in that file we see this:
>  
> #ifndef HAVE_OPENSSL_PROTOTYPE_TS_VERIFY_CTS_SET_CERTS
> #define TS_VERIFY_CTS_set_certs(x,y) ((x)->certs = (y))
> #endif
>  
> So if HAVE_OPENSSL_PROTOTYPE_TS_VERIFY_CTS_SET_CERTS isn't defined
> then 
> it will attempt to look inside the TS_VERIFY_CTX structure - which is
> not allowed from 1.1.1 onwards because it is opaque.
>  
> My guess is the setting of 
> HAVE_OPENSSL_PROTOTYPE_TS_VERIFY_CTS_SET_CERTS is going wrong with 
> OpenSSL 3.X
>  
> It seems to get defined by Cmake/dcmtkPrepare.cmake:
>  
>    CHECK_FUNCTIONWITHHEADER_EXISTS("TS_VERIFY_CTS_set_certs(0,0)" 
> "openssl/ts.h" HAVE_OPENSSL_PROTOTYPE_TS_VERIFY_CTS_SET_CERTS)
>  
> Indeed that function header does *not* exist in 3.x because it is 
> instead a macro:
>  
> # ifndef OPENSSL_NO_DEPRECATED_3_0
> #  define TS_VERIFY_CTS_set_certs(ctx, cert) 
> TS_VERIFY_CTX_set_certs(ctx,cert)
> # endif
>  
> In 1.1.1 this was a full C function so the cmake detection would have
> worked correctly there.
>  
> Matt
>  
>  
>  
> > 
> > dcmpstat:
> > 16:36:48:689 
> > 34>C:\repos\mmi-director-dcmtk-3.6.8\openssl-
> > 3.0.8\include\openssl\types.h(104,30): error C2371: 'EVP_MD_CTX':
> > redefinition; different basic types
> > 16:36:48:753 34>(compiling source file 
> > '../../../dcmtk-3.6.8/dcmpstat/libsrc/dvsighdl.cc')
> > 16:36:48:753 
> > 34>C:\repos\mmi-director-dcmtk-3.6.8\dcmtk-
> > 3.6.8\dcmsign\include\dcmtk\dcmsign\simdmac.h(39,30):
> > 16:36:48:753 34>see declaration of 'EVP_MD_CTX'
> > 
> > dcmtls:
> > 16:35:16:392 
> > 26>C:\repos\mmi-director-dcmtk-3.6.8\dcmtk-
> > 3.6.8\dcmtls\libsrc\tlsciphr.cc(238,32): error C2027: use of
> > undefined type 'ssl_ctx_st'
> > 16:35:16:392 
> > 26>C:\repos\mmi-director-dcmtk-3.6.8\dcmtk-
> > 3.6.8\dcmtls\include\dcmtk\dcmtls\tlslayer.h(37,8):
> > 16:35:16:392 26>see declaration of 'ssl_ctx_st'
> > 
> > **
> > 
> > **
> > 
> > *Thom Bentley *| Senior Software Engineer |Medidata, a Dassault
> > Systèmes 
> > company 
> > 
> > *From:*Tomas Mraz 
> > *Sent:* Friday, June 28, 2024 10:15 AM
> > *To:* BENTLEY Thom ;
> > openssl-users@openssl.org
> > *Subject:* Re: Missing header file ts_local.h in install location.
> > 
> > TS_VERIFY_CTX is an opaque structure since version 1. 1. 0. You may
> > not 
> > access its members directly. To set them you need to use the
> > various 
> > TS_VERIFY_CTX_set* functions. If there are any particular accessors
> > missing, please report that as a
> > 
> > TS_VERIFY_CTX is an opaque structure since version 1.1.0. You may
> > not
> > 
> > access its members directly. To set them you need to use the
> > various
> > 
> > TS_VERIFY_CTX_set* functions.
> > 
> 

RE: Missing header file ts_local.h in install location.

[BENTLEY Thom via openssl-users]

Does this Bing CoPilot response suggest that DCMTK’s CMake configuration should 
be searching for a different function name?


The HAVE_OPENSSL_PROTOTYPE_TS_VERIFY_CTS_SET_CERTS is a macro that checks for 
the existence of the TS_VERIFY_CTS_set_certs function in 
OpenSSL1.
 This function is used to set the server’s certificate chain when verifying a 
TimeStampToken 
(TST)1.

However, starting from OpenSSL 3.0.0, the correct spelling of the function is 
TS_VERIFY_CTX_set_certs, and the misspelled version TS_VERIFY_CTS_set_certs has 
been retained for compatibility reasons, but it is 
deprecated1.

This could potentially cause issues if DCMTK 3.6.8 is not properly configured 
to handle this change in OpenSSL 3.0.8.




Thom Bentley | Senior Software Engineer | Medidata, a Dassault Systèmes 
company

From: Matt Caswell 
Sent: Friday, June 28, 2024 11:54 AM
To: BENTLEY Thom ; Tomas Mraz ; 
openssl-users@openssl.org
Subject: Re: Missing header file ts_local.h in install location.

On 28/06/2024 16: 29, BENTLEY Thom via openssl-users wrote: > Thanks. Yes, I 
saw that they became opaque. > The code I’m building works fine with 1. 1. 1w 
but we need to move to > 3. 0. 8 at least. > Here are the errors I see. > >






On 28/06/2024 16:29, BENTLEY Thom via openssl-users wrote:

> Thanks.  Yes, I saw that they became opaque.

> The code I’m building works fine with 1.1.1w but we need to move to

> 3.0.8 at least.

> Here are the errors I see.

>

> dcmdsig:

> 16:34:48:290

> 19>C:\repos\mmi-director-dcmtk-3.6.8\dcmtk-3.6.8\dcmsign\libsrc\sitstamp.cc(1342,5):
>  error C2027: use of undefined type 'TS_verify_ctx'

> 16:34:48:290

> 19>C:\repos\mmi-director-dcmtk-3.6.8\openssl-3.0.8\include\openssl\ts.h(405,16):

> 16:34:48:290 19>see declaration of 'TS_verify_ctx'





It looks to me like DCMTK needs updating to use OpenSSL 3.x



This particular error occurs because line 1342 of sitstamp.cc looks like

this:



 TS_VERIFY_CTS_set_certs(ctx, NULL);



Earlier on in that file we see this:



#ifndef HAVE_OPENSSL_PROTOTYPE_TS_VERIFY_CTS_SET_CERTS

#define TS_VERIFY_CTS_set_certs(x,y) ((x)->certs = (y))

#endif



So if HAVE_OPENSSL_PROTOTYPE_TS_VERIFY_CTS_SET_CERTS isn't defined then

it will attempt to look inside the TS_VERIFY_CTX structure - which is

not allowed from 1.1.1 onwards because it is opaque.



My guess is the setting of

HAVE_OPENSSL_PROTOTYPE_TS_VERIFY_CTS_SET_CERTS is going wrong with

OpenSSL 3.X



It seems to get defined by Cmake/dcmtkPrepare.cmake:



   CHECK_FUNCTIONWITHHEADER_EXISTS("TS_VERIFY_CTS_set_certs(0,0)"

"openssl/ts.h" HAVE_OPENSSL_PROTOTYPE_TS_VERIFY_CTS_SET_CERTS)



Indeed that function header does *not* exist in 3.x because it is

instead a macro:



# ifndef OPENSSL_NO_DEPRECATED_3_0

#  define TS_VERIFY_CTS_set_certs(ctx, cert)

TS_VERIFY_CTX_set_certs(ctx,cert)

# endif



In 1.1.1 this was a full C function so the cmake detection would have

worked correctly there.



Matt







>

> dcmpstat:

> 16:36:48:689

> 34>C:\repos\mmi-director-dcmtk-3.6.8\openssl-3.0.8\include\openssl\types.h(104,30):
>  error C2371: 'EVP_MD_CTX': redefinition; different basic types

> 16:36:48:753 34>(compiling source file

> '../../../dcmtk-3.6.8/dcmpstat/libsrc/dvsighdl.cc')

> 16:36:48:753

> 34>C:\repos\mmi-director-dcmtk-3.6.8\dcmtk-3.6.8\dcmsign\include\dcmtk\dcmsign\simdmac.h(39,30):

> 16:36:48:753 34>see declaration of 'EVP_MD_CTX'

>

> dcmtls:

> 16:35:16:392

> 26>C:\repos\mmi-director-dcmtk-3.6.8\dcmtk-3.6.8\dcmtls\libsrc\tlsciphr.cc(238,32):
>  error C2027: use of undefined type 'ssl_ctx_st'

> 16:35:16:392

> 26>C:\repos\mmi-director-dcmtk-3.6.8\dcmtk-3.6.8\dcmtls\include\dcmtk\dcmtls\tlslayer.h(37,8):

> 16:35:16:392 26>see declaration of 'ssl_ctx_st'

>

> **

>

> **

>

> *Thom Bentley *| Senior Software Engineer |Medidata, a Dassault Systèmes

> company 

>

> *From:*Tomas Mraz mailto:to...@openssl.org>>

> *Sent:* Friday, June 28, 2024 10:15 AM

> *To:* BENTLEY Thom mailto:thom.bent...@3ds.com>>; 
> openssl-users@openssl.org

> *Subject:* Re: Missing header file ts_local.h in install location.

>

> TS_VERIFY_CTX is an opaque structure since version 1. 1. 0. You may not

> access its members directly. To set them you need to use the various

> TS_VERIFY_CTX_set* functions. If there are any particular accessors

> missing, please report that as a

>

> TS_VERIFY_CTX is an opaque structure since version 1.1.0. You may not

>

> access its members directly. To set them you need 

Re: Missing header file ts_local.h in install location.

[BENTLEY Thom via openssl-users]

Hi Matt,
Yeah,  that’s what I thought too, but they claim they built it with openssl 
3.0.8 in their INSTALL file.
https://github.com/DCMTK/dcmtk/blob/59f75a8b50e50ae1bb1ff12098040c6327500740/INSTALL#L219
I have also posted on their discussion board.

Thanks.

--
Thom Bentley | Senior Software Engineer |Medidata, a Dassault Systèmes company
thom.bent...@3ds.com


From: Matt Caswell 
Date: Friday, June 28, 2024 at 11:53 AM
To: BENTLEY Thom , Tomas Mraz , 
"openssl-users@openssl.org" 
Subject: Re: Missing header file ts_local.h in install location.

On 28/06/2024 16: 29, BENTLEY Thom via openssl-users wrote: > Thanks. Yes, I 
saw that they became opaque. > The code I’m building works fine with 1. 1. 1w 
but we need to move to > 3. 0. 8 at least. > Here are the errors I see. > >






On 28/06/2024 16:29, BENTLEY Thom via openssl-users wrote:

> Thanks.  Yes, I saw that they became opaque.

> The code I’m building works fine with 1.1.1w but we need to move to

> 3.0.8 at least.

> Here are the errors I see.

>

> dcmdsig:

> 16:34:48:290

> 19>C:\repos\mmi-director-dcmtk-3.6.8\dcmtk-3.6.8\dcmsign\libsrc\sitstamp.cc(1342,5):
>  error C2027: use of undefined type 'TS_verify_ctx'

> 16:34:48:290

> 19>C:\repos\mmi-director-dcmtk-3.6.8\openssl-3.0.8\include\openssl\ts.h(405,16):

> 16:34:48:290 19>see declaration of 'TS_verify_ctx'





It looks to me like DCMTK needs updating to use OpenSSL 3.x



This particular error occurs because line 1342 of sitstamp.cc looks like

this:



 TS_VERIFY_CTS_set_certs(ctx, NULL);



Earlier on in that file we see this:



#ifndef HAVE_OPENSSL_PROTOTYPE_TS_VERIFY_CTS_SET_CERTS

#define TS_VERIFY_CTS_set_certs(x,y) ((x)->certs = (y))

#endif



So if HAVE_OPENSSL_PROTOTYPE_TS_VERIFY_CTS_SET_CERTS isn't defined then

it will attempt to look inside the TS_VERIFY_CTX structure - which is

not allowed from 1.1.1 onwards because it is opaque.



My guess is the setting of

HAVE_OPENSSL_PROTOTYPE_TS_VERIFY_CTS_SET_CERTS is going wrong with

OpenSSL 3.X



It seems to get defined by Cmake/dcmtkPrepare.cmake:



   CHECK_FUNCTIONWITHHEADER_EXISTS("TS_VERIFY_CTS_set_certs(0,0)"

"openssl/ts.h" HAVE_OPENSSL_PROTOTYPE_TS_VERIFY_CTS_SET_CERTS)



Indeed that function header does *not* exist in 3.x because it is

instead a macro:



# ifndef OPENSSL_NO_DEPRECATED_3_0

#  define TS_VERIFY_CTS_set_certs(ctx, cert)

TS_VERIFY_CTX_set_certs(ctx,cert)

# endif



In 1.1.1 this was a full C function so the cmake detection would have

worked correctly there.



Matt







>

> dcmpstat:

> 16:36:48:689

> 34>C:\repos\mmi-director-dcmtk-3.6.8\openssl-3.0.8\include\openssl\types.h(104,30):
>  error C2371: 'EVP_MD_CTX': redefinition; different basic types

> 16:36:48:753 34>(compiling source file

> '../../../dcmtk-3.6.8/dcmpstat/libsrc/dvsighdl.cc')

> 16:36:48:753

> 34>C:\repos\mmi-director-dcmtk-3.6.8\dcmtk-3.6.8\dcmsign\include\dcmtk\dcmsign\simdmac.h(39,30):

> 16:36:48:753 34>see declaration of 'EVP_MD_CTX'

>

> dcmtls:

> 16:35:16:392

> 26>C:\repos\mmi-director-dcmtk-3.6.8\dcmtk-3.6.8\dcmtls\libsrc\tlsciphr.cc(238,32):
>  error C2027: use of undefined type 'ssl_ctx_st'

> 16:35:16:392

> 26>C:\repos\mmi-director-dcmtk-3.6.8\dcmtk-3.6.8\dcmtls\include\dcmtk\dcmtls\tlslayer.h(37,8):

> 16:35:16:392 26>see declaration of 'ssl_ctx_st'

>

> **

>

> **

>

> *Thom Bentley *| Senior Software Engineer |Medidata, a Dassault Systèmes

> company 

>

> *From:*Tomas Mraz 

> *Sent:* Friday, June 28, 2024 10:15 AM

> *To:* BENTLEY Thom ; openssl-users@openssl.org

> *Subject:* Re: Missing header file ts_local.h in install location.

>

> TS_VERIFY_CTX is an opaque structure since version 1. 1. 0. You may not

> access its members directly. To set them you need to use the various

> TS_VERIFY_CTX_set* functions. If there are any particular accessors

> missing, please report that as a

>

> TS_VERIFY_CTX is an opaque structure since version 1.1.0. You may not

>

> access its members directly. To set them you need to use the various

>

> TS_VERIFY_CTX_set* functions.

>

> If there are any particular accessors missing, please report that as a

>

> bug to

> https://urldefense.com/v3/__https://github.com/openssl/openssl__;!!FbCVDoc3r24SyHFW!8NySO-tJ589YiMdFNLtEu_6Hc7knvKgfTOXGkAFWjfEMxLaE5oRe3igKb4JOdd9HiiJ8sLVdiV6SYZo$[github[.]com]

Re: Missing header file ts_local.h in install location.

[Matt Caswell]

On 28/06/2024 16:29, BENTLEY Thom via openssl-users wrote:

Thanks.  Yes, I saw that they became opaque.
The code I’m building works fine with 1.1.1w but we need to move to 
3.0.8 at least.

Here are the errors I see.

dcmdsig:
16:34:48:290 
19>C:\repos\mmi-director-dcmtk-3.6.8\dcmtk-3.6.8\dcmsign\libsrc\sitstamp.cc(1342,5): error C2027: use of undefined type 'TS_verify_ctx'
16:34:48:290 
19>C:\repos\mmi-director-dcmtk-3.6.8\openssl-3.0.8\include\openssl\ts.h(405,16):

16:34:48:290 19>see declaration of 'TS_verify_ctx'



It looks to me like DCMTK needs updating to use OpenSSL 3.x

This particular error occurs because line 1342 of sitstamp.cc looks like 
this:


TS_VERIFY_CTS_set_certs(ctx, NULL);

Earlier on in that file we see this:

#ifndef HAVE_OPENSSL_PROTOTYPE_TS_VERIFY_CTS_SET_CERTS
#define TS_VERIFY_CTS_set_certs(x,y) ((x)->certs = (y))
#endif

So if HAVE_OPENSSL_PROTOTYPE_TS_VERIFY_CTS_SET_CERTS isn't defined then 
it will attempt to look inside the TS_VERIFY_CTX structure - which is 
not allowed from 1.1.1 onwards because it is opaque.


My guess is the setting of 
HAVE_OPENSSL_PROTOTYPE_TS_VERIFY_CTS_SET_CERTS is going wrong with 
OpenSSL 3.X


It seems to get defined by Cmake/dcmtkPrepare.cmake:

  CHECK_FUNCTIONWITHHEADER_EXISTS("TS_VERIFY_CTS_set_certs(0,0)" 
"openssl/ts.h" HAVE_OPENSSL_PROTOTYPE_TS_VERIFY_CTS_SET_CERTS)


Indeed that function header does *not* exist in 3.x because it is 
instead a macro:


# ifndef OPENSSL_NO_DEPRECATED_3_0
#  define TS_VERIFY_CTS_set_certs(ctx, cert) 
TS_VERIFY_CTX_set_certs(ctx,cert)

# endif

In 1.1.1 this was a full C function so the cmake detection would have 
worked correctly there.


Matt





dcmpstat:
16:36:48:689 
34>C:\repos\mmi-director-dcmtk-3.6.8\openssl-3.0.8\include\openssl\types.h(104,30): error C2371: 'EVP_MD_CTX': redefinition; different basic types
16:36:48:753 34>(compiling source file 
'../../../dcmtk-3.6.8/dcmpstat/libsrc/dvsighdl.cc')
16:36:48:753 
34>C:\repos\mmi-director-dcmtk-3.6.8\dcmtk-3.6.8\dcmsign\include\dcmtk\dcmsign\simdmac.h(39,30):

16:36:48:753 34>see declaration of 'EVP_MD_CTX'

dcmtls:
16:35:16:392 
26>C:\repos\mmi-director-dcmtk-3.6.8\dcmtk-3.6.8\dcmtls\libsrc\tlsciphr.cc(238,32): error C2027: use of undefined type 'ssl_ctx_st'
16:35:16:392 
26>C:\repos\mmi-director-dcmtk-3.6.8\dcmtk-3.6.8\dcmtls\include\dcmtk\dcmtls\tlslayer.h(37,8):

16:35:16:392 26>see declaration of 'ssl_ctx_st'

**

**

*Thom Bentley *| Senior Software Engineer |Medidata, a Dassault Systèmes 
company 


*From:*Tomas Mraz 
*Sent:* Friday, June 28, 2024 10:15 AM
*To:* BENTLEY Thom ; openssl-users@openssl.org
*Subject:* Re: Missing header file ts_local.h in install location.

TS_VERIFY_CTX is an opaque structure since version 1. 1. 0. You may not 
access its members directly. To set them you need to use the various 
TS_VERIFY_CTX_set* functions. If there are any particular accessors 
missing, please report that as a


TS_VERIFY_CTX is an opaque structure since version 1.1.0. You may not

access its members directly. To set them you need to use the various

TS_VERIFY_CTX_set* functions.

If there are any particular accessors missing, please report that as a

bug to 
https://urldefense.com/v3/__https://github.com/openssl/openssl__;!!FbCVDoc3r24SyHFW!8NySO-tJ589YiMdFNLtEu_6Hc7knvKgfTOXGkAFWjfEMxLaE5oRe3igKb4JOdd9HiiJ8sLVdiV6SYZo$ [github[.]com]


Tomas Mraz, OpenSSL

On Fri, 2024-06-28 at 14:09 +, BENTLEY Thom via openssl-users

wrote:













Hi All, 


 



I build and installed version 3.0.8 on Windows with Visual Studio



using the instructions provided.



I copied the bin, include, and lib directories to a location that



would be found by the CMake for the



DCMTK toolkit version 3.6.8.



When I attempt to build the DCMTK toolkit, I see that the ts.h value



can’t find the definition ofTS_verify_ctx.



That’s because of the missing ts_local.h as far as I can see.


 



Is there something I missed in the build of the libraries and the



install package?



Thank.


 










 


 



Thom Bentley| Senior Software Engineer |



Medidata, a Dassault Systèmes company


 



This email and any attachments are intended solely for the use of the



individual or entity to whom it is addressed and may be confidential



and/or privileged.



If you are not one of the named recipients or have received this



email in error,



(i) you should not read, disclose, or copy it,



(ii) please notify sender of your receipt by reply email and delete



this email and all attachments,



(iii) Dassault Systèmes does not accept or assume any liability or



responsibility for any use of or reliance on this email.







Please be informed that your personal data are processed according to



our data privacy policy as described on our website. Should 

RE: Missing header file ts_local.h in install location.

[BENTLEY Thom via openssl-users]

Thanks.  Yes, I saw that they became opaque.
The code I’m building works fine with 1.1.1w but we need to move to 3.0.8 at 
least.
Here are the errors I see.
dcmdsig:
16:34:48:290 
19>C:\repos\mmi-director-dcmtk-3.6.8\dcmtk-3.6.8\dcmsign\libsrc\sitstamp.cc(1342,5):
 error C2027: use of undefined type 'TS_verify_ctx'
16:34:48:290 
19>C:\repos\mmi-director-dcmtk-3.6.8\openssl-3.0.8\include\openssl\ts.h(405,16):
16:34:48:290 19>see declaration of 'TS_verify_ctx'

dcmpstat:
16:36:48:689 
34>C:\repos\mmi-director-dcmtk-3.6.8\openssl-3.0.8\include\openssl\types.h(104,30):
 error C2371: 'EVP_MD_CTX': redefinition; different basic types
16:36:48:753 34>(compiling source file 
'../../../dcmtk-3.6.8/dcmpstat/libsrc/dvsighdl.cc')
16:36:48:753 
34>C:\repos\mmi-director-dcmtk-3.6.8\dcmtk-3.6.8\dcmsign\include\dcmtk\dcmsign\simdmac.h(39,30):
16:36:48:753 34>see declaration of 'EVP_MD_CTX'

dcmtls:
16:35:16:392 
26>C:\repos\mmi-director-dcmtk-3.6.8\dcmtk-3.6.8\dcmtls\libsrc\tlsciphr.cc(238,32):
 error C2027: use of undefined type 'ssl_ctx_st'
16:35:16:392 
26>C:\repos\mmi-director-dcmtk-3.6.8\dcmtk-3.6.8\dcmtls\include\dcmtk\dcmtls\tlslayer.h(37,8):
16:35:16:392 26>see declaration of 'ssl_ctx_st'



Thom Bentley | Senior Software Engineer | Medidata, a Dassault Systèmes 
company

From: Tomas Mraz 
Sent: Friday, June 28, 2024 10:15 AM
To: BENTLEY Thom ; openssl-users@openssl.org
Subject: Re: Missing header file ts_local.h in install location.

TS_VERIFY_CTX is an opaque structure since version 1. 1. 0. You may not access 
its members directly. To set them you need to use the various 
TS_VERIFY_CTX_set* functions. If there are any particular accessors missing, 
please report that as a


TS_VERIFY_CTX is an opaque structure since version 1.1.0. You may not

access its members directly. To set them you need to use the various

TS_VERIFY_CTX_set* functions.



If there are any particular accessors missing, please report that as a

bug to 
https://urldefense.com/v3/__https://github.com/openssl/openssl__;!!FbCVDoc3r24SyHFW!8NySO-tJ589YiMdFNLtEu_6Hc7knvKgfTOXGkAFWjfEMxLaE5oRe3igKb4JOdd9HiiJ8sLVdiV6SYZo$[github[.]com]





Tomas Mraz, OpenSSL





On Fri, 2024-06-28 at 14:09 +, BENTLEY Thom via openssl-users

wrote:

>

>

>

> Hi All,

>

> I build and installed version 3.0.8 on Windows with Visual Studio

> using the instructions provided.

> I copied the bin, include, and lib directories to a location that

> would be found by the CMake for the

> DCMTK toolkit version 3.6.8.

> When I attempt to build the DCMTK toolkit, I see that the ts.h value

> can’t find the definition ofTS_verify_ctx.

> That’s because of the missing ts_local.h as far as I can see.

>

> Is there something I missed in the build of the libraries and the

> install package?

> Thank.

>

>

>

>

>

> Thom Bentley| Senior Software Engineer |

> Medidata, a Dassault Systèmes company

>

> This email and any attachments are intended solely for the use of the

> individual or entity to whom it is addressed and may be confidential

> and/or privileged.

> If you are not one of the named recipients or have received this

> email in error,

> (i) you should not read, disclose, or copy it,

> (ii) please notify sender of your receipt by reply email and delete

> this email and all attachments,

> (iii) Dassault Systèmes does not accept or assume any liability or

> responsibility for any use of or reliance on this email.

>

> Please be informed that your personal data are processed according to

> our data privacy policy as described on our website. Should you have

> any questions related to personal data protection, please contact 3DS

> Data Protection Officerhttps://www.3ds.com/privacy-policy/contact/

>

>



--

Tomáš Mráz, OpenSSL



This email and any attachments are intended solely for the use of the 
individual or entity to whom it is addressed and may be confidential and/or 
privileged.

If you are not one of the named recipients or have received this email in error,

(i) you should not read, disclose, or copy it,

(ii) please notify sender of your receipt by reply email and delete this email 
and all attachments,

(iii) Dassault Systèmes does not accept or assume any liability or 
responsibility for any use of or reliance on this email.


Please be informed that your personal data are processed according to our data 
privacy policy as described on our website. Should you have any questions 
related to personal data protection, please contact 3DS Data Protection Officer 
https://www.3ds.com/privacy-policy/contact/

RE: Missing header file ts_local.h in install location.

[BENTLEY Thom via openssl-users]

Here are the compile errors I’m getting.
dcmdsig:
16:34:48:290 
19>C:\repos\mmi-director-dcmtk-3.6.8\dcmtk-3.6.8\dcmsign\libsrc\sitstamp.cc(1342,5):
 error C2027: use of undefined type 'TS_verify_ctx'
16:34:48:290 
19>C:\repos\mmi-director-dcmtk-3.6.8\openssl-3.0.8\include\openssl\ts.h(405,16):
16:34:48:290 19>see declaration of 'TS_verify_ctx'

dcmpstat:
16:36:48:689 
34>C:\repos\mmi-director-dcmtk-3.6.8\openssl-3.0.8\include\openssl\types.h(104,30):
 error C2371: 'EVP_MD_CTX': redefinition; different basic types
16:36:48:753 34>(compiling source file 
'../../../dcmtk-3.6.8/dcmpstat/libsrc/dvsighdl.cc')
16:36:48:753 
34>C:\repos\mmi-director-dcmtk-3.6.8\dcmtk-3.6.8\dcmsign\include\dcmtk\dcmsign\simdmac.h(39,30):
16:36:48:753 34>see declaration of 'EVP_MD_CTX'

dcmtls:
16:35:16:392 
26>C:\repos\mmi-director-dcmtk-3.6.8\dcmtk-3.6.8\dcmtls\libsrc\tlsciphr.cc(238,32):
 error C2027: use of undefined type 'ssl_ctx_st'
16:35:16:392 
26>C:\repos\mmi-director-dcmtk-3.6.8\dcmtk-3.6.8\dcmtls\include\dcmtk\dcmtls\tlslayer.h(37,8):
16:35:16:392 26>see declaration of 'ssl_ctx_st'



Thom Bentley | Senior Software Engineer | Medidata, a Dassault Systèmes 
company

From: Matt Caswell 
Sent: Friday, June 28, 2024 10:18 AM
To: BENTLEY Thom ; openssl-users@openssl.org
Subject: Re: Missing header file ts_local.h in install location.

On 28/06/2024 15: 09, BENTLEY Thom via openssl-users wrote: > Hi All, > > I 
build and installed version 3. 0. 8 on Windows with Visual Studio using > the 
instructions provided. > I copied the bin, include, and lib directories to






On 28/06/2024 15:09, BENTLEY Thom via openssl-users wrote:

> Hi All,

>

> I build and installed version 3.0.8 on Windows with Visual Studio using

> the instructions provided.

> I copied the bin, include, and lib directories to a location that would

> be found by the CMake for the

>

> DCMTK toolkit version 3.6.8.

>

> When I attempt to build the DCMTK toolkit, I see that the ts.h value

> can’t find the definition of TS_verify_ctx.

> That’s because of the missing ts_local.h as far as I can see.

>



What exactly is the error you are seeing?



ts_local.h is an internal header file that applications external to

OpenSSL should not need. The TS_VERIFY_CTX type is *opaque* and

applications using it should not need to have the structure definition.



Having a very quick look at the code in 
https://urldefense.com/v3/__https://github.com/DCMTK/dcmtk__;!!FbCVDoc3r24SyHFW!7UVHjNIJ1w_3RzAEzzTZpLBeLwyxFY5CwqNobpaFwKRs_B1TJHgU9dat_WFkpY0MNOliv4wHJTnxfw$[github[.]com],

I don't see it referring to any internal contents of TS_VERIFY_CTX. It

just passes it around as a pointer object - which should be fine.



Matt





> Is there something I missed in the build of the libraries and the

> install package?

>

> Thank.

>

> **

>

> **

>

> *Thom Bentley *| Senior Software Engineer |Medidata, a Dassault Systèmes

> company 

>

> This email and any attachments are intended solely for the use of the

> individual or entity to whom it is addressed and may be confidential

> and/or privileged.

>

> If you are not one of the named recipients or have received this email

> in error,

>

> (i) you should not read, disclose, or copy it,

>

> (ii) please notify sender of your receipt by reply email and delete this

> email and all attachments,

>

> (iii) Dassault Systèmes does not accept or assume any liability or

> responsibility for any use of or reliance on this email.

>

>

> Please be informed that your personal data are processed according to

> our data privacy policy as described on our website. Should you have any

> questions related to personal data protection, please contact 3DS Data

> Protection Officer https://www.3ds.com/privacy-policy/contact/

> 

>

>

This email and any attachments are intended solely for the use of the 
individual or entity to whom it is addressed and may be confidential and/or 
privileged.

If you are not one of the named recipients or have received this email in error,

(i) you should not read, disclose, or copy it,

(ii) please notify sender of your receipt by reply email and delete this email 
and all attachments,

(iii) Dassault Systèmes does not accept or assume any liability or 
responsibility for any use of or reliance on this email.


Please be informed that your personal data are processed according to our data 
privacy policy as described on our website. Should you have any questions 
related to personal data protection, please contact 3DS Data Protection Officer 
https://www.3ds.com/privacy-policy/contact/

Re: Missing header file ts_local.h in install location.

[Matt Caswell]

On 28/06/2024 15:09, BENTLEY Thom via openssl-users wrote:

Hi All,

I build and installed version 3.0.8 on Windows with Visual Studio using 
the instructions provided.
I copied the bin, include, and lib directories to a location that would 
be found by the CMake for the


DCMTK toolkit version 3.6.8.

When I attempt to build the DCMTK toolkit, I see that the ts.h value 
can’t find the definition of TS_verify_ctx.

That’s because of the missing ts_local.h as far as I can see.



What exactly is the error you are seeing?

ts_local.h is an internal header file that applications external to 
OpenSSL should not need. The TS_VERIFY_CTX type is *opaque* and 
applications using it should not need to have the structure definition.


Having a very quick look at the code in https://github.com/DCMTK/dcmtk, 
I don't see it referring to any internal contents of TS_VERIFY_CTX. It 
just passes it around as a pointer object - which should be fine.


Matt


Is there something I missed in the build of the libraries and the 
install package?


Thank.

**

**

*Thom Bentley *| Senior Software Engineer |Medidata, a Dassault Systèmes 
company 


This email and any attachments are intended solely for the use of the 
individual or entity to whom it is addressed and may be confidential 
and/or privileged.


If you are not one of the named recipients or have received this email 
in error,


(i) you should not read, disclose, or copy it,

(ii) please notify sender of your receipt by reply email and delete this 
email and all attachments,


(iii) Dassault Systèmes does not accept or assume any liability or 
responsibility for any use of or reliance on this email.



Please be informed that your personal data are processed according to 
our data privacy policy as described on our website. Should you have any 
questions related to personal data protection, please contact 3DS Data 
Protection Officer https://www.3ds.com/privacy-policy/contact/ 

Re: Missing header file ts_local.h in install location.

[Tomas Mraz]

TS_VERIFY_CTX is an opaque structure since version 1.1.0. You may not
access its members directly. To set them you need to use the various
TS_VERIFY_CTX_set* functions.

If there are any particular accessors missing, please report that as a
bug to https://github.com/openssl/openssl


Tomas Mraz, OpenSSL


On Fri, 2024-06-28 at 14:09 +, BENTLEY Thom via openssl-users
wrote:
> 
> 
> 
> Hi All, 
>  
> I build and installed version 3.0.8 on Windows with Visual Studio
> using the instructions provided.
> I copied the bin, include, and lib directories to a location that
> would be found by the CMake for the
> DCMTK toolkit version 3.6.8.
> When I attempt to build the DCMTK toolkit, I see that the ts.h value
> can’t find the definition ofTS_verify_ctx.
> That’s because of the missing ts_local.h as far as I can see.
>  
> Is there something I missed in the build of the libraries and the
> install package?
> Thank.
>  
> 
> 
>  
>  
> Thom Bentley| Senior Software Engineer |
> Medidata, a Dassault Systèmes company
>  
> This email and any attachments are intended solely for the use of the
> individual or entity to whom it is addressed and may be confidential
> and/or privileged.
> If you are not one of the named recipients or have received this
> email in error,
> (i) you should not read, disclose, or copy it,
> (ii) please notify sender of your receipt by reply email and delete
> this email and all attachments,
> (iii) Dassault Systèmes does not accept or assume any liability or
> responsibility for any use of or reliance on this email.
> 
> Please be informed that your personal data are processed according to
> our data privacy policy as described on our website. Should you have
> any questions related to personal data protection, please contact 3DS
> Data Protection Officerhttps://www.3ds.com/privacy-policy/contact/
> 
> 

-- 
Tomáš Mráz, OpenSSL

Missing header file ts_local.h in install location.

[BENTLEY Thom via openssl-users]

Hi All,

I build and installed version 3.0.8 on Windows with Visual Studio using the 
instructions provided.
I copied the bin, include, and lib directories to a location that would be 
found by the CMake for the
DCMTK toolkit version 3.6.8.
When I attempt to build the DCMTK toolkit, I see that the ts.h value can't find 
the definition of TS_verify_ctx.
That's because of the missing ts_local.h as far as I can see.

Is there something I missed in the build of the libraries and the install 
package?
Thank.



Thom Bentley | Senior Software Engineer | Medidata, a Dassault Systèmes 
company


This email and any attachments are intended solely for the use of the 
individual or entity to whom it is addressed and may be confidential and/or 
privileged.

If you are not one of the named recipients or have received this email in error,

(i) you should not read, disclose, or copy it,

(ii) please notify sender of your receipt by reply email and delete this email 
and all attachments,

(iii) Dassault Systèmes does not accept or assume any liability or 
responsibility for any use of or reliance on this email.


Please be informed that your personal data are processed according to our data 
privacy policy as described on our website. Should you have any questions 
related to personal data protection, please contact 3DS Data Protection Officer 
https://www.3ds.com/privacy-policy/contact/

Re: Issue with install after using `perl Configure` to set --prefix and --openssldir

[BENTLEY Thom via openssl-users]

Thanks for that.  I am so used to using options in that form -option 
optionvalue instad of -option=optionvalue

--
Thom Bentley | Senior Software Engineer |Medidata, a Dassault Systèmes company
thom.bent...@3ds.com


From: Tomas Mraz 
Date: Thursday, June 27, 2024 at 1:48 PM
To: BENTLEY Thom , "openssl-users@openssl.org" 

Subject: Re: Issue with install after using `perl Configure` to set --prefix 
and --openssldir

You seem to have space instead of = between --openssldir and the path. And 
yeah, try to experiment with the doublequotes if that does not help. I do not 
know the exact rules for these in the Windows shell. Tomas Mraz, OpenSSL On 
Thu, 2024-06-27


You seem to have space instead of = between --openssldir and the path.



And yeah, try to experiment with the doublequotes if that does not

help. I do not know the exact rules for these in the Windows shell.



Tomas Mraz, OpenSSL



On Thu, 2024-06-27 at 17:46 +, BENTLEY Thom wrote:

>

>

>

> Thanks Tomas.

> I tried that but got the error I specified in my post.  Unless you

> are saying I need quotes around the entire–openssldir option.

>

>

>

>

>

>

>

> --

> Thom Bentley | Senior Software Engineer |Medidata, a Dassault

> Systèmes company

> thom.bent...@3ds.com

>

>

>

>

> From:Tomas Mraz 

> Date: Thursday, June 27, 2024 at 1:29 PM

> To: BENTLEY Thom , "openssl-users@openssl.org"

> 

> Subject: Re: Issue with install after using `perl Configure` to set -

> -prefix and --openssldir

>

>

>

>

>

> Hello, you have to use "--

> openssldir=C: \OpenSSLInstallDir\CommonFiles\SSL" Regards, Tomas

> Mraz, OpenSSL On Thu, 2024-06-27 at 16: 50 +, BENTLEY Thom via

> openssl-users wrote: > > > > Hi All, > > I get an error running `perl

>

> Hello,

>

> you have to use "--openssldir=C:\OpenSSLInstallDir\CommonFiles\SSL"

>

> Regards,

>

> Tomas Mraz, OpenSSL

>

> On Thu, 2024-06-27 at 16:50 +, BENTLEY Thom via openssl-users

> wrote:

> >

> >

> >

> > Hi All,

> >

> > I get an error running `perl Configure --openssldir

> > "C:\OpenSSLInstallDir\CommonFiles\SSL" --

> > prefix=C:\OpenSSLInstallDir

> > VC-WIN64A`

> > target already defined - C:\OpenSSLInstallDir\Common Files\SSL

> > (offending arg: VC-WIN64A)

> >

> > If I remove --openssldir "C:\OpenSSLInstallDir\CommonFiles\SSL",

> > the

> > configure happens fine but the install fails.

> > Here are the steps after the reconfigure.

> > nmake clean

> > nmake

> > nmake test

> > nmake install.

> >

> > The install shows this error:

> > NMAKE : fatal error U1077: '"C:\Strawberry\perl\bin\perl.exe"

> > ".\util\mkdir-p.pl" "C:\Program Files\Common Files\SSL\certs"' :

> > return code '0x2'

> > Stop.

> >

> > What step did I miss or is this a bug?  I thought I could override

> > the common files location with –openssldir but that doesn’t seem to

> > work.

> >

> > Thanks.

> >

> >

> >

> >

> > Thom Bentley| Senior Software Engineer |

> > Medidata, a Dassault Systèmes company

> >

> > This email and any attachments are intended solely for the use of

> > the

> > individual or entity to whom it is addressed and may be

> > confidential

> > and/or privileged.

> > If you are not one of the named recipients or have received this

> > email in error,

> > (i) you should not read, disclose, or copy it,

> > (ii) please notify sender of your receipt by reply email and delete

> > this email and all attachments,

> > (iii) Dassault Systèmes does not accept or assume any liability or

> > responsibility for any use of or reliance on this email.

> >

> > Please be informed that your personal data are processed according

> > to

> > our data privacy policy as described on our website. Should you

> > have

> > any questions related to personal data protection, please contact

> > 3DS

> > Data Protection Officerhttps://www.3ds.com/privacy-policy/contact/

> >

> >

>

> --

> Tomáš Mráz, OpenSSL

>

> This email and any attachments are intended solely for the use of the

> individual or entity to whom it is addressed and may be confidential

> and/or privileged.

> If you are not one of the named recipients or have received this

> email in error,

> (i) you should not read, disclose, or copy it,

> (ii) please notify sender of your receipt by reply email and delete

> this email and all attachments,

> (iii) Dassault Systèmes does not accept or assume any liability or

> responsibility for any use of or reliance on this email.

>

> Please be informed that your personal data are processed according to

> our data privacy policy as described on our website. Should you have

> any questions related to personal data protection, please contact 3DS

> Data Protection Officerhttps://www.3ds.com/privacy-policy/contact/

>

>



--

Tomáš Mráz, OpenSSL



This email and any attachments are intended solely for the use of the 
individual or entity to whom it is addressed and may be confidential and/or 
privileged.

If you are not one of the named recipients or 

Re: Issue with install after using `perl Configure` to set --prefix and --openssldir

[Tomas Mraz]

You seem to have space instead of = between --openssldir and the path.

And yeah, try to experiment with the doublequotes if that does not
help. I do not know the exact rules for these in the Windows shell.

Tomas Mraz, OpenSSL

On Thu, 2024-06-27 at 17:46 +, BENTLEY Thom wrote:
> 
> 
> 
> Thanks Tomas.
> I tried that but got the error I specified in my post.  Unless you
> are saying I need quotes around the entire–openssldir option.
>  
> 
> 
> 
> 
> 
> 
> --
> Thom Bentley | Senior Software Engineer |Medidata, a Dassault
> Systèmes company
> thom.bent...@3ds.com
>  
>  
> 
> 
> From:Tomas Mraz 
> Date: Thursday, June 27, 2024 at 1:29 PM
> To: BENTLEY Thom , "openssl-users@openssl.org"
> 
> Subject: Re: Issue with install after using `perl Configure` to set -
> -prefix and --openssldir
> 
> 
>  
> 
> 
> Hello, you have to use "--
> openssldir=C: \OpenSSLInstallDir\CommonFiles\SSL" Regards, Tomas
> Mraz, OpenSSL On Thu, 2024-06-27 at 16: 50 +, BENTLEY Thom via
> openssl-users wrote: > > > > Hi All, > > I get an error running `perl
> 
> Hello,
>  
> you have to use "--openssldir=C:\OpenSSLInstallDir\CommonFiles\SSL"
>  
> Regards,
>  
> Tomas Mraz, OpenSSL
>  
> On Thu, 2024-06-27 at 16:50 +, BENTLEY Thom via openssl-users
> wrote:
> > 
> > 
> > 
> > Hi All, 
> >  
> > I get an error running `perl Configure --openssldir
> > "C:\OpenSSLInstallDir\CommonFiles\SSL" --
> > prefix=C:\OpenSSLInstallDir
> > VC-WIN64A`
> > target already defined - C:\OpenSSLInstallDir\Common Files\SSL
> > (offending arg: VC-WIN64A)
> >  
> > If I remove --openssldir "C:\OpenSSLInstallDir\CommonFiles\SSL",
> > the
> > configure happens fine but the install fails.
> > Here are the steps after the reconfigure.
> > nmake clean
> > nmake 
> > nmake test
> > nmake install.
> >  
> > The install shows this error:
> > NMAKE : fatal error U1077: '"C:\Strawberry\perl\bin\perl.exe"
> > ".\util\mkdir-p.pl" "C:\Program Files\Common Files\SSL\certs"' :
> > return code '0x2'
> > Stop.
> >  
> > What step did I miss or is this a bug?  I thought I could override
> > the common files location with –openssldir but that doesn’t seem to
> > work.
> > 
> > Thanks.
> > 
> > 
> >  
> >  
> > Thom Bentley| Senior Software Engineer |
> > Medidata, a Dassault Systèmes company
> >  
> > This email and any attachments are intended solely for the use of
> > the
> > individual or entity to whom it is addressed and may be
> > confidential
> > and/or privileged.
> > If you are not one of the named recipients or have received this
> > email in error,
> > (i) you should not read, disclose, or copy it,
> > (ii) please notify sender of your receipt by reply email and delete
> > this email and all attachments,
> > (iii) Dassault Systèmes does not accept or assume any liability or
> > responsibility for any use of or reliance on this email.
> > 
> > Please be informed that your personal data are processed according
> > to
> > our data privacy policy as described on our website. Should you
> > have
> > any questions related to personal data protection, please contact
> > 3DS
> > Data Protection Officerhttps://www.3ds.com/privacy-policy/contact/
> > 
> > 
>  
> -- 
> Tomáš Mráz, OpenSSL
>  
> This email and any attachments are intended solely for the use of the
> individual or entity to whom it is addressed and may be confidential
> and/or privileged.
> If you are not one of the named recipients or have received this
> email in error,
> (i) you should not read, disclose, or copy it,
> (ii) please notify sender of your receipt by reply email and delete
> this email and all attachments,
> (iii) Dassault Systèmes does not accept or assume any liability or
> responsibility for any use of or reliance on this email.
> 
> Please be informed that your personal data are processed according to
> our data privacy policy as described on our website. Should you have
> any questions related to personal data protection, please contact 3DS
> Data Protection Officerhttps://www.3ds.com/privacy-policy/contact/
> 
> 

-- 
Tomáš Mráz, OpenSSL

Re: Issue with install after using `perl Configure` to set --prefix and --openssldir

[BENTLEY Thom via openssl-users]

Thanks Tomas.
I tried that but got the error I specified in my post.  Unless you are saying I 
need quotes around the entire –openssldir option.

--
Thom Bentley | Senior Software Engineer |Medidata, a Dassault Systèmes company
thom.bent...@3ds.com


From: Tomas Mraz 
Date: Thursday, June 27, 2024 at 1:29 PM
To: BENTLEY Thom , "openssl-users@openssl.org" 

Subject: Re: Issue with install after using `perl Configure` to set --prefix 
and --openssldir

Hello, you have to use "--openssldir=C: \OpenSSLInstallDir\CommonFiles\SSL" 
Regards, Tomas Mraz, OpenSSL On Thu, 2024-06-27 at 16: 50 +, BENTLEY Thom 
via openssl-users wrote: > > > > Hi All, > > I get an error running `perl


Hello,



you have to use "--openssldir=C:\OpenSSLInstallDir\CommonFiles\SSL"



Regards,



Tomas Mraz, OpenSSL



On Thu, 2024-06-27 at 16:50 +, BENTLEY Thom via openssl-users

wrote:

>

>

>

> Hi All,

>

> I get an error running `perl Configure --openssldir

> "C:\OpenSSLInstallDir\CommonFiles\SSL" --prefix=C:\OpenSSLInstallDir

> VC-WIN64A`

> target already defined - C:\OpenSSLInstallDir\Common Files\SSL

> (offending arg: VC-WIN64A)

>

> If I remove --openssldir "C:\OpenSSLInstallDir\CommonFiles\SSL", the

> configure happens fine but the install fails.

> Here are the steps after the reconfigure.

> nmake clean

> nmake

> nmake test

> nmake install.

>

> The install shows this error:

> NMAKE : fatal error U1077: '"C:\Strawberry\perl\bin\perl.exe"

> ".\util\mkdir-p.pl" "C:\Program Files\Common Files\SSL\certs"' :

> return code '0x2'

> Stop.

>

> What step did I miss or is this a bug?  I thought I could override

> the common files location with –openssldir but that doesn’t seem to

> work.

>

> Thanks.

>

>

>

>

> Thom Bentley| Senior Software Engineer |

> Medidata, a Dassault Systèmes company

>

> This email and any attachments are intended solely for the use of the

> individual or entity to whom it is addressed and may be confidential

> and/or privileged.

> If you are not one of the named recipients or have received this

> email in error,

> (i) you should not read, disclose, or copy it,

> (ii) please notify sender of your receipt by reply email and delete

> this email and all attachments,

> (iii) Dassault Systèmes does not accept or assume any liability or

> responsibility for any use of or reliance on this email.

>

> Please be informed that your personal data are processed according to

> our data privacy policy as described on our website. Should you have

> any questions related to personal data protection, please contact 3DS

> Data Protection Officerhttps://www.3ds.com/privacy-policy/contact/

>

>



--

Tomáš Mráz, OpenSSL



This email and any attachments are intended solely for the use of the 
individual or entity to whom it is addressed and may be confidential and/or 
privileged.

If you are not one of the named recipients or have received this email in error,

(i) you should not read, disclose, or copy it,

(ii) please notify sender of your receipt by reply email and delete this email 
and all attachments,

(iii) Dassault Systèmes does not accept or assume any liability or 
responsibility for any use of or reliance on this email.


Please be informed that your personal data are processed according to our data 
privacy policy as described on our website. Should you have any questions 
related to personal data protection, please contact 3DS Data Protection Officer 
https://www.3ds.com/privacy-policy/contact/

Re: Issue with install after using `perl Configure` to set --prefix and --openssldir

[Tomas Mraz]

Hello,

you have to use "--openssldir=C:\OpenSSLInstallDir\CommonFiles\SSL"

Regards,

Tomas Mraz, OpenSSL

On Thu, 2024-06-27 at 16:50 +, BENTLEY Thom via openssl-users
wrote:
> 
> 
> 
> Hi All, 
>  
> I get an error running `perl Configure --openssldir
> "C:\OpenSSLInstallDir\CommonFiles\SSL" --prefix=C:\OpenSSLInstallDir
> VC-WIN64A`
> target already defined - C:\OpenSSLInstallDir\Common Files\SSL
> (offending arg: VC-WIN64A)
>  
> If I remove --openssldir "C:\OpenSSLInstallDir\CommonFiles\SSL", the
> configure happens fine but the install fails.
> Here are the steps after the reconfigure.
> nmake clean
> nmake 
> nmake test
> nmake install.
>  
> The install shows this error:
> NMAKE : fatal error U1077: '"C:\Strawberry\perl\bin\perl.exe"
> ".\util\mkdir-p.pl" "C:\Program Files\Common Files\SSL\certs"' :
> return code '0x2'
> Stop.
>  
> What step did I miss or is this a bug?  I thought I could override
> the common files location with –openssldir but that doesn’t seem to
> work.
> 
> Thanks.
> 
> 
>  
>  
> Thom Bentley| Senior Software Engineer |
> Medidata, a Dassault Systèmes company
>  
> This email and any attachments are intended solely for the use of the
> individual or entity to whom it is addressed and may be confidential
> and/or privileged.
> If you are not one of the named recipients or have received this
> email in error,
> (i) you should not read, disclose, or copy it,
> (ii) please notify sender of your receipt by reply email and delete
> this email and all attachments,
> (iii) Dassault Systèmes does not accept or assume any liability or
> responsibility for any use of or reliance on this email.
> 
> Please be informed that your personal data are processed according to
> our data privacy policy as described on our website. Should you have
> any questions related to personal data protection, please contact 3DS
> Data Protection Officerhttps://www.3ds.com/privacy-policy/contact/
> 
> 

-- 
Tomáš Mráz, OpenSSL

Issue with install after using `perl Configure` to set --prefix and --openssldir

[BENTLEY Thom via openssl-users]

Hi All,

I get an error running `perl Configure --openssldir 
"C:\OpenSSLInstallDir\CommonFiles\SSL" --prefix=C:\OpenSSLInstallDir VC-WIN64A`
target already defined - C:\OpenSSLInstallDir\Common Files\SSL (offending arg: 
VC-WIN64A)

If I remove --openssldir "C:\OpenSSLInstallDir\CommonFiles\SSL", the configure 
happens fine but the install fails.
Here are the steps after the reconfigure.
nmake clean
nmake
nmake test
nmake install.

The install shows this error:
NMAKE : fatal error U1077: '"C:\Strawberry\perl\bin\perl.exe" 
".\util\mkdir-p.pl" "C:\Program Files\Common Files\SSL\certs"' : return code 
'0x2'
Stop.

What step did I miss or is this a bug?  I thought I could override the common 
files location with -openssldir but that doesn't seem to work.

Thanks.


Thom Bentley | Senior Software Engineer | Medidata, a Dassault Systèmes 
company


This email and any attachments are intended solely for the use of the 
individual or entity to whom it is addressed and may be confidential and/or 
privileged.

If you are not one of the named recipients or have received this email in error,

(i) you should not read, disclose, or copy it,

(ii) please notify sender of your receipt by reply email and delete this email 
and all attachments,

(iii) Dassault Systèmes does not accept or assume any liability or 
responsibility for any use of or reliance on this email.


Please be informed that your personal data are processed according to our data 
privacy policy as described on our website. Should you have any questions 
related to personal data protection, please contact 3DS Data Protection Officer 
https://www.3ds.com/privacy-policy/contact/

Re: Syntax of OID values

[Neil Horman]

I believe the oid_file key in the config is used by the ca and req applets
and is meant to be a value rather than a section (i.e. oid_file =
/path/to/oid/file/name)

To do what I believe you are trying to do above, you need to follow the
directions here:
https://www.openssl.org/docs/man1.1.1/man5/config.html

by assigning an oid_section like this:
oid_section = my_oid_section_name

And then creating the section:
[my_oid_section_name]
 some_new_oid = 1.2.3.4

On Thu, Jun 27, 2024 at 1:48 AM Dvorcovoy Dmitry V. via openssl-users <
openssl-users@openssl.org> wrote:

> I want to make my own tiny rootca.
> There are problem with supporting OIDS. I found in documentation about
> oid_file, but can not decode syntax of values.
> DER: works fine, but I want to use more readeable format.
>
> All I can find is the same docs without a tiny working example how to use
> my defined oids.
> sample:
> [oid_file]
>  1.3.6.1.4.1.311.21.1 msCAversion XCN_OID_CERTSRV_CA_VERSION
>  1.3.6.1.4.1.311.21.4 msCRLNextPublish XCN_OID_CRL_NEXT_PUBLISH
>
> [ca.conf]
>  oid_file =oid.txt
>  ...
> [ crl_ext ]
> authorityKeyIdentifier=keyid:always
> msCAversion = DER:020101
> msCRLNextPublish = DER:170D3234303930393131333635395A
>
> with these options all works ok.
> >openssl ca -config ca.conf -gencrl -crlexts crl_ext -out crl.pem
>
> but when I try anything like this:
>  msCAversion = 1
>  msCAversion = INT:01
>  msCAversion = INTEGER:0x01
> (and many other combinations)
>
> I'll got the same error:
> Using configuration from ca.conf
> Error checking CRL extension section crl_ext
> 00CEC9A0FA7F:error:1181:X509 V3 routines:do_ext_nconf:unknown
> extension:crypto/x509/v3_conf.c:92:
> 00CEC9A0FA7F:error:1180:X509 V3
> routines:X509V3_EXT_nconf_int:error in
> extension:crypto/x509/v3_conf.c:48:section=crl_ext, name=msCAversion,
> value=INTEGER:0x01
>
> Same with datetime, there are no help about it's format:
> msCRLNextPublish =UTC
> =: UTCTIME:"2024-Sep-09 11:36:59"
>  =ANS1.UTCTIME
>
> How to properly fromat values and please, include it with examples to
> documentation?
>
> And what to do to make -text outpul with readeable format, not just dump
> of OIDs? I think, there have to be some global OID config file, but where
> is it?
>

OpenSSL Security Advisory

[Matt Caswell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

OpenSSL Security Advisory [27th June 2024]
==

SSL_select_next_proto buffer overread (CVE-2024-5535)
=

Severity: Low

Issue summary: Calling the OpenSSL API function SSL_select_next_proto with an
empty supported client protocols buffer may cause a crash or memory contents to
be sent to the peer.

Impact summary: A buffer overread can have a range of potential consequences
such as unexpected application beahviour or a crash. In particular this issue
could result in up to 255 bytes of arbitrary private data from memory being sent
to the peer leading to a loss of confidentiality. However, only applications
that directly call the SSL_select_next_proto function with a 0 length list of
supported client protocols are affected by this issue. This would normally never
be a valid scenario and is typically not under attacker control but may occur by
accident in the case of a configuration or programming error in the calling
application.

The OpenSSL API function SSL_select_next_proto is typically used by TLS
applications that support ALPN (Application Layer Protocol Negotiation) or NPN
(Next Protocol Negotiation). NPN is older, was never standardised and
is deprecated in favour of ALPN. We believe that ALPN is significantly more
widely deployed than NPN. The SSL_select_next_proto function accepts a list of
protocols from the server and a list of protocols from the client and returns
the first protocol that appears in the server list that also appears in the
client list. In the case of no overlap between the two lists it returns the
first item in the client list. In either case it will signal whether an overlap
between the two lists was found. In the case where SSL_select_next_proto is
called with a zero length client list it fails to notice this condition and
returns the memory immediately following the client list pointer (and reports
that there was no overlap in the lists).

This function is typically called from a server side application callback for
ALPN or a client side application callback for NPN. In the case of ALPN the list
of protocols supplied by the client is guaranteed by libssl to never be zero in
length. The list of server protocols comes from the application and should never
normally be expected to be of zero length. In this case if the
SSL_select_next_proto function has been called as expected (with the list
supplied by the client passed in the client/client_len parameters), then the
application will not be vulnerable to this issue. If the application has
accidentally been configured with a zero length server list, and has
accidentally passed that zero length server list in the client/client_len
parameters, and has additionally failed to correctly handle a "no overlap"
response (which would normally result in a handshake failure in ALPN) then it
will be vulnerable to this problem.

In the case of NPN, the protocol permits the client to opportunistically select
a protocol when there is no overlap. OpenSSL returns the first client protocol
in the no overlap case in support of this. The list of client protocols comes
from the application and should never normally be expected to be of zero length.
However if the SSL_select_next_proto function is accidentally called with a
client_len of 0 then an invalid memory pointer will be returned instead. If the
application uses this output as the opportunistic protocol then the loss of
confidentiality will occur.

This issue has been assessed as Low severity because applications are most
likely to be vulnerable if they are using NPN instead of ALPN - but NPN is not
widely used. It also requires an application configuration or programming error.
Finally, this issue would not typically be under attacker control making active
exploitation unlikely.

The FIPS modules in 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.

OpenSSL 3.3, 3.2, 3.1, 3.0, 1.1.1 and 1.0.2 are vulnerable to this issue.

OpenSSL 3.3 users should upgrade to OpenSSL 3.3.2 once it is released.

OpenSSL 3.2 users should upgrade to OpenSSL 3.2.3 once it is released.

OpenSSL 3.1 users should upgrade to OpenSSL 3.1.7 once it is released.

OpenSSL 3.0 users should upgrade to OpenSSL 3.0.15 once it is released.

OpenSSL 1.1.1 users should upgrade to OpenSSL 1.1.1za once it is released
(premium support customers only).

OpenSSL 1.0.2 users should upgrade to OpenSSL 1.0.2zk once it is released
(premium support customers only).

Due to the low severity of this issue we are not issuing new releases of
OpenSSL at this time. The fix will be included in the next releases when they
become available. The fix is also available in commit e86ac436f0 (for 3.3),
commit 99fb785a5f (for 3.2), commit 4ada436a19 (for 3.1) and commit cf6f91f612
(for 3.0) in the OpenSSL git repository. It is available to premium support
customers in commit b78ec0824d (for 1.1.1) and commit 

Syntax of OID values

[Dvorcovoy Dmitry V. via openssl-users]

I want to make my own tiny rootca.
There are problem with supporting OIDS. I found in documentation about 
oid_file, but can not decode syntax of values.
DER: works fine, but I want to use more readeable format.

All I can find is the same docs without a tiny working example how to use my 
defined oids.
sample:
[oid_file]
 1.3.6.1.4.1.311.21.1 msCAversion XCN_OID_CERTSRV_CA_VERSION
 1.3.6.1.4.1.311.21.4 msCRLNextPublish XCN_OID_CRL_NEXT_PUBLISH

[ca.conf]
 oid_file =oid.txt
 ...
[ crl_ext ]
authorityKeyIdentifier=keyid:always
msCAversion = DER:020101
msCRLNextPublish = DER:170D3234303930393131333635395A

with these options all works ok.
>openssl ca -config ca.conf -gencrl -crlexts crl_ext -out crl.pem

but when I try anything like this:
 msCAversion = 1
 msCAversion = INT:01
 msCAversion = INTEGER:0x01
(and many other combinations)

I'll got the same error:
Using configuration from ca.conf
Error checking CRL extension section crl_ext
00CEC9A0FA7F:error:1181:X509 V3 routines:do_ext_nconf:unknown 
extension:crypto/x509/v3_conf.c:92:
00CEC9A0FA7F:error:1180:X509 V3 routines:X509V3_EXT_nconf_int:error in
extension:crypto/x509/v3_conf.c:48:section=crl_ext, name=msCAversion, 
value=INTEGER:0x01

Same with datetime, there are no help about it's format:
msCRLNextPublish =UTC
=: UTCTIME:"2024-Sep-09 11:36:59"
 =ANS1.UTCTIME

How to properly fromat values and please, include it with examples to 
documentation?

And what to do to make -text outpul with readeable format, not just dump of 
OIDs? I think, there have to be some global OID config file, but where is it?

RE: Issue building after configuring for VC-WIN64A (version 3.0.8)

[BENTLEY Thom via openssl-users]

Thanks Neil.  Realized that shortly after posting.
I did a `nmake clean`.
I haven’t cloned the repo so I couldn’t use git clean
I’m running `nmake test` now.

I’m back to C++/C coding on Windows after not doing any for about 15-20 years.
Last was a little to build code to be wrapped for use in python on Linux.
Using docker build images to do the work is a bit cleaner than using Visual 
Studio at the command line.

Thanks again.



Thom Bentley | Senior Software Engineer | Medidata, a Dassault Systèmes 
company

From: Neil Horman 
Sent: Wednesday, June 26, 2024 3:29 PM
To: BENTLEY Thom 
Cc: openssl-users@openssl.org
Subject: Re: Issue building after configuring for VC-WIN64A (version 3.0.8)

You will almost certainly need to preform an nmake distclean (or just run git 
clean on your tree) prior to reconfiguring. nmake is really bad about getting 
lost in dependency resolution. Its quite likely that there is a remaining 
object file

You will almost certainly need to preform an nmake distclean (or just run git 
clean on your tree) prior to reconfiguring.  nmake is really bad about getting 
lost in dependency resolution.  Its quite likely that there is a remaining 
object file somewhere that didn't get rebuilt for x64 when you ran your second 
configure.

Start with a clean tree, run vcvarsall.bat x64 to set up your tool chain, then 
Configure for VC-WIN64A and nmake, it should work fine.

On Wed, Jun 26, 2024 at 3:20 PM BENTLEY Thom via openssl-users 
mailto:openssl-users@openssl.org>> wrote:
Hi All,

I followed the instructions for building OpenSSL 3.0.8 at 
https://github.com/openssl/openssl/blob/openssl-3.0.8/NOTES-WINDOWS.md#native-builds-using-visual-c
The nmake step failed with the following error:
   cmd /C ""cl" /Zs /showIncludes  /Zi /Fdossl_static.pdb /Gs0 /GF /Gy /MD 
/W3 /wd4090 /nologo /O2 -I"crypto" -I"include" 
-I"providers\implementations\include" -I"providers\common\include" -D"L_ENDIAN" 
-D"OPENSSL_PIC" -D"OPENSSLDIR=\"C:\\Program Files\\Common Files\\SSL\"" 
-D"ENGINESDIR=\"C:\\Program Files\\OpenSSL\\lib\\engines-3\"" 
-D"MODULESDIR=\"C:\\Program Files\\OpenSSL\\lib\\ossl-modules\"" 
-D"OPENSSL_BUILDING_OPENSSL" -D"OPENSSL_SYS_WIN32" -D"WIN32_LEAN_AND_MEAN" 
-D"UNICODE" -D"_UNICODE" -D"_CRT_SECURE_NO_DEPRECATE" 
-D"_WINSOCK_DEPRECATED_NO_WARNINGS" -D"NDEBUG"   -DOPENSSL_BN_ASM_GF2m 
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_CPUID_OBJ 
-DOPENSSL_IA32_SSE2 "ssl\record\tls_pad.c" > ssl\record\libcommon-lib-tls_pad.d 
2>&1"
"lib" /nologo /out:providers\libcommon.lib 
@C:\Users\tbentley\AppData\Local\Temp\1\nmFF6D.tmp
IF EXIST .manifest DEL /F /Q .manifest
IF EXIST libcrypto-3-x64.dll DEL /F /Q libcrypto-3-x64.dll
cmd /C ""link" /nologo /debug /dll  /nologo /debug 
@C:\Users\tbentley\AppData\Local\Temp\1\nm96.tmp /implib:libcrypto.lib || (DEL 
/Q libcrypto-3-x64.* libcrypto.lib & EXIT 1)"
crypto\aes\libcrypto-shlib-aes_cfb.obj : fatal error LNK1112: module machine 
type 'x86' conflicts with target machine type 'x64'
Could Not Find C:\OpenSSL\openssl-3.0.8\openssl-3.0.8\libcrypto-3-x64.*
NMAKE : fatal error U1077: 'cmd /C ""link" /nologo /debug /dll  /nologo /debug 
@C:\Users\tbentley\AppData\Local\Temp\1\nm96.tmp /implib:libcrypto.lib || (DEL 
/Q libcrypto-3-x64.* libcrypto.lib & EXIT 1)"' : return code '0x1'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual 
Studio\2022\Professional\VC\Tools\MSVC\14.38.33130\bin\HostX86\x86\nmake.exe" / 
  _build_sw' : return code '0x2'
Stop.

I then realized that the wrong version of cl.exe was in the path so I ran:
"C:\Program Files\Microsoft Visual 
Studio\2022\Professional\VC\Auxiliary\Build\vcvarsall.bat" x64

I re-ran
perl Configure VC-WIN64A

and re-ran nmake.

I still have a mismatch error during linking

cmd /C ""cl" /Zs /showIncludes  /Zi /Fdossl_static.pdb /Gs0 /GF /Gy /MD 
/W3 /wd4090 /nologo /O2 -I"." -I"include" -I"apps\include" -D"L_ENDIAN" 
-D"OPENSSL_PIC" -D"OPENSSLDIR=\"C:\\Program Files\\Common Files\\SSL\"" 
-D"ENGINESDIR=\"C:\\Program Files\\OpenSSL\\lib\\engines-3\"" 
-D"MODULESDIR=\"C:\\Program Files\\OpenSSL\\lib\\ossl-modules\"" 
-D"OPENSSL_BUILDING_OPENSSL" -D"OPENSSL_SYS_WIN32" -D"WIN32_LEAN_AND_MEAN" 
-D"UNICODE" -D"_UNICODE" -D"_CRT_SECURE_NO_DEPRECATE" 
-D"_WINSOCK_DEPRECATED_NO_WARNINGS" -D"NDEBUG"   "apps\lib\tlssrp_depr.c" > 
apps\lib\libapps-lib-tlssrp_depr.d 2>&1"
"lib" /nologo /out:apps\libapps.lib 
@C:\Users\tbentley\AppData\Local\Temp\1\nm9792.tmp
apps\lib\libapps-lib-fmt.obj : fatal error LNK1112: module machine type 'x86' 
conflicts with target machine type 'x64'
NMAKE : fatal error U1077: '"lib" /nologo /out:apps\libapps.lib 

Re: Issue building after configuring for VC-WIN64A (version 3.0.8)

[Neil Horman]

You will almost certainly need to preform an nmake distclean (or just run
git clean on your tree) prior to reconfiguring.  nmake is really bad about
getting lost in dependency resolution.  Its quite likely that there is a
remaining object file somewhere that didn't get rebuilt for x64 when you
ran your second configure.

Start with a clean tree, run vcvarsall.bat x64 to set up your tool chain,
then Configure for VC-WIN64A and nmake, it should work fine.

On Wed, Jun 26, 2024 at 3:20 PM BENTLEY Thom via openssl-users <
openssl-users@openssl.org> wrote:

> Hi All,
>
>
>
> I followed the instructions for building OpenSSL 3.0.8 at
> https://github.com/openssl/openssl/blob/openssl-3.0.8/NOTES-WINDOWS.md#native-builds-using-visual-c
>
> The nmake step failed with the following error:
>cmd /C ""cl" /Zs /showIncludes  /Zi /Fdossl_static.pdb /Gs0 /GF /Gy
> /MD /W3 /wd4090 /nologo /O2 -I"crypto" -I"include"
> -I"providers\implementations\include" -I"providers\common\include"
> -D"L_ENDIAN" -D"OPENSSL_PIC" -D"OPENSSLDIR=\"C:\\Program Files\\Common
> Files\\SSL\"" -D"ENGINESDIR=\"C:\\Program Files\\OpenSSL\\lib\\engines-3\""
> -D"MODULESDIR=\"C:\\Program Files\\OpenSSL\\lib\\ossl-modules\""
> -D"OPENSSL_BUILDING_OPENSSL" -D"OPENSSL_SYS_WIN32" -D"WIN32_LEAN_AND_MEAN"
> -D"UNICODE" -D"_UNICODE" -D"_CRT_SECURE_NO_DEPRECATE"
> -D"_WINSOCK_DEPRECATED_NO_WARNINGS" -D"NDEBUG"   -DOPENSSL_BN_ASM_GF2m
> -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_CPUID_OBJ
> -DOPENSSL_IA32_SSE2 "ssl\record\tls_pad.c" >
> ssl\record\libcommon-lib-tls_pad.d 2>&1"
>
> "lib" /nologo /out:providers\libcommon.lib
> @C:\Users\tbentley\AppData\Local\Temp\1\nmFF6D.tmp
>
> IF EXIST .manifest DEL /F /Q .manifest
>
> IF EXIST libcrypto-3-x64.dll DEL /F /Q libcrypto-3-x64.dll
>
> cmd /C ""link" /nologo /debug /dll  /nologo /debug
> @C:\Users\tbentley\AppData\Local\Temp\1\nm96.tmp /implib:libcrypto.lib ||
> (DEL /Q libcrypto-3-x64.* libcrypto.lib & EXIT 1)"
>
> crypto\aes\libcrypto-shlib-aes_cfb.obj : fatal error LNK1112: module
> machine type 'x86' conflicts with target machine type 'x64'
>
> Could Not Find C:\OpenSSL\openssl-3.0.8\openssl-3.0.8\libcrypto-3-x64.*
>
> NMAKE : fatal error U1077: 'cmd /C ""link" /nologo /debug /dll  /nologo
> /debug @C:\Users\tbentley\AppData\Local\Temp\1\nm96.tmp
> /implib:libcrypto.lib || (DEL /Q libcrypto-3-x64.* libcrypto.lib & EXIT
> 1)"' : return code '0x1'
>
> Stop.
>
> NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual
> Studio\2022\Professional\VC\Tools\MSVC\14.38.33130\bin\HostX86\x86\nmake.exe"
> /   _build_sw' : return code '0x2'
>
> Stop.
>
>
>
> I then realized that the wrong version of cl.exe was in the path so I ran:
> "C:\Program Files\Microsoft Visual
> Studio\2022\Professional\VC\Auxiliary\Build\vcvarsall.bat" x64
>
>
>
> I re-ran
>
> perl Configure VC-WIN64A
>
>
>
> and re-ran nmake.
>
> I still have a mismatch error during linking
>
> cmd /C ""cl" /Zs /showIncludes  /Zi /Fdossl_static.pdb /Gs0 /GF
> /Gy /MD /W3 /wd4090 /nologo /O2 -I"." -I"include" -I"apps\include"
> -D"L_ENDIAN" -D"OPENSSL_PIC" -D"OPENSSLDIR=\"C:\\Program Files\\Common
> Files\\SSL\"" -D"ENGINESDIR=\"C:\\Program Files\\OpenSSL\\lib\\engines-3\""
> -D"MODULESDIR=\"C:\\Program Files\\OpenSSL\\lib\\ossl-modules\""
> -D"OPENSSL_BUILDING_OPENSSL" -D"OPENSSL_SYS_WIN32" -D"WIN32_LEAN_AND_MEAN"
> -D"UNICODE" -D"_UNICODE" -D"_CRT_SECURE_NO_DEPRECATE"
> -D"_WINSOCK_DEPRECATED_NO_WARNINGS" -D"NDEBUG"   "apps\lib\tlssrp_depr.c" >
> apps\lib\libapps-lib-tlssrp_depr.d 2>&1"
>
> "lib" /nologo /out:apps\libapps.lib
> @C:\Users\tbentley\AppData\Local\Temp\1\nm9792.tmp
>
> apps\lib\libapps-lib-fmt.obj : fatal error LNK1112: module machine type
> 'x86' conflicts with target machine type 'x64'
>
> NMAKE : fatal error U1077: '"lib" /nologo /out:apps\libapps.lib
> @C:\Users\tbentley\AppData\Local\Temp\1\nm9792.tmp' : return code '0x458'
>
> Stop.
>
> NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual
> Studio\2022\Professional\VC\Tools\MSVC\14.38.33130\bin\HostX64\x64\nmake.exe"
> /   _build_sw' : return code '0x2'
>
> Stop.
>
>
>
> If I run cl.exe I see:
> Microsoft (R) C/C++ Optimizing Compiler Version 19.38.33133 for x64
>
> Copyright (C) Microsoft Corporation.  All rights reserved.
>
>
>
> Thanks.
>
>
>
>
>
>
>
>
>
> *Thom Bentley *| Senior Software Engineer | Medidata, a Dassault Systèmes
> company 
>
>
>
> This email and any attachments are intended solely for the use of the
> individual or entity to whom it is addressed and may be confidential and/or
> privileged.
>
> If you are not one of the named recipients or have received this email in
> error,
>
> (i) you should not read, disclose, or copy it,
>
> (ii) please notify sender of your receipt by reply email and delete this
> email and all attachments,
>
> (iii) Dassault Systèmes does not accept or assume any liability or
> responsibility for any use of or 

RE: Issue building after configuring for VC-WIN64A (version 3.0.8)

[Michael Wojcik via openssl-users]

Did you do an "nmake clean" after switching to the correct compiler? You need 
to get rid of those 32-bit objects, or you'll continue to have a machine-type 
mismatch.

--
Michael Wojcik
Rocket Software

Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

Issue building after configuring for VC-WIN64A (version 3.0.8)

[BENTLEY Thom via openssl-users]

Hi All,

I followed the instructions for building OpenSSL 3.0.8 at 
https://github.com/openssl/openssl/blob/openssl-3.0.8/NOTES-WINDOWS.md#native-builds-using-visual-c
The nmake step failed with the following error:
   cmd /C ""cl" /Zs /showIncludes  /Zi /Fdossl_static.pdb /Gs0 /GF /Gy /MD 
/W3 /wd4090 /nologo /O2 -I"crypto" -I"include" 
-I"providers\implementations\include" -I"providers\common\include" -D"L_ENDIAN" 
-D"OPENSSL_PIC" -D"OPENSSLDIR=\"C:\\Program Files\\Common Files\\SSL\"" 
-D"ENGINESDIR=\"C:\\Program Files\\OpenSSL\\lib\\engines-3\"" 
-D"MODULESDIR=\"C:\\Program Files\\OpenSSL\\lib\\ossl-modules\"" 
-D"OPENSSL_BUILDING_OPENSSL" -D"OPENSSL_SYS_WIN32" -D"WIN32_LEAN_AND_MEAN" 
-D"UNICODE" -D"_UNICODE" -D"_CRT_SECURE_NO_DEPRECATE" 
-D"_WINSOCK_DEPRECATED_NO_WARNINGS" -D"NDEBUG"   -DOPENSSL_BN_ASM_GF2m 
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_CPUID_OBJ 
-DOPENSSL_IA32_SSE2 "ssl\record\tls_pad.c" > ssl\record\libcommon-lib-tls_pad.d 
2>&1"
"lib" /nologo /out:providers\libcommon.lib 
@C:\Users\tbentley\AppData\Local\Temp\1\nmFF6D.tmp
IF EXIST .manifest DEL /F /Q .manifest
IF EXIST libcrypto-3-x64.dll DEL /F /Q libcrypto-3-x64.dll
cmd /C ""link" /nologo /debug /dll  /nologo /debug 
@C:\Users\tbentley\AppData\Local\Temp\1\nm96.tmp /implib:libcrypto.lib || (DEL 
/Q libcrypto-3-x64.* libcrypto.lib & EXIT 1)"
crypto\aes\libcrypto-shlib-aes_cfb.obj : fatal error LNK1112: module machine 
type 'x86' conflicts with target machine type 'x64'
Could Not Find C:\OpenSSL\openssl-3.0.8\openssl-3.0.8\libcrypto-3-x64.*
NMAKE : fatal error U1077: 'cmd /C ""link" /nologo /debug /dll  /nologo /debug 
@C:\Users\tbentley\AppData\Local\Temp\1\nm96.tmp /implib:libcrypto.lib || (DEL 
/Q libcrypto-3-x64.* libcrypto.lib & EXIT 1)"' : return code '0x1'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual 
Studio\2022\Professional\VC\Tools\MSVC\14.38.33130\bin\HostX86\x86\nmake.exe" / 
  _build_sw' : return code '0x2'
Stop.

I then realized that the wrong version of cl.exe was in the path so I ran:
"C:\Program Files\Microsoft Visual 
Studio\2022\Professional\VC\Auxiliary\Build\vcvarsall.bat" x64

I re-ran
perl Configure VC-WIN64A

and re-ran nmake.

I still have a mismatch error during linking

cmd /C ""cl" /Zs /showIncludes  /Zi /Fdossl_static.pdb /Gs0 /GF /Gy /MD 
/W3 /wd4090 /nologo /O2 -I"." -I"include" -I"apps\include" -D"L_ENDIAN" 
-D"OPENSSL_PIC" -D"OPENSSLDIR=\"C:\\Program Files\\Common Files\\SSL\"" 
-D"ENGINESDIR=\"C:\\Program Files\\OpenSSL\\lib\\engines-3\"" 
-D"MODULESDIR=\"C:\\Program Files\\OpenSSL\\lib\\ossl-modules\"" 
-D"OPENSSL_BUILDING_OPENSSL" -D"OPENSSL_SYS_WIN32" -D"WIN32_LEAN_AND_MEAN" 
-D"UNICODE" -D"_UNICODE" -D"_CRT_SECURE_NO_DEPRECATE" 
-D"_WINSOCK_DEPRECATED_NO_WARNINGS" -D"NDEBUG"   "apps\lib\tlssrp_depr.c" > 
apps\lib\libapps-lib-tlssrp_depr.d 2>&1"
"lib" /nologo /out:apps\libapps.lib 
@C:\Users\tbentley\AppData\Local\Temp\1\nm9792.tmp
apps\lib\libapps-lib-fmt.obj : fatal error LNK1112: module machine type 'x86' 
conflicts with target machine type 'x64'
NMAKE : fatal error U1077: '"lib" /nologo /out:apps\libapps.lib 
@C:\Users\tbentley\AppData\Local\Temp\1\nm9792.tmp' : return code '0x458'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual 
Studio\2022\Professional\VC\Tools\MSVC\14.38.33130\bin\HostX64\x64\nmake.exe" / 
  _build_sw' : return code '0x2'
Stop.

If I run cl.exe I see:
Microsoft (R) C/C++ Optimizing Compiler Version 19.38.33133 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

Thanks.




Thom Bentley | Senior Software Engineer | Medidata, a Dassault Systèmes 
company


This email and any attachments are intended solely for the use of the 
individual or entity to whom it is addressed and may be confidential and/or 
privileged.

If you are not one of the named recipients or have received this email in error,

(i) you should not read, disclose, or copy it,

(ii) please notify sender of your receipt by reply email and delete this email 
and all attachments,

(iii) Dassault Systèmes does not accept or assume any liability or 
responsibility for any use of or reliance on this email.


Please be informed that your personal data are processed according to our data 
privacy policy as described on our website. Should you have any questions 
related to personal data protection, please contact 3DS Data Protection Officer 
https://www.3ds.com/privacy-policy/contact/

Re: secp256r1 65 byte key size in packet capture

[Lokesh Chakka]

Is there a way to have all those man pages installed in my system.
I'm using Ubuntu 24.

On Wed, Jun 19, 2024, 17:49 Matt Caswell  wrote:

>
>
> On 19/06/2024 12:14, Lokesh Chakka wrote:
> > Now I need to explore C APIs for getting those keys as hex array.
> > Could you please suggest any good references for beginners.
>
> You would need to first load the key from the file to create an EVP_PKEY
> object. For example you could use the PEM_read_PUBKEY() function for
> this. See:
>
> https://www.openssl.org/docs/man3.3/man3/PEM_read_PUBKEY.html
>
> Once you have the key as an EVP_PKEY object, you can get the raw
> encoding as a char array in a format suitable for TLS using the
> EVP_PKEY_get1_encoded_public_key() function. See:
>
>
> https://www.openssl.org/docs/man3.3/man3/EVP_PKEY_get1_encoded_public_key.html
>
> Matt
>
>
>
> >
> > Regards
> > --
> > Lokesh Chakka.
> >
> >
> > On Wed, Jun 19, 2024 at 4:21 PM Matt Caswell  > > wrote:
> >
> >
> >
> > On 19/06/2024 09:15, Lokesh Chakka wrote:
> >  > hello,
> >  >
> >  > I'm trying to generate public/private keys with following
> commands:
> >  >
> >  > openssl ecparam -name secp256r1 -genkey -out pvtkey.pem
> >  > openssl ec -in pvtkey.pem -pubout
> >  >
> >  > I'm seeing the sizeof private key as 164 bytes and public key as
> > 124 bytes.
> >  >
> >  > In a wireshark capture( attached ), I'm seeing key length as 65
> > bytes.
> >
> > What you are doing is confusing. You have generated public/private
> key
> > pair for secp256r1 - but the wireshark capture you show seems to be
> the
> > key share from a TLSv1.3 handshake. TLSv1.3 key shares are ephemeral
> so
> > - you'll get a different key share every time. You don't need to
> create
> > a public/private key for this. OpenSSL does it for you.
> >
> > Anyway. Taking the key that you generated:
> >
> > -BEGIN PUBLIC KEY-
> > MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEVSmp4UnlQbzbe6eopByeEUzkmYHP
> > GgaKvSt/xdAgvDp7FXKTpST8UM9LpF8f4JETOXgDDGvNlIDqVFo+T0hdtQ==
> > -END PUBLIC KEY-
> >
> > This is just a PEM encoding of the real key (base 64 encoding of DER
> > structured data in PEM headers). Not sure where you get 124 bytes
> from,
> > but you can look take a look at the actual key data like this:
> >
> > $ openssl pkey -in /tmp/key.pem -pubin -noout -text
> > Public-Key: (256 bit)
> > pub:
> >   04:55:29:a9:e1:49:e5:41:bc:db:7b:a7:a8:a4:1c:
> >   9e:11:4c:e4:99:81:cf:1a:06:8a:bd:2b:7f:c5:d0:
> >   20:bc:3a:7b:15:72:93:a5:24:fc:50:cf:4b:a4:5f:
> >   1f:e0:91:13:39:78:03:0c:6b:cd:94:80:ea:54:5a:
> >   3e:4f:48:5d:b5
> > ASN1 OID: prime256v1
> > NIST CURVE: P-256
> >
> > This shows you the 65 bytes of raw public key data contained within
> the
> > key file.
> >
> > This key is in "uncompressed" format (the 04 byte at the start
> > indicates
> > this). Since it is uncompressed we then get an x and a y value to
> > indicate the point on the curve. Each of these are 32 bytes long (256
> > bits) - so this gives you 65 bytes in total.
> >
> > Matt
> >
> >
> >
> >  >
> >  > Can someone help me understand why the difference?
> >  >
> >  > Thanks & Regards
> >  > --
> >  > Lokesh Chakka.
> >
>

Re: 20240619 snapshots

[Richard Levitte]

The Doctor via openssl-users  writes:

> On Wed, Jun 19, 2024 at 09:53:19AM +0200, Tomas Mraz wrote:
>> They are there. Maybe you've looked too soon before the CDN caches were
>> synchronized.
>> 
>> 
>> On Tue, 2024-06-18 at 21:12 -0600, The Doctor via openssl-users wrote:
>> > Where are they?
>> 
>> -- 
>> Tom Mr??z, OpenSSL
>> 
>
> I use lynx

That's absolutely fine and makes no difference.  The snapshots got in
place, but probably became visible after you looked.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: secp256r1 65 byte key size in packet capture

[Matt Caswell]

On 19/06/2024 12:14, Lokesh Chakka wrote:

Now I need to explore C APIs for getting those keys as hex array.
Could you please suggest any good references for beginners.


You would need to first load the key from the file to create an EVP_PKEY 
object. For example you could use the PEM_read_PUBKEY() function for 
this. See:


https://www.openssl.org/docs/man3.3/man3/PEM_read_PUBKEY.html

Once you have the key as an EVP_PKEY object, you can get the raw 
encoding as a char array in a format suitable for TLS using the 
EVP_PKEY_get1_encoded_public_key() function. See:


https://www.openssl.org/docs/man3.3/man3/EVP_PKEY_get1_encoded_public_key.html

Matt





Regards
--
Lokesh Chakka.


On Wed, Jun 19, 2024 at 4:21 PM Matt Caswell > wrote:




On 19/06/2024 09:15, Lokesh Chakka wrote:
 > hello,
 >
 > I'm trying to generate public/private keys with following commands:
 >
 > openssl ecparam -name secp256r1 -genkey -out pvtkey.pem
 > openssl ec -in pvtkey.pem -pubout
 >
 > I'm seeing the sizeof private key as 164 bytes and public key as
124 bytes.
 >
 > In a wireshark capture( attached ), I'm seeing key length as 65
bytes.

What you are doing is confusing. You have generated public/private key
pair for secp256r1 - but the wireshark capture you show seems to be the
key share from a TLSv1.3 handshake. TLSv1.3 key shares are ephemeral so
- you'll get a different key share every time. You don't need to create
a public/private key for this. OpenSSL does it for you.

Anyway. Taking the key that you generated:

-BEGIN PUBLIC KEY-
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEVSmp4UnlQbzbe6eopByeEUzkmYHP
GgaKvSt/xdAgvDp7FXKTpST8UM9LpF8f4JETOXgDDGvNlIDqVFo+T0hdtQ==
-END PUBLIC KEY-

This is just a PEM encoding of the real key (base 64 encoding of DER
structured data in PEM headers). Not sure where you get 124 bytes from,
but you can look take a look at the actual key data like this:

$ openssl pkey -in /tmp/key.pem -pubin -noout -text
Public-Key: (256 bit)
pub:
      04:55:29:a9:e1:49:e5:41:bc:db:7b:a7:a8:a4:1c:
      9e:11:4c:e4:99:81:cf:1a:06:8a:bd:2b:7f:c5:d0:
      20:bc:3a:7b:15:72:93:a5:24:fc:50:cf:4b:a4:5f:
      1f:e0:91:13:39:78:03:0c:6b:cd:94:80:ea:54:5a:
      3e:4f:48:5d:b5
ASN1 OID: prime256v1
NIST CURVE: P-256

This shows you the 65 bytes of raw public key data contained within the
key file.

This key is in "uncompressed" format (the 04 byte at the start
indicates
this). Since it is uncompressed we then get an x and a y value to
indicate the point on the curve. Each of these are 32 bytes long (256
bits) - so this gives you 65 bytes in total.

Matt



 >
 > Can someone help me understand why the difference?
 >
 > Thanks & Regards
 > --
 > Lokesh Chakka.

Re: 20240619 snapshots

[The Doctor via openssl-users]

On Wed, Jun 19, 2024 at 09:53:19AM +0200, Tomas Mraz wrote:
> They are there. Maybe you've looked too soon before the CDN caches were
> synchronized.
> 
> 
> On Tue, 2024-06-18 at 21:12 -0600, The Doctor via openssl-users wrote:
> > Where are they?
> 
> -- 
> Tom Mr??z, OpenSSL
> 

I use lynx
-- 
Member - Liberal International This is doc...@nk.ca Ici doc...@nk.ca
Yahweh, King & country!Never Satan President Republic!Beware AntiChrist rising!
Look at Psalms 14 and 53 on Atheism ;
United Kingdom save the NAtion on 4 July 2024 vote Liberal Democrat

Re: secp256r1 65 byte key size in packet capture

[Lokesh Chakka]

Hi Matt,

I'm trying to craft a client hello packet using a C program. I'm learning
about these keys, openssl, TLS etc.

So

openssl ecparam -name secp256r1 -genkey -out pvtkey.pem
openssl ec -in pvtkey.pem -pubout -out pubkey.pem
openssl pkey -in pubkey.pem -pubin -noout -text

will give me the 65 bytes. Understood. Thanks alot.

Now I need to explore C APIs for getting those keys as hex array.
Could you please suggest any good references for beginners.

Regards
--
Lokesh Chakka.


On Wed, Jun 19, 2024 at 4:21 PM Matt Caswell  wrote:

>
>
> On 19/06/2024 09:15, Lokesh Chakka wrote:
> > hello,
> >
> > I'm trying to generate public/private keys with following commands:
> >
> > openssl ecparam -name secp256r1 -genkey -out pvtkey.pem
> > openssl ec -in pvtkey.pem -pubout
> >
> > I'm seeing the sizeof private key as 164 bytes and public key as 124
> bytes.
> >
> > In a wireshark capture( attached ), I'm seeing key length as 65 bytes.
>
> What you are doing is confusing. You have generated public/private key
> pair for secp256r1 - but the wireshark capture you show seems to be the
> key share from a TLSv1.3 handshake. TLSv1.3 key shares are ephemeral so
> - you'll get a different key share every time. You don't need to create
> a public/private key for this. OpenSSL does it for you.
>
> Anyway. Taking the key that you generated:
>
> -BEGIN PUBLIC KEY-
> MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEVSmp4UnlQbzbe6eopByeEUzkmYHP
> GgaKvSt/xdAgvDp7FXKTpST8UM9LpF8f4JETOXgDDGvNlIDqVFo+T0hdtQ==
> -END PUBLIC KEY-
>
> This is just a PEM encoding of the real key (base 64 encoding of DER
> structured data in PEM headers). Not sure where you get 124 bytes from,
> but you can look take a look at the actual key data like this:
>
> $ openssl pkey -in /tmp/key.pem -pubin -noout -text
> Public-Key: (256 bit)
> pub:
>  04:55:29:a9:e1:49:e5:41:bc:db:7b:a7:a8:a4:1c:
>  9e:11:4c:e4:99:81:cf:1a:06:8a:bd:2b:7f:c5:d0:
>  20:bc:3a:7b:15:72:93:a5:24:fc:50:cf:4b:a4:5f:
>  1f:e0:91:13:39:78:03:0c:6b:cd:94:80:ea:54:5a:
>  3e:4f:48:5d:b5
> ASN1 OID: prime256v1
> NIST CURVE: P-256
>
> This shows you the 65 bytes of raw public key data contained within the
> key file.
>
> This key is in "uncompressed" format (the 04 byte at the start indicates
> this). Since it is uncompressed we then get an x and a y value to
> indicate the point on the curve. Each of these are 32 bytes long (256
> bits) - so this gives you 65 bytes in total.
>
> Matt
>
>
>
> >
> > Can someone help me understand why the difference?
> >
> > Thanks & Regards
> > --
> > Lokesh Chakka.
>

Re: secp256r1 65 byte key size in packet capture

[Matt Caswell]

On 19/06/2024 09:15, Lokesh Chakka wrote:

hello,

I'm trying to generate public/private keys with following commands:

openssl ecparam -name secp256r1 -genkey -out pvtkey.pem
openssl ec -in pvtkey.pem -pubout

I'm seeing the sizeof private key as 164 bytes and public key as 124 bytes.

In a wireshark capture( attached ), I'm seeing key length as 65 bytes.


What you are doing is confusing. You have generated public/private key 
pair for secp256r1 - but the wireshark capture you show seems to be the 
key share from a TLSv1.3 handshake. TLSv1.3 key shares are ephemeral so 
- you'll get a different key share every time. You don't need to create 
a public/private key for this. OpenSSL does it for you.


Anyway. Taking the key that you generated:

-BEGIN PUBLIC KEY-
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEVSmp4UnlQbzbe6eopByeEUzkmYHP
GgaKvSt/xdAgvDp7FXKTpST8UM9LpF8f4JETOXgDDGvNlIDqVFo+T0hdtQ==
-END PUBLIC KEY-

This is just a PEM encoding of the real key (base 64 encoding of DER 
structured data in PEM headers). Not sure where you get 124 bytes from, 
but you can look take a look at the actual key data like this:


$ openssl pkey -in /tmp/key.pem -pubin -noout -text
Public-Key: (256 bit)
pub:
04:55:29:a9:e1:49:e5:41:bc:db:7b:a7:a8:a4:1c:
9e:11:4c:e4:99:81:cf:1a:06:8a:bd:2b:7f:c5:d0:
20:bc:3a:7b:15:72:93:a5:24:fc:50:cf:4b:a4:5f:
1f:e0:91:13:39:78:03:0c:6b:cd:94:80:ea:54:5a:
3e:4f:48:5d:b5
ASN1 OID: prime256v1
NIST CURVE: P-256

This shows you the 65 bytes of raw public key data contained within the 
key file.


This key is in "uncompressed" format (the 04 byte at the start indicates 
this). Since it is uncompressed we then get an x and a y value to 
indicate the point on the curve. Each of these are 32 bytes long (256 
bits) - so this gives you 65 bytes in total.


Matt





Can someone help me understand why the difference?

Thanks & Regards
--
Lokesh Chakka.

Re: secp256r1 65 byte key size in packet capture

[Lokesh Chakka]

Understood. Thanks alot.
But I'm still Not able to understand why it is 65 bytes in the key value.


Thanks & Regards
--
Lokesh Chakka.


On Wed, Jun 19, 2024 at 3:03 PM Tomas Mraz  wrote:

> You need to do base64 decoding to find out the real size of the ASN.1
> encoded data.
>
> Tomas Mraz, OpenSSL
>
> On Wed, 2024-06-19 at 14:58 +0530, Lokesh Chakka wrote:
> > hi,
> >
> > please check the following :
> >
> > =
> > =
> > $ openssl ecparam -name secp256r1 -genkey -out pvtkey.pem
> > using curve name prime256v1 instead of secp256r1
> > $ cat pvtkey.pem
> > -BEGIN EC PARAMETERS-
> > BggqhkjOPQMBBw==
> > -END EC PARAMETERS-
> > -BEGIN EC PRIVATE KEY-
> > MHcCAQEEIAXXAWUj/cUQT8pDLKp5r269mw58aTzr/hYAEXQZVQqUoAoGCCqGSM49
> > AwEHoUQDQgAEVSmp4UnlQbzbe6eopByeEUzkmYHPGgaKvSt/xdAgvDp7FXKTpST8
> > UM9LpF8f4JETOXgDDGvNlIDqVFo+T0hdtQ==
> > -END EC PRIVATE KEY-
> > $ openssl ec -in pvtkey.pem -pubout
> > read EC key
> > writing EC key
> > -BEGIN PUBLIC KEY-
> > MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEVSmp4UnlQbzbe6eopByeEUzkmYHP
> > GgaKvSt/xdAgvDp7FXKTpST8UM9LpF8f4JETOXgDDGvNlIDqVFo+T0hdtQ==
> > -END PUBLIC KEY-
> > =
> > =
> >
> > sizeof private key is 164 bytes and the public key is 124 bytes.
> >
> >
> > Thanks & Regards
> > --
> > Lokesh Chakka.
> >
> >
> > On Wed, Jun 19, 2024 at 2:28 PM Tomas Mraz  wrote:
> > > Hi Lokesh,
> > >
> > > I am not sure how do you count the sizes of 164 bytes and 124 bytes
> > > for
> > > the pem files.
> > >
> > > If I use -outform DER (and use -noout with the ecparam to avoid
> > > outputting the params because the private key already contains info
> > > about the params used) I see the following sizes for the DER
> > > encoded
> > > data:
> > >
> > > private key: 121 bytes
> > > public key: 91 bytes
> > >
> > > Given both files contain information about the group used and other
> > > ASN.1 encoding related stuff, and that the private key file
> > > contains 32
> > > bytes of the private key but also the encoded uncompressed public
> > > key
> > > of 65 bytes, this is fully expected.
> > >
> > > Tomas Mraz, OpenSSL
> > >
> > > On Wed, 2024-06-19 at 13:45 +0530, Lokesh Chakka wrote:
> > > > hello,
> > > >
> > > > I'm trying to generate public/private keys with following
> > > > commands:
> > > >
> > > > openssl ecparam -name secp256r1 -genkey -out pvtkey.pem
> > > > openssl ec -in pvtkey.pem -pubout
> > > >
> > > > I'm seeing the sizeof private key as 164 bytes and public key as
> > > > 124
> > > > bytes.
> > > >
> > > > In a wireshark capture( attached ), I'm seeing key length as 65
> > > > bytes.
> > > >
> > > > Can someone help me understand why the difference?
> > > >
> > > > Thanks & Regards
> > > > --
> > > > Lokesh Chakka.
> > >
>
> --
> Tomáš Mráz, OpenSSL
>
>

Re: secp256r1 65 byte key size in packet capture

[Tomas Mraz]

You need to do base64 decoding to find out the real size of the ASN.1
encoded data.

Tomas Mraz, OpenSSL

On Wed, 2024-06-19 at 14:58 +0530, Lokesh Chakka wrote:
> hi,
> 
> please check the following :
> 
> =
> =
> $ openssl ecparam -name secp256r1 -genkey -out pvtkey.pem
> using curve name prime256v1 instead of secp256r1
> $ cat pvtkey.pem 
> -BEGIN EC PARAMETERS-
> BggqhkjOPQMBBw==
> -END EC PARAMETERS-
> -BEGIN EC PRIVATE KEY-
> MHcCAQEEIAXXAWUj/cUQT8pDLKp5r269mw58aTzr/hYAEXQZVQqUoAoGCCqGSM49
> AwEHoUQDQgAEVSmp4UnlQbzbe6eopByeEUzkmYHPGgaKvSt/xdAgvDp7FXKTpST8
> UM9LpF8f4JETOXgDDGvNlIDqVFo+T0hdtQ==
> -END EC PRIVATE KEY-
> $ openssl ec -in pvtkey.pem -pubout
> read EC key
> writing EC key
> -BEGIN PUBLIC KEY-
> MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEVSmp4UnlQbzbe6eopByeEUzkmYHP
> GgaKvSt/xdAgvDp7FXKTpST8UM9LpF8f4JETOXgDDGvNlIDqVFo+T0hdtQ==
> -END PUBLIC KEY-
> =
> =
> 
> sizeof private key is 164 bytes and the public key is 124 bytes.
> 
> 
> Thanks & Regards
> --
> Lokesh Chakka.
> 
> 
> On Wed, Jun 19, 2024 at 2:28 PM Tomas Mraz  wrote:
> > Hi Lokesh,
> > 
> > I am not sure how do you count the sizes of 164 bytes and 124 bytes
> > for
> > the pem files.
> > 
> > If I use -outform DER (and use -noout with the ecparam to avoid
> > outputting the params because the private key already contains info
> > about the params used) I see the following sizes for the DER
> > encoded
> > data:
> > 
> > private key: 121 bytes
> > public key: 91 bytes
> > 
> > Given both files contain information about the group used and other
> > ASN.1 encoding related stuff, and that the private key file
> > contains 32
> > bytes of the private key but also the encoded uncompressed public
> > key
> > of 65 bytes, this is fully expected.
> > 
> > Tomas Mraz, OpenSSL
> > 
> > On Wed, 2024-06-19 at 13:45 +0530, Lokesh Chakka wrote:
> > > hello,
> > > 
> > > I'm trying to generate public/private keys with following
> > > commands:
> > > 
> > > openssl ecparam -name secp256r1 -genkey -out pvtkey.pem
> > > openssl ec -in pvtkey.pem -pubout
> > > 
> > > I'm seeing the sizeof private key as 164 bytes and public key as
> > > 124
> > > bytes.
> > > 
> > > In a wireshark capture( attached ), I'm seeing key length as 65
> > > bytes.
> > > 
> > > Can someone help me understand why the difference?
> > > 
> > > Thanks & Regards
> > > --
> > > Lokesh Chakka.
> > 

-- 
Tomáš Mráz, OpenSSL

Re: secp256r1 65 byte key size in packet capture

[Lokesh Chakka]

hi,

please check the following :

==
$ openssl ecparam -name secp256r1 -genkey -out pvtkey.pem
using curve name prime256v1 instead of secp256r1
$ cat pvtkey.pem
-BEGIN EC PARAMETERS-
BggqhkjOPQMBBw==
-END EC PARAMETERS-
-BEGIN EC PRIVATE KEY-
MHcCAQEEIAXXAWUj/cUQT8pDLKp5r269mw58aTzr/hYAEXQZVQqUoAoGCCqGSM49
AwEHoUQDQgAEVSmp4UnlQbzbe6eopByeEUzkmYHPGgaKvSt/xdAgvDp7FXKTpST8
UM9LpF8f4JETOXgDDGvNlIDqVFo+T0hdtQ==
-END EC PRIVATE KEY-
$ openssl ec -in pvtkey.pem -pubout
read EC key
writing EC key
-BEGIN PUBLIC KEY-
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEVSmp4UnlQbzbe6eopByeEUzkmYHP
GgaKvSt/xdAgvDp7FXKTpST8UM9LpF8f4JETOXgDDGvNlIDqVFo+T0hdtQ==
-END PUBLIC KEY-
==

sizeof private key is 164 bytes and the public key is 124 bytes.


Thanks & Regards
--
Lokesh Chakka.


On Wed, Jun 19, 2024 at 2:28 PM Tomas Mraz  wrote:

> Hi Lokesh,
>
> I am not sure how do you count the sizes of 164 bytes and 124 bytes for
> the pem files.
>
> If I use -outform DER (and use -noout with the ecparam to avoid
> outputting the params because the private key already contains info
> about the params used) I see the following sizes for the DER encoded
> data:
>
> private key: 121 bytes
> public key: 91 bytes
>
> Given both files contain information about the group used and other
> ASN.1 encoding related stuff, and that the private key file contains 32
> bytes of the private key but also the encoded uncompressed public key
> of 65 bytes, this is fully expected.
>
> Tomas Mraz, OpenSSL
>
> On Wed, 2024-06-19 at 13:45 +0530, Lokesh Chakka wrote:
> > hello,
> >
> > I'm trying to generate public/private keys with following commands:
> >
> > openssl ecparam -name secp256r1 -genkey -out pvtkey.pem
> > openssl ec -in pvtkey.pem -pubout
> >
> > I'm seeing the sizeof private key as 164 bytes and public key as 124
> > bytes.
> >
> > In a wireshark capture( attached ), I'm seeing key length as 65
> > bytes.
> >
> > Can someone help me understand why the difference?
> >
> > Thanks & Regards
> > --
> > Lokesh Chakka.
>
> --
> Tomáš Mráz, OpenSSL
>
>

Re: secp256r1 65 byte key size in packet capture

[Tomas Mraz]

Hi Lokesh,

I am not sure how do you count the sizes of 164 bytes and 124 bytes for
the pem files.

If I use -outform DER (and use -noout with the ecparam to avoid
outputting the params because the private key already contains info
about the params used) I see the following sizes for the DER encoded
data:

private key: 121 bytes
public key: 91 bytes

Given both files contain information about the group used and other
ASN.1 encoding related stuff, and that the private key file contains 32
bytes of the private key but also the encoded uncompressed public key
of 65 bytes, this is fully expected.

Tomas Mraz, OpenSSL

On Wed, 2024-06-19 at 13:45 +0530, Lokesh Chakka wrote:
> hello,
> 
> I'm trying to generate public/private keys with following commands:
> 
> openssl ecparam -name secp256r1 -genkey -out pvtkey.pem
> openssl ec -in pvtkey.pem -pubout
> 
> I'm seeing the sizeof private key as 164 bytes and public key as 124
> bytes.
> 
> In a wireshark capture( attached ), I'm seeing key length as 65
> bytes.
> 
> Can someone help me understand why the difference?
> 
> Thanks & Regards
> --
> Lokesh Chakka.

-- 
Tomáš Mráz, OpenSSL

secp256r1 65 byte key size in packet capture

[Lokesh Chakka]

hello,

I'm trying to generate public/private keys with following commands:

openssl ecparam -name secp256r1 -genkey -out pvtkey.pem
openssl ec -in pvtkey.pem -pubout

I'm seeing the sizeof private key as 164 bytes and public key as 124 bytes.

In a wireshark capture( attached ), I'm seeing key length as 65 bytes.

Can someone help me understand why the difference?

Thanks & Regards
--
Lokesh Chakka.

Re: 20240619 snapshots

[Tomas Mraz]

They are there. Maybe you've looked too soon before the CDN caches were
synchronized.


On Tue, 2024-06-18 at 21:12 -0600, The Doctor via openssl-users wrote:
> Where are they?

-- 
Tomáš Mráz, OpenSSL

20240619 snapshots

[The Doctor via openssl-users]

Where are they?
-- 
Member - Liberal International This is doc...@nk.ca Ici doc...@nk.ca
Yahweh, King & country!Never Satan President Republic!Beware AntiChrist rising!
Look at Psalms 14 and 53 on Atheism ;
United Kingdom save the NAtion on 4 July 2024 vote Liberal Democrat

RE: [EXTERNAL] - 32-bit OpenSSL binary found in Suprema BioStar 2 door access system

[Turritopsis Dohrnii Teo En Ming via openssl-users]

On Wednesday, April 17th, 2024 at 6:57 AM, Michael Wojcik via openssl-users 
 wrote:

> > From: Turritopsis Dohrnii Teo En Ming teo.en.m...@protonmail.com
> > Sent: Monday, 15 April, 2024 07:36
> > 
> > > > From: openssl-users openssl-users-boun...@openssl.org On Behalf Of
> > > > Turritopsis Dohrnii Teo En Ming via openssl-users
> > > > Sent: Saturday, 9 March, 2024 06:59
> > > > To: openssl-users@openssl.org
> > > > 
> > > > On 7 March 2024 Thursday, when I was installing new self-signed SSL
> > > > certificate for the door access system for a law firm in Singapore, I 
> > > > notice that
> > > > Suprema BioStar 2 also has 32-bit OpenSSL binary.
> > > > 
> > > > The path is:
> > > > 
> > > > C:\Program Files\BioStar 2(x64)\ta\OpenSSL-Win32\bin
> > > > 
> > > > I am wondering if I can install 64-bit OpenSSL binary from another 
> > > > packager.
> > > > Will there be any conflict?
> 
> > I am thinking of installing Third Party OpenSSL Related Binary 
> > Distributions like
> > FireDaemon.
> 
> 
> I can't comment on that; I don't know what it contains, or how its 
> installation process works.
> 
> > I think there shouldn't be a conflict.
> 
> 
> This is more a question about Windows and how it loads DLLs, than it is an 
> OpenSSL question.
> 
> Assuming BioStar 2 loads the OpenSSL DLLs using the normal Windows mechanism, 
> from EXEs in the same directory as those DLLs, then it should continue to 
> load its own OpenSSL DLLs. Windows puts the EXE's directory at the start of 
> the DLL search path when doing a normal implicit load, assuming no SxS 
> nonsense interferes. Though that said, it's odd that BioStar 2 puts the 
> OpenSSL DLLs in a "bin" directory (apparently) of their own. I can't say what 
> BioStar 2 is up to here; I have no idea how the developers of that package 
> expect things to work.
> 
> The other concern is whether any other programs which use OpenSSL will end up 
> loading it from the BioStar 2 OpenSSL-Win32\bin directory rather than the 
> FireDaemon installation directory, whatever that might be. Applications which 
> simply have an implicit dependency on the OpenSSL DLLs, or which do a 
> conventional LoadLibrary, will typically end up searching the directories in 
> their PATH environment value. So you would want to ensure that the FireDaemon 
> directory containing the OpenSSL DLLs is earlier in the PATH for at least 
> those applications, and probably for everything — assuming BioStar 2 does 
> something sensible like specify its library-loading source.
> 
> In short, it's impossible for anyone to say whether there will be a problem 
> without recreating your environment. This is a universal difficulty with 
> loading shared modules. The best approach for professional software is to 
> avoid using modules which might conflict, by being explicit with their 
> linking or using alternative file and symbol names or whatever. But many ISVs 
> do not take that precaution.
> 
> --
> Michael Wojcik

Dear Michael,

Noted with thanks.

Mr. Turritopsis Dohrnii Teo En Ming
Targeted Individual in Singapore

Re: New OpenSSL Releases

[Matt Caswell]

On 09/06/2024 19:59, Dennis Clarke via openssl-users wrote:

On 5/30/24 11:15, Michael Wojcik via openssl-users wrote:
From: openssl-users  On Behalf Of 
Dennis

Clarke via openssl-users
Sent: Thursday, 30 May, 2024 07:29

OKay, thank you. I guess today is a good day to test on a few oddball
system architectures. I suspect there are very very few people out there
running actual HPE Itanium hardware or big-endian IBM POWER and that
often raises a few bugs that slip under the radar.


Itanium is rare (we've stopped supporting it)...


Well I can report only two tests fail :

Test Summary Report
---
04-test_bio_dgram.t   (Wstat: 256 (exited 1) Tests: 1 
Failed: 1)

   Failed test:  1
   Non-zero exit status: 1
65-test_cmp_client.t  (Wstat: 256 (exited 1) Tests: 2 
Failed: 1)

   Failed test:  1
   Non-zero exit status: 1
Files=312, Tests=3685, 18523 wallclock secs (46.06 usr  1.22 sys + 
18271.89 cusr 170.74 csys = 18489.91 CPU)

Result: FAIL


So that is pretty cool on an Itanium :

garak$
garak$ uname -a
Linux garak 6.6.30-gentoo-ia64 #1 SMP Tue May 14 20:07:58 UTC 2024 ia64 
Madison GenuineIntel GNU/Linux

garak$

Now I am going to go digging and see where those tests fail. May be
something trivial.

garak$
garak$ find . | grep 'test_bio_dgram'
./test-runs/test_bio_dgram
./test/recipes/04-test_bio_dgram.t
garak$
garak$ find . | grep 'test_cmp_client'
./test-runs/test_cmp_client
./test/recipes/65-test_cmp_client_data
./test/recipes/65-test_cmp_client_data/client.csr
./test/recipes/65-test_cmp_client_data/client.key
./test/recipes/65-test_cmp_client_data/server.key
./test/recipes/65-test_cmp_client_data/server.crt
./test/recipes/65-test_cmp_client_data/client.crt
./test/recipes/65-test_cmp_client.t
garak$

No obvious output log files there.



Try this to give more verbose output for a specific test failure:

make TESTS=test_bio_dgram V=1 test


Matt