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: 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<mailto: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 pa

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_CORTEXA

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 
-

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.

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/in

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<http://www.mdsol.com/>


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<http://www.mdsol.com/>

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<http://www.mdsol.com/>


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<http://www.mdsol.com/>


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/

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

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

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

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<http://www.mdsol.com/>


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/

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<http://www.mdsol.com/>

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<http://www.mdsol.com/>

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<http://www.mdsol.com/>


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

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<http://www.mdsol.com/>

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<http://www.mdsol.com/>


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/

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<http://www.mdsol.com/>

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<mailto: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\ty

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

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.

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

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: 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 
OpenSSL<https://www.openssl.org/docs/man3.1/man3/TS_VERIFY_CTS_set_certs.html>1<https://www.openssl.org/docs/man3.1/man3/TS_VERIFY_CTS_set_certs.html>.
 This function is used to set the server’s certificate chain when verifying a 
TimeStampToken 
(TST)<https://www.openssl.org/docs/man3.1/man3/TS_VERIFY_CTS_set_certs.html>1<https://www.openssl.org/docs/man3.1/man3/TS_VERIFY_CTS_set_certs.html>.

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 
deprecated<https://www.openssl.org/docs/man3.1/man3/TS_VERIFY_CTS_set_certs.html>1<https://www.openssl.org/docs/man3.1/man3/TS_VERIFY_CTS_set_certs.html>.

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<http://www.mdsol.com/>

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 <http://www.mdsol.com/>

>

> *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<mailto:openssl-users@openssl.org>

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

>

> TS_VERIFY_CTX is an opaque structur

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 <http://www.mdsol.com/>

>

> *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$<https://urldefense.com/v3/__https:/github.com/openssl/openssl__;!!FbCVDoc3r24SyHFW!8NySO-tJ589YiMdFNLtEu_6Hc7knvKgfTOXGkAFWjfEMxLaE5oRe3igKb4JOdd9HiiJ8sLVdiV6SYZo$><https://urldefense.com/v3/__https:/github.com/openssl/openssl__;!!FbCVDoc3r24SyHFW!8NySO-tJ589YiMdFNLtEu_6Hc7knvKgfTOX

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<http://www.mdsol.com/>

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$<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<http://www.mdsol.com/>

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$<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 <http://www.mdsol.com/>

>

> 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/

> <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/

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 attac

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/

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/

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<http://www.mdsol.com/>

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<https://urldefense.com/v3/__https:/github.com/openssl/openssl/blob/openssl-3.0.8/NOTES-WINDOWS.md*native-builds-using-visual-c__;Iw!!FbCVDoc3r24SyHFW!9BqZOCOxlpRTXjW5drCeGn-ixU7WUYpkDFukFHevsdCQNboc_RsPmguI6sPk97qPk97xQcn2iwI2Az3DNQ$>
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&q

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<http://www.mdsol.com/>


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: 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

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: [External] : Why do I get the following error `wrong signature length` when I try to validate a signed file using the c++ OpenSSL 3.1 library?

[Thomas Dwyer III via openssl-users]

|if (EVP_PKEY_verify(ctx, licenseSignature, sizeof(licenseSignature), 
licenseContent, sizeof(licenseContent)) <= 0)|


The sizeof operator is not doing what you think it's doing. It's 
computing the sizes of the pointers (typically 4 or 8 bytes depending on 
your architecture) and not the sizes of your signature & signed content. 
You need to pass additional size_t values to your verifyLicense() 
function so that EVP_PKEY_verify() can know what those lengths really 
are. It's impossible to determine this from just a char* pointer.



Tom.III


On 6/10/24 13:15, Christian F. Gonzalez Di Antonio wrote:
I posted this on 
https://stackoverflow.com/questions/78604338/why-do-i-get-the-following-error-wrong-signature-length-when-i-try-to-validate 
<https://urldefense.com/v3/__https://stackoverflow.com/questions/78604338/why-do-i-get-the-following-error-wrong-signature-length-when-i-try-to-validate__;!!ACWV5N9M2RV99hQ!NbxXgIkXi0CHG7PAehmOM_k1dXimFAfepGUTqIqQlJDfvxHviaWiNf3Cq45qlpW8zwSBX6jMtdkdlo7VlGpofDCM$> 



I'm writing an c++ program LicenseValidator -> 
https://github.com/christiangda/LicenseValidator 
<https://urldefense.com/v3/__https://github.com/christiangda/LicenseValidator__;!!ACWV5N9M2RV99hQ!NbxXgIkXi0CHG7PAehmOM_k1dXimFAfepGUTqIqQlJDfvxHviaWiNf3Cq45qlpW8zwSBX6jMtdkdlo7VlA9bse82$> to 
validate a hypothetical |program license| using OpenSSL 3.1 Library 
<https://urldefense.com/v3/__https://wiki.openssl.org/index.php/OpenSSL_3.0__;!!ACWV5N9M2RV99hQ!NbxXgIkXi0CHG7PAehmOM_k1dXimFAfepGUTqIqQlJDfvxHviaWiNf3Cq45qlpW8zwSBX6jMtdkdlo7VlL35ykQZ$>, 
and when I tried to validate the licensed content I got the following 
error:


|Failed to verify license 008C1AF90100:error:0277:rsa 
routines:ossl_rsa_verify:wrong signature 
length:crypto/rsa/rsa_sign.c:338: 
008C1AF90100:error:1C880004:Provider routines:rsa_verify:RSA 
lib:providers/implementations/signature/rsa_sig.c:785: |


I would appreciate any help or guidance on what I am doing wrong.

I am not at all an expert in the c/c++ programming language and this 
is the first time I have tried to use the OpenSSL library.


Of course, I've used GitHub Copilot, gemini, and chatgpt to write and 
understand the repository code. The chalenge is about the examples I 
found on internet, the majority of them are about OpenSSL v1 and the 
v3 is very different, so was hard to understand the migration.


The README.md 
<https://urldefense.com/v3/__https://github.com/christiangda/LicenseValidator/blob/main/README.md__;!!ACWV5N9M2RV99hQ!NbxXgIkXi0CHG7PAehmOM_k1dXimFAfepGUTqIqQlJDfvxHviaWiNf3Cq45qlpW8zwSBX6jMtdkdlo7VlB0fGmIT$> file 
has the instructions to create all the necessary keys, etc, references 
I used and the instructions to compile it using cmake.


The core function is LicenseValidator/src/License.cpp 
<https://urldefense.com/v3/__https://github.com/christiangda/LicenseValidator/blob/82f5501ab2e5bf2d91dc4298245b36fde2efd66b/src/License.cpp*L79__;Iw!!ACWV5N9M2RV99hQ!NbxXgIkXi0CHG7PAehmOM_k1dXimFAfepGUTqIqQlJDfvxHviaWiNf3Cq45qlpW8zwSBX6jMtdkdlo7VlOpxxmDb$>:


|bool verifyLicense(const unsigned char *licenseContent, const 
unsigned char *licenseSignature, const std::string pubkey) { EVP_PKEY 
*pkey = loadRsaPemPubKey(pubkey); if (pkey == NULL) { std::cerr << 
"Failed to load public key" << std::endl; ERR_print_errors_fp(stdout); 
return false; } EVP_PKEY_CTX *ctx = EVP_PKEY_CTX_new(pkey, NULL); if 
(ctx == NULL) { std::cerr << "Failed to create EVP_PKEY_CTX" << 
std::endl; EVP_PKEY_free(pkey); ERR_print_errors_fp(stdout); return 
false; } if (EVP_PKEY_verify_init(ctx) <= 0) { std::cerr << "Failed to 
initialize EVP_PKEY_CTX" << std::endl; EVP_PKEY_CTX_free(ctx); 
EVP_PKEY_free(pkey); ERR_print_errors_fp(stdout); return false; } // 
PKCS1 padding scheme if (EVP_PKEY_CTX_set_rsa_padding(ctx, 
RSA_PKCS1_PADDING) <= 0) { std::cerr << "Failed to set RSA padding" << 
std::endl; EVP_PKEY_CTX_free(ctx); EVP_PKEY_free(pkey); 
ERR_print_errors_fp(stdout); return false; } // SHA256 digest if 
(EVP_PKEY_CTX_set_signature_md(ctx, EVP_sha256()) <= 0) { std::cerr << 
"Failed to set signature MD" << std::endl; EVP_PKEY_CTX_free(ctx); 
EVP_PKEY_free(pkey); ERR_print_errors_fp(stdout); return false; } if 
(EVP_PKEY_verify(ctx, licenseSignature, sizeof(licenseSignature), 
licenseContent, sizeof(licenseContent)) <= 0) { std::cerr << "Failed 
to verify license" << std::endl; EVP_PKEY_CTX_free(ctx); 
EVP_PKEY_free(pkey); ERR_print_errors_fp(stdout); return false; } 
EVP_PKEY_CTX_free(ctx); EVP_PKEY_free(pkey); return true; } |


Some guidance about how to solve the error I got.


--
Saludos,
Christian

Re: New OpenSSL Releases

[Dennis Clarke via openssl-users]

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.



--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken

OpenSSL version 3.1.6 published

[OpenSSL]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


   OpenSSL version 3.1.6 released
   ==

   OpenSSL - The Open Source toolkit for SSL/TLS
   https://www.openssl.org/

   The OpenSSL project team is pleased to announce the release of
   version 3.1.6 of our open source toolkit for SSL/TLS.
   For details of the changes, see the release notes at:

https://www.openssl.org/news/openssl-3.1-notes.html

   Specific notes on upgrading to OpenSSL 3.1 from previous versions are
   available in the OpenSSL Migration Guide, here:

https://www.openssl.org/docs/man3.1/man7/migration_guide.html

   The OpenSSL 3.1.6 is available for download at these URLs:

 * https://www.openssl.org/source/
 * https://github.com/openssl/openssl/releases

   The distribution file name is:

o openssl-3.1.6.tar.gz
  Size: 15672690
  SHA1 checksum:  2ab959fbc11283a0bc7a39e33b8f6862372cfc9a
  SHA256 checksum:  
5d2be4036b478ef3cb0a854ca9b353072c3a0e26d8a56f8f0ab9fb6ed32d38d7

   The checksums were calculated using the following commands:

openssl sha1 openssl-3.1.6.tar.gz
openssl sha256 openssl-3.1.6.tar.gz

   Yours,

   The OpenSSL Project Team.

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEE78CkZ9YTy4PH7W0w2JTizos9efUFAmZfItwACgkQ2JTizos9
efVb5Q/9GEh1L3F0bHg5aKH5yD5EwFcQ8Vjj2Prd2O7JDWaZ7Nj9pTzW0R+Fqlst
F2oFM8mPGGP41NNfF6otPKvFfen/mKkygX0HvvmTzH88wn+4hBsTngOs5xSnNrZD
pUc7RTdtBVaQN3M7Rg9EVN2bqJBLhiw+d/zGTU72SD/f3fr0rmt6ViZiuUNLkj6B
+wZKxCELMiLP2Sl1bfC+SF+gCjBR+4iZG0viL8U891PzuD77dp+Zzs637pjD1Qsd
k8BRu+fxd9dz7D6OAt2eHyDwqvR/0rlzsiE40Cx0KamF3Ck1c0sqcxcfc/SXmGyr
OePg8aI0qUHDjgZN5v3z4aSfmcymNayTVoEiCYdb4MYsKY/ydLjDS/VnfR4KtfI5
FGaiW+Fua9JDLS0wLcREiq4bjdfae3dzEUlClO4zMesP+3pDNWcPbam9DptG36pc
RPIe55X3VoJDEEPju6flyvA6ZlyFDc1Qf/1G+9gXYke3r4EQIRrAIibZucVrGs8k
926hHSJOGX1s0sJOMJv7PkUsZO+8W7xwHHUH/WQzMoigrXnFhQvK+vPHCz3nnyQX
WmSedMR2UNHyn26AuPDhS3pHCCkYHZQcKJDPsMmgEQaMrAhs++4ob91/L/uBJIuz
9Cb7yo7JIgAAqUSkZApLb5As8Qo8qoWzPAY7QNznVkpcnCTkzIw=
=qMw6
-END PGP SIGNATURE-

OpenSSL version 3.0.14 published

[OpenSSL]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


   OpenSSL version 3.0.14 released
   ===

   OpenSSL - The Open Source toolkit for SSL/TLS
   https://www.openssl.org/

   The OpenSSL project team is pleased to announce the release of
   version 3.0.14 of our open source toolkit for SSL/TLS.
   For details of the changes, see the release notes at:

https://www.openssl.org/news/openssl-3.0-notes.html

   Specific notes on upgrading to OpenSSL 3.0 from previous versions are
   available in the OpenSSL Migration Guide, here:

https://www.openssl.org/docs/man3.0/man7/migration_guide.html

   The OpenSSL 3.0.14 is available for download at these URLs:

 * https://www.openssl.org/source/
 * https://github.com/openssl/openssl/releases

   The distribution file name is:

o openssl-3.0.14.tar.gz
  Size: 15305497
  SHA1 checksum:  80b67212212a5ba81b071026d1ad851d6cbcca93
  SHA256 checksum:  
eeca035d4dd4e84fc25846d952da6297484afa0650a6f84c682e39df3a4123ca

   The checksums were calculated using the following commands:

openssl sha1 openssl-3.0.14.tar.gz
openssl sha256 openssl-3.0.14.tar.gz

   Yours,

   The OpenSSL Project Team.

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEE78CkZ9YTy4PH7W0w2JTizos9efUFAmZfJFUACgkQ2JTizos9
efXypBAAqsEyCqkpJkOZQDiPn0nyFhlCaHaA15MVeQjHUxcGbcEWj7EMOVUDb1UG
IXkywtTRpoGzPnT8wHcQFXEpXEDP4QyuEJ1s4il5gg17TRoA5arLErul8uq2HeqT
wnPe2WAkt1UP1dYIDq+WnKhQUsFl81g2hmF9wtNwyIH7mZyxJhSDKJVcA3ojJL6q
AvjRQBr8gBy67WsIvoJbnmvqkjNkLYYP0nvm66Qcx9kAxhL86XKPEyhOKHv/OP1v
lgD54+kPaRV2fFkr3sdqc1IrfsRVpG4GIpLZQzaxRl4coItXWeDdooIUsQHVrlb2
WyfBMyWlhQt6nftoLgrv70ACwqXjrkO6vULmq87OW6rZTytb1iv/U57lzOsg2NLQ
BfvvSV/6QYLYhssOZKC8EG/+cwzs91XJpzmx0zlT4uxoam/GUxMbq13ULnZZq/XW
Ogj0axmyAGSgEQvOR//sRW7HxQNweeQJTKoZiYQYLT9gPkpTC2Tr4ZJ7Gm4BCjG1
g3j4cfgbBM4a4rk1u5oK5fciAhJj4Z793PcKWgnuAWHb60/2QyCa2rUibZbgVgQq
WPFVTzgAxSrvqGwyI2GcbllYFL1hOhn6H2dTg/nWfZ5WgpdyrIHKK0RMs/Ifw1+9
h+P0reR5ua8VGlCzJnl7vhOexehJC5bhl+8P0f19DjglDIgwOUM=
=ThVk
-END PGP SIGNATURE-

OpenSSL version 3.3.1 published

[OpenSSL]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


   OpenSSL version 3.3.1 released
   ==

   OpenSSL - The Open Source toolkit for SSL/TLS
   https://www.openssl.org/

   The OpenSSL project team is pleased to announce the release of
   version 3.3.1 of our open source toolkit for SSL/TLS.
   For details of the changes, see the release notes at:

https://www.openssl.org/news/openssl-3.3-notes.html

   Specific notes on upgrading to OpenSSL 3.3 from previous versions are
   available in the OpenSSL Migration Guide, here:

https://www.openssl.org/docs/man3.3/man7/migration_guide.html

   The OpenSSL 3.3.1 is available for download at these URLs:

 * https://www.openssl.org/source/
 * https://github.com/openssl/openssl/releases

   The distribution file name is:

o openssl-3.3.1.tar.gz
  Size: 18055752
  SHA1 checksum:  7376042523b6a229bc697b8099c2af369d1a84c6
  SHA256 checksum:  
777cd596284c883375a2a7a11bf5d2786fc5413255efab20c50d6ffe6d020b7e

   The checksums were calculated using the following commands:

openssl sha1 openssl-3.3.1.tar.gz
openssl sha256 openssl-3.3.1.tar.gz

   Yours,

   The OpenSSL Project Team.

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEE78CkZ9YTy4PH7W0w2JTizos9efUFAmZfDj8ACgkQ2JTizos9
efWupw//W5wxuesxX8vrNS5p1k1Nut8gw8xNLMK0vCL904DuxDZOoIzydIf2lD0x
B5KKOiH0oI4mp9FlzDln4TqlN6z5F9mfSSrSfVn/9T+7KyvBq1FOqJJ3qVsrQtdA
2dOK+lSKmbQRe32YNrDWyuFt/0XDAoolRcUdFs+Z84wL0VfvVyNcT7DGBcsuYA3J
jomMmtHHvzcBiu4/9OK+30Tfa1L+JPoeIQy3lABpbRi8UUt1RMG1Ud9MbqEwQKuA
hxPnFhS3f5PGkED1EmNCOqi+XAQ6d9h5p1SYUvYHJwr0kK1XqiEo6a7w+xj/oZ3D
tUY48H2AM6x7InyGdWO1Hcbv+dyAVVSYS0tPvp7DcdlkjB+FheBiuEeLF4DoIQBo
0eLIKfpti+1HAPwyHi0Pxb9Rn+iMgP0CzXlLSHAgsjRh0a1hDe64Q0tqE4AOPAYU
52U6/DlkdJbpZtSZjXpdVTt55DPnMAo5tgftojEMYjKD6MyetdWhezh0f0AoK+qZ
6tgCMn3AYhZS/DHB+UoaEmHf2k1kKQOxQljWy7Pn9EDXHckWxQ3z26W/YaiCIeXB
C+Y8fZn3aL7J/COx9o84k3/5bh9pGkCfEpQOjPD8y9r3XBMbnbvdHXzIfr4MeSpf
mo4tWLoT2P5HgDwZexN32HLKhQwzipAQk/ARBVCSb4KACRgNTW4=
=3f9G
-END PGP SIGNATURE-

OpenSSL version 3.2.2 published

[OpenSSL]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


   OpenSSL version 3.2.2 released
   ==

   OpenSSL - The Open Source toolkit for SSL/TLS
   https://www.openssl.org/

   The OpenSSL project team is pleased to announce the release of
   version 3.2.2 of our open source toolkit for SSL/TLS.
   For details of the changes, see the release notes at:

https://www.openssl.org/news/openssl-3.2-notes.html

   Specific notes on upgrading to OpenSSL 3.2 from previous versions are
   available in the OpenSSL Migration Guide, here:

https://www.openssl.org/docs/man3.2/man7/migration_guide.html

   The OpenSSL 3.2.2 is available for download at these URLs:

 * https://www.openssl.org/source/
 * https://github.com/openssl/openssl/releases

   The distribution file name is:

o openssl-3.2.2.tar.gz
  Size: 17744472
  SHA1 checksum:  b12311372a0277ca0eb218a68a7fd9f5ce66d162
  SHA256 checksum:  
197149c18d9e9f292c43f0400acaba12e5f52cacfe050f3d199277ea738ec2e7

   The checksums were calculated using the following commands:

openssl sha1 openssl-3.2.2.tar.gz
openssl sha256 openssl-3.2.2.tar.gz

   Yours,

   The OpenSSL Project Team.

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEE78CkZ9YTy4PH7W0w2JTizos9efUFAmZfEBUACgkQ2JTizos9
efU4ihAAiyA2vUL0OFnXfXpKi3hnRnKkwJxxuBwYAqAsPFejwJ6+u4oe1GesZewE
q3wmVhp9JVjpxBz3ExLmss9SRty4fPOUJhfw43TZ9Wes6RmWPsFtb/QyNhvi4v41
MAlKkxYtjP9e/cVJvPVVJLxfCScGdiwwJ7jGxQNpaDCa99phVfMor2mlvlxBkNxu
attWRc+S7NGUQEfAxMrgDFgUV3sihkadzYFPDiCVqUBXgZkoHcjyCl78fnqPjNEP
juSORGglJbyOK0IydiluRqOsDWswWKkMrLO4uxbtgJkpRM+u7+MAqVfQQeCFiBAU
z2v3grMtM+FcMUC0ABF9jQY8y7KKpTy7jj4bOE3DaoPyrJVCFq+oHyqbNazErCAD
qgerxI2NbaUAOqI+LxyZOwtfLYX93cjMGpydfF6J46uy9i8U9g4qv0ruZAhSyigb
/tKBYNflwjF0zm4YAlM7UZHBCQJjlFNiodvsMUG36o3D/6+FXXAWXw/++KxRipl7
HFI0HpKE9p7z7+vJtvJovrbtyokUjuQHU6RhAzBJGT9UqV8wJa1G0qqbqqR06dm5
iP80abrTtKUxq1h9DthLWe1kqU0VWnz41+WiMxwzDOAPGKsozBTOAxVBFMBJHWcj
KIMKq3wsqrK16pK8yaugCRAlDvWNurPxjWTqtta3lZOnY9HmHio=
=B/li
-END PGP SIGNATURE-

RE: Issue in DH Algorithm Keys Generation in OpenSSL 3.3.0

[Vishal Kevat via openssl-users]

Hi Viktor,



I have assigned the task find out the root cause where the API is failing with 
this composite number. I see that with this composite number, the API 
BN_mod_inverse(Ri, R, &tmod, ctx) is returning NULL. (This is being called in 
bn_mont.c).

This function is defined in bn_gcd.c

Because of this API failed to return non-null value, the final API 
DH_generate_key() is failed to generate the DH public and private keys.



Can you explain what does the BN_mod_inverse() actually does.

Is this API related to the prime check on the DH Algorithm input prime number?



Regards,

Vishal






General

-Original Message-
From: openssl-users  On Behalf Of Viktor 
Dukhovni
Sent: Friday, May 31, 2024 06:14 PM
To: openssl-users@openssl.org
Subject: Re: Issue in DH Algorithm Keys Generation in OpenSSL 3.3.0



[External email: Use caution with links and attachments]











On Fri, May 31, 2024 at 12:39:12PM +, Vishal Kevat via openssl-users wrote:



> Is there any way to make this prime number work by doing some

> modifications in the openssl source code.



It ISN'T a *prime* number.



> Like bypassing the OpenSSL DH prime check?



Why do you want to use a broken DH group?  Even if that 128-bit composite 
number were instead prime, it would still be way too small to offer any 
security.



It is hard to imagine how what you're asking for makes any sense.



--

Viktor.

Re: Blocking on a non-blocking socket?

[Wiebe Cazemier via openssl-users]

- Original Message -
> From: "Wiebe Cazemier" 
> To: openssl-users@openssl.org
> Sent: Thursday, 23 May, 2024 12:22:31
> Subject: Blocking on a non-blocking socket?
>
> Hi List,
> 
> I have a very obscure problem with an application using O_NONBLOCK still
> blocking. Over the course of a year of running with hundreds of thousands of
> clients, it has happened twice over the last month that a worker thread froze.
> It's a long story, but I'm pretty sure it's not a deadlock or spinning event
> loop or something, primarily because the application recovers after about 20
> minutes with a client errorring out with ETIMEDOUT. Coincidentally, that 20
> minutes matches the timeout description of the tcp man page [1].
> 
> It really looks like a non-blocking socket is still blocking. I found 
> something
> with a similar problem ([2]), but what they think of SSL_MODE_AUTO_RETRY does
> not match the documentation.
> 
> So, is there indeed any way an application that has SSL_MODE_AUTO_RETRY on
> (which is default since 1.1.1) can block? Looking at the source code, I don't
> see any calls to fcntl() that removes the O_NONBLOCK.
> 
> My IO method is SSL_read() and SSL_write() with an SSL object given to
> SSL_set_fd().
> 
> The only SSL modes I change from the default is that I set
> SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER.
> 
> There are two primary deployments of this application, one with OpenSSL 1.1.1
> and one with 3.0.0. Only 1.1.1 has shown this problem, but it may be a
> coincidence.
> 
> Side question, is it a problem to set SSL_set_fd() before using fcntl to set 
> the
> fd to O_NONBLOCK? I ask, because the docs say "The BIO and hence the SSL 
> engine
> inherit the behaviour of fd. If fd is non-blocking, the ssl will also have
> non-blocking behaviour.". The 'inherit' may be a key word here; not sure when
> it's done.
> 
> Regards,
> 
> Wiebe Cazemier


As a follow-up, the fault did turn out to be my own... As I imagine [1] is. 
They describe SSL_MODE_AUTO_RETRY 'attempts to renegotiate a broken SSL 
connection', but all SSL_MODE_AUTO_RETRY indeed really does is read multiple 
records at a time, without returning from read. 

Despite what I thought before, my code actually did have an unfortunate edge 
case where there was a while loop spinning on SSL_write() when there was no 
room in the socket. This would eventually fail with ETIMEDOUT.

Well, it was educational at least...


[1] https://github.com/alanxz/rabbitmq-c/issues/586

RE: Issue in DH Algorithm Keys Generation in OpenSSL 3.3.0

[Vishal Kevat via openssl-users]

Hi Viktor,

Is there any way to make this prime number work by doing some modifications in 
the openssl source code.

Like bypassing the OpenSSL DH prime check?

Regards,
Vishal


General
-Original Message-
From: openssl-users  On Behalf Of Viktor 
Dukhovni
Sent: Friday, May 31, 2024 03:01 PM
To: openssl-users@openssl.org
Subject: Re: Issue in DH Algorithm Keys Generation in OpenSSL 3.3.0

[External email: Use caution with links and attachments]





On Fri, May 31, 2024 at 07:47:40AM +, Vishal Kevat via openssl-users wrote:

> I am using OpenSSL source version 3.3.0 and facing an issue in key
> generation part of Diffie Hellman (DH) Algorithm. Below are the APIs I
> am using for generating Public and Private Keys:
>
> static unsigned char DH_PRIME_128[] = { /* 128 bit prime */
>   0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
>   0xc9, 0x0f, 0xda, 0xa2, 0x21, 0x68, 0xc2, 0x34 };
>
> static unsigned char dh_g[] = {
>   0x02,
> };

That number is clearly not prime, it is, for a start obviously divisible by 4!  
And of course "2" is then clearly not a generator of the multiplicative group 
of residues that are coprime to it, indeed the group is not cyclic:


https://en.wikipedia.org/wiki/Multiplicative_group_of_integers_modulo_n#Cyclic_case

so it has no generator.

FWIW, the factors of your "prime" are:

4, 31, 2347, 439409, 1327715723, 2004151850481839419

As can be confirmed via:

$ echo '4 31 * 2347 * 439409 * 1327715723 * 2004151850481839419 * 16o p' | 
dc
C90FDAA22168C234

Bottom line you should not expect this "prime" to yield a viable DH group.

--
Viktor.

RE: Issue in DH Algorithm Keys Generation in OpenSSL 3.3.0

[Vishal Kevat via openssl-users]

Hi OpenSSL users,

I am using OpenSSL source version 3.3.0 and facing an issue in key generation 
part of Diffie Hellman (DH) Algorithm. Below are the APIs I am using for 
generating Public and Private Keys:

static unsigned char DH_PRIME_128[] = { /* 128 bit prime */
  0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
  0xc9, 0x0f, 0xda, 0xa2, 0x21, 0x68, 0xc2, 0x34
};

static unsigned char dh_g[] = {
  0x02,
};

dhContext->handle = DH_new(); // Allocate DH Context

BIGNUM *dhp_bn, *dhg_bn;

dhp_bn = BN_bin2bn(DH_PRIME_128, sizeof(DH_PRIME_128), NULL);
dhg_bn = BN_bin2bn(dh_g, sizeof(dh_g), NULL);
DH_set0_pqg(dhContext->handle, dhp_bn, NULL, dhg_bn)

int ret = DH_generate_key(dhContext->handle);  // Generate DH Pub and Priv keys

const BIGNUM* pub_key = DH_get0_pub_key(dhContext->handle);
const BIGNUM* pri_key = DH_get0_priv_key(dhContext->handle);


When I set the prime number DH_PRIME_128 as above, the API DH_generate_key() is 
failing to generate the Public and Private Keys and returning 0.
Using the above prime number Mocana Crypto Library is able to generate the DH 
Pub and Priv keys but OpenSSL is failing to do so.



When I use the below prime number instead:
static unsigned char DH_PRIME_128[] = { /* 128 bit prime */
  0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
  0x34, 0xC2, 0x68, 0x21, 0xA2, 0xDA, 0x0F, 0xC9
};

The DH_generate_key() API is successfully able to generate the keys.

Please let me know, what is the reason of this failing API when I use the first 
prime number for DH algorithm key generation or I am doing wrong anything here?

Regards,
Vishal Kevat




General

RE: New OpenSSL Releases

[Michael Wojcik via openssl-users]

> 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), but anyone running on AIX is 
running big-endian POWER. We have multiple product lines that run on AIX. That 
said, we're typically only looking at the current LTS release.

IBM i would be big-endian POWER too, but I don't know off the top of my head if 
OpenSSL 3 even has a configuration stanza for i.

--
Michael Wojcik

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.

Re: New OpenSSL Releases

[Dennis Clarke via openssl-users]

On 5/30/24 03:03, Tomas Mraz wrote:

You can just test the HEAD commits in the respective branches (openssl-
3.0, openssl-3.1, openssl-3.2 and openssl-3.3) in git. The repository
will be frozen today afternoon so there should be no further changes
apart from eventual regression fixes and the release commits.



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.


--
--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken

Re: New OpenSSL Releases

[Dennis Clarke via openssl-users]

On 5/28/24 08:51, Tomas Mraz wrote:

The OpenSSL project team would like to announce the upcoming release of
OpenSSL versions 3.3.1, 3.2.2, 3.1.6 and 3.0.14.



Will there be any release candidate tarballs for testing on various
systems?  Perhaps there already exists some commit or "tag" ( whatever
you want to call it ) in git ?



--
--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken

Re: Blocking on a non-blocking socket?

[Wiebe Cazemier via openssl-users]

Hi Detlef,

- Original Message -
> From: "Detlef Vollmann" 
> To: openssl-users@openssl.org
> Sent: Friday, 24 May, 2024 12:02:37
> Subject: Re: Blocking on a non-blocking socket?
> 
> That's correct, but if I understand Matt correctly, this isn't the case.
> The idea of SSL_MODE_AUTO_RETRY is that if there's data, but it isn't
> application data but some kind of handshake data, then SSL_read doesn't
> return (after handling the handshake data), but immediately retries.
> If this retry fails with EWOULDBLOCK (or actually BIO_read returns 0),
> then SSL_read returns with 0 and SSL_WANT_READ.

Wouldn't the option then have to be called 'read more than one record at a 
time'? To me, 'retry' is a bit of a misnomer in that description.

Tracing the code, the retry seems to be considered based on 
BIO_fd_non_fatal_error(), which looks at EWOULDBLOCK. See [1] and [2].

Wiebe


[1] 
https://github.com/openssl/openssl/blob/b9e084f139c53ce133e66aba2f523c680141c0e6/crypto/bio/bss_fd.c#L226
[2] 
https://github.com/openssl/openssl/blob/b9e084f139c53ce133e66aba2f523c680141c0e6/crypto/bio/bss_fd.c#L113

Re: Blocking on a non-blocking socket?

[Wiebe Cazemier via openssl-users]

Hi Matt,

- Original Message -
> From: "Matt Caswell" 
> To: openssl-users@openssl.org
> Sent: Friday, 24 May, 2024 00:26:28
> Subject: Re: Blocking on a non-blocking socket?

> Not quite.
> 
> When you call SSL_read() it is because you are hoping to read
> application data.
> 
> OpenSSL will go ahead and attempt to read a record from the socket. If
> there is no data (and you are using a non-blocking socket), or only a
> partial record available then the SSL_read() call will fail and indicate
> SSL_ERROR_WANT_READ.
> 
> If a full record is available it will process it. If the record contains
> application data then the SSL_read() call will return successfully and
> provide the application data to the application.
> 
> If the record contains non-application data (i.e. some TLS protocol
> message like a key update, or new session ticket) then, with
> SSL_MODE_AUTO_RETRY on it will automatically try and read another record
> (and the above process repeats). 

Can you show me in the code where that is? It seems the callers of BIO_read() 
[1] are responsible for doing the retry, because the reader functions abort 
when retry is set. Those are many callers, for x509, evp, b64, etc. But, the 
code is kind of hard to trace, because it's all calls to bio_method_st.bread 
function pointers.

My main concern is, if it would get an EWOULDBLOCK, there is (almost) no sense 
in retrying because in the 100 microseconds or so that passed, there is likely 
still no data. Plus, is there a limit on how often it's retried? If the 
connection is broken (packet loss, so nobody is aware) in the middle of 
rekeying, it can retry all it wants, but nothing will ever come. If it does 
that, then at some point, reads on the socket would fail with ETIMEDOUT, which 
is what I'm seeing.


[1] 
https://github.com/openssl/openssl/blob/b9e084f139c53ce133e66aba2f523c680141c0e6/crypto/bio/bio_lib.c#L303

Re: Blocking on a non-blocking socket?

[Wiebe Cazemier via openssl-users]

Hi Neil,

- Original Message -
> From: "Neil Horman" 
> To: "Wiebe Cazemier" 
> Cc: "udhayakumar" , openssl-users@openssl.org
> Sent: Thursday, 23 May, 2024 23:42:18
> Subject: Re: Blocking on a non-blocking socket?

> from:
> [ https://www.openssl.org/docs/man1.0.2/man3/SSL_CTX_set_mode.html |
> https://www.openssl.org/docs/man1.0.2/man3/SSL_CTX_set_mode.html ]

> SSL_MODE_AUTO_RETRY in non-blocking mode should cause SSL_reaa/SSL_write to
> return -1 with an error code of WANT_READ/WANT_WRITE until such time as the
> re-negotiation has completed. I need to confirm thats the case in the code, 
> but
> it seems to be. If the underlying socket is in non-blocking mode, there should
> be no way for calls to block in SSL_read/SSL_write on the socket read/write
> system call.

I still don't really see what the difference is between SSL_MODE_AUTO_RETRY on 
or off in non-blocking mode?

The person at [1] seems to have had a similar issue, and was convinced clearing 
SSL_MODE_AUTO_RETRY fixed it. But I agree, I don't know how it could be. 
OpenSSL would have to remove the O_NONBLOCK, or do select/poll, and I can't 
find it doing that.

I hope it happens again soon and I'm around to attach a debugger.

Regards,

Wiebe


[1] https://github.com/alanxz/rabbitmq-c/issues/586

Re: Blocking on a non-blocking socket?

[Wiebe Cazemier via openssl-users]

- Original Message -
> From: "Neil Horman" 
> To: "udhayakumar" 
> Cc: "Wiebe Cazemier" , openssl-users@openssl.org
> Sent: Thursday, 23 May, 2024 22:05:22
> Subject: Re: Blocking on a non-blocking socket?

> do you have a stack trace of the thread hung in this state? That would confirm
> whats going on here
> Neil

Hi Neil, 

No, I don't. I wasn't there to attach a debugger. It recovered before I could 
do that. And despite a lot of effort, I can't reproduce it either.

But in general, what does SSL_MODE_AUTO_RETRY on/off change in non-blocking 
mode? The documentation is too vague for me. It says:

> Setting SSL_MODE_AUTO_RETRY for a nonblocking BIO will process 
> non-application data records until either no more data is available or an 
> application data record has been processed.

But how is that different from disabling SSL_MODE_AUTO_RETRY?

Regards,

Wiebe

Blocking on a non-blocking socket?

[Wiebe Cazemier via openssl-users]

Hi List,

I have a very obscure problem with an application using O_NONBLOCK still 
blocking. Over the course of a year of running with hundreds of thousands of 
clients, it has happened twice over the last month that a worker thread froze. 
It's a long story, but I'm pretty sure it's not a deadlock or spinning event 
loop or something, primarily because the application recovers after about 20 
minutes with a client errorring out with ETIMEDOUT. Coincidentally, that 20 
minutes matches the timeout description of the tcp man page [1].

It really looks like a non-blocking socket is still blocking. I found something 
with a similar problem ([2]), but what they think of SSL_MODE_AUTO_RETRY does 
not match the documentation.

So, is there indeed any way an application that has SSL_MODE_AUTO_RETRY on 
(which is default since 1.1.1) can block? Looking at the source code, I don't 
see any calls to fcntl() that removes the O_NONBLOCK.

My IO method is SSL_read() and SSL_write() with an SSL object given to 
SSL_set_fd().

The only SSL modes I change from the default is that I set 
SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER. 

There are two primary deployments of this application, one with OpenSSL 1.1.1 
and one with 3.0.0. Only 1.1.1 has shown this problem, but it may be a 
coincidence.

Side question, is it a problem to set SSL_set_fd() before using fcntl to set 
the fd to O_NONBLOCK? I ask, because the docs say "The BIO and hence the SSL 
engine inherit the behaviour of fd. If fd is non-blocking, the ssl will also 
have non-blocking behaviour.". The 'inherit' may be a key word here; not sure 
when it's done.

Regards,

Wiebe Cazemier



[1] https://man7.org/linux/man-pages/man7/tcp.7.html
[2] https://github.com/alanxz/rabbitmq-c/issues/586

Trouble decoding key in provider

[Bernd Ritter via openssl-users]

Hi there,

I am trying to implement a provider. The decoder successfull decodes the 
key (it is using an ED25519 key with a custom OID -> hence the provider).


Currently I am facing two problems:

1. the PEM decoding is ignored unless I comment out the DER decoding part

The private key is packaged in a pkcs#8 format. This seems to be 
decodable from PEM, but only if I comment out the DER part. This does 
not leave me confident my code is correct.


static const OSSL_ALGORITHM ed25519ph_decoder_dispatch[] = {
 {"ed25519-my:1.2.3.4", "provider=my,input=pem,structure=pkcs8", 
dispatch_decoder_my_ed25519_private_der, PROV_DESCS_ED25519},

 {ed25519-my:1.2.3.4", "provider=my,input=der", , PROV_DESCS_ED25519},
 {NULL, NULL, NULL, NULL}};

Both parts work each. Maybe someone can enlighten me here :-)

2. the DER part works as well. I can extract the exact key I've created 
in the keygen part before. But despite my efforts to find the correct 
export mechanism by trail and error and reading through all the provider 
implementation I've found in the provider corner and in the internet, 
some thing is still missing here. After reading out the key, I does not 
seem to be available:
 PROVIDER: 
making public key from example-priv.pem

0:d=0  hl=2 l=  46 cons: SEQUENCE
2:d=1  hl=2 l=   1 prim: INTEGER   :00
5:d=1  hl=2 l=   5 cons: SEQUENCE
7:d=2  hl=2 l=   3 prim: OBJECT:1.2.3.4
   12:d=1  hl=2 l=  34 prim: OCTET STRING  [HEX 
DUMP]:0420E2F448C53E58A6233CBFD306D62B2875EE175F3A88C20DCA7C4DF0BE945F192F

ed25519ph provider init...
registered  oids
new  provider context
ed25519ph provider init complete
operating switch: 22 (10=KEYMGMT, 12=SIG, 20=ENC, 21=DEC, 22=STOR)
operating switch: 21 (10=KEYMGMT, 12=SIG, 20=ENC, 21=DEC, 22=STOR)
operating switch: 10 (10=KEYMGMT, 12=SIG, 20=ENC, 21=DEC, 22=STOR)
operating switch: 21 (10=KEYMGMT, 12=SIG, 20=ENC, 21=DEC, 22=STOR)
/home/rittebe/Entwicklung/ed25519ph-provider/src/ed25519ph_decoder.c - 
Decoder context new 0x5c304c501a50

operating switch: 21 (10=KEYMGMT, 12=SIG, 20=ENC, 21=DEC, 22=STOR)
src/ed25519ph_decoder.c - Decoder context new 0x5c304c503b60
src/ed25519ph_decoder.c - Decoder decode DER (selection=87) 0x5c304c503b60
PKCS8_pkey_get0
dump with len=34
04 20 e2 f4 48 c5 3e 58 a6 23 3c bf d3 06 d6 2b 28 75 ee 17 5f 3a 88 c2 
0d ca 7c 4d f0 be 94 5f 19 2f

dump done
asn1 octet string. read 34
asn1 octet string len=32
dump with len=32
e2 f4 48 c5 3e 58 a6 23 3c bf d3 06 d6 2b 28 75 ee 17 5f 3a 88 c2 0d ca 
7c 4d f0 be 94 5f 19 2f

dump done
src/ed25519ph_decoder.c - Decoder Export to provider independent params 
format

src/ed25519ph_decoder.c - 32
Private DER decode rc from callback=0, rc=1
src/ed25519ph_decoder.c - Decoder context free 0x5c304c503b60
operating switch: 10 (10=KEYMGMT, 12=SIG, 20=ENC, 21=DEC, 22=STOR)
operating switch: 21 (10=KEYMGMT, 12=SIG, 20=ENC, 21=DEC, 22=STOR)
operating switch: 10 (10=KEYMGMT, 12=SIG, 20=ENC, 21=DEC, 22=STOR)
operating switch: 21 (10=KEYMGMT, 12=SIG, 20=ENC, 21=DEC, 22=STOR)
src/ed25519ph_decoder.c - Decoder context new 0x5c304c5050c0
operating switch: 21 (10=KEYMGMT, 12=SIG, 20=ENC, 21=DEC, 22=STOR)
src/ed25519ph_decoder.c - Decoder context new 0x5c304c507080
src/ed25519ph_decoder.c - Decoder context free 0x5c304c507080
Could not find private key of key from example-priv.pem
800BD7ED6273:error:1608010C:STORE 
routines:ossl_store_handle_load_result:unsupported:crypto/store/store_result.c:151:

src/ed25519ph_decoder.c - Decoder context free 0x5c304c5050c0
src/ed25519ph_decoder.c - Decoder context free 0x5c304c501a50

The first part is from openssl asn1parse to see if the key matches. 
After it is read correctly I get this "could not find private key of key 
from xxx" error.


At the moment I am "exporting" the key from the decoder like this:

OSSL_PARAM params[4];
int object_type = OSSL_OBJECT_PKEY;

params[0] = OSSL_PARAM_construct_int(OSSL_OBJECT_PARAM_TYPE, 
&object_type);
params[1] = 
OSSL_PARAM_construct_utf8_string(OSSL_OBJECT_PARAM_DATA_TYPE, 
(char*)"privkey", 0);
params[2] = 
OSSL_PARAM_construct_octet_string(OSSL_OBJECT_PARAM_DATA, (void*)objref, 
objref_sz);

params[3] = OSSL_PARAM_construct_end();

objref just contains the plain key, which should be usable for import in 
the keymanagement.


Looking for help. Thanks.

Bernd

--
Bernd Ritter
Linux Developer
Tel.: +49 175 534 4534
Mail: rit...@b1-systems.de

B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt, HRB 3537

Re: OpenSSL version 3.3.0 published

[Dennis Clarke via openssl-users]

On 5/16/24 08:28, Neil Horman wrote:

Glad its working a bit better for you.  If you are inclined, please feel
free to open a PR with your changes for review.


Well, the changes are *really* trivial. Necessary and trivial.


--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken

Re: OpenSSL version 3.3.0 published

[Dennis Clarke via openssl-users]

On 5/15/24 18:34, Neil Horman wrote:

You are correct, the files you reference (most of them in fact) get built
into separate objects in the event the build flags are different for shared
and static libraries, and should be unrelated to the issue you are seeing



I was somewhat puzzled by this also. Yes.


As for the undefined symbols, thats definitely a mystery.  most notably,
the symbols referenced are internal.  That is to say they shouldn't be
exported in the symbol table for libssl.so (though a quick look with
objectdump shows they are, which may be a separate issue)

Looking at the sources, I can see what _might_ be happening

cert_comp_tests.c includes "../ssl/ssl_local.h"
if quic is enabled (i.e. OPENSSL_NO_QUIC is undefined), ssl_local.h
includes quic/quic_local.h
quic_local.h includes internal/quic_txp.h
quic_txp.h includes internal/quic_stream_map.h
quic_stream_map.h defines a static inline function
named ossl_quic_stream_recv_get_final_size which calls
ossl_quic_rxfc_get_final_size, which in turn
calls ossl_quic_rxfc_get_final_size

I'm guessing the other symbols have simmilar patterns.



I am still digging into the issue.
I thank you the thoughtful reply.



As to why its happening my first guess would be that more recent compilers
like gcc and clang do lazy symbol resolution, only resolving a subordonate
symbol, when its calling parent is found to be used.  Given
ossl_quic_stream_recv_get_final_size isn't called anywhere in
comp_stream_test.c, the compiler disposes of the symbol prior to any need
to resolve its called symbols, and so everything is ok.



I also suspect a linker issue here and the sad fact is that the GNU
 ld just will not suffice in this server. C'est la vie ici.



conversely (again, I'm guessing here) the solaris 5.10 compiler likely take
a more bulldozer-ish approach, leaving everything in the object file and
only stripping symbols after all resolutions are complete, leading to the
missing symbols error, despite its not being needed.



I have to laugh at the "bulldozer" idea as you are likely quite 
correct there.




As to what to do about this...I'm unsure.  The quick hack I would imagine
would be to move the definition of ossl_quic_stream_recv_get_final_size
into a c file (likely quic_stream_map.c) and just declare a prototype in
the quic_stream_map.h header, so as to avoid the unneeded symbol
resolution.  You would have to lather rinse  repeat with the other missing
symbols of course.

As to your prior question about how long the ability to support SunOS will
last, well, unfortunately I don't think any of us can say.  I believe the
platoform you are building on is on our unadpoted platform list:
https://www.openssl.org/policies/general-supplemental/platforms.html

And while we endeavor to keep openssl building on as many platforms as
possible, its not feasible to cover all the currently
unmaintained platforms.  You do have some agency here however. If you are
willing and interested, you could volunteer to be a community platform
maintainer for your target platform.  This would entail you building
openssl on your adopted platform, and running the test suite routinely,
reporting bugs and fixing errors as they occur.  Its not a small amount of
work, but it would be a significant contribution toward ensuring that
openssl stays viable on the targets you need.


I can tell you that this morning I see :

.
.
.
All tests successful.
Files=312, Tests=3182, 6714 wallclock secs (25.22 usr  3.10 sys + 
6370.32 cusr 170.55 csys = 6569.19 CPU)

Result: PASS
`test' is up to date.

hubble $ pwd
/opt/bw/build/openssl-3.3.0_SunOS_5.10_SPARC64.005

hubble $
hubble $ psrinfo -pv
The physical processor has 8 virtual processors (0-7)
  SPARC64-VII+ (portid 1024 impl 0x7 ver 0xa1 clock 2860 MHz)
hubble $
hubble $ uname -a
SunOS hubble 5.10 Generic_150400-67 sun4u sparc SUNW,SPARC-Enterprise
hubble $

hubble $ hash -r
hubble $ which openssl
/opt/bw/bin/openssl
hubble $

hubble $ ldd /opt/bw/bin/openssl
libssl.so.3 =>   /opt/bw/lib/libssl.so.3
libcrypto.so.3 =>/opt/bw/lib/libcrypto.so.3
libsocket.so.1 =>/lib/64/libsocket.so.1
libnsl.so.1 =>   /lib/64/libnsl.so.1
libdl.so.1 =>/lib/64/libdl.so.1
librt.so.1 =>/lib/64/librt.so.1
libstatomic.so.1 =>  /opt/bw/lib/libstatomic.so.1
libc.so.1 => /lib/64/libc.so.1
libmp.so.2 =>/lib/64/libmp.so.2
libmd.so.1 =>/lib/64/libmd.so.1
libscf.so.1 =>   /lib/64/libscf.so.1
libaio.so.1 =>   /lib/64/libaio.so.1
libdoor.so.1 =>  /lib/64/libdoor.so.1
libuutil.so.1 => /lib/64/libuutil.so.1
libgen.so.1 =>   /lib/64/libgen.so.1
libm.so.2 => /lib/64/libm.so.2
/lib/sparcv9/../libm/sparcv9/libm_hwcap1.so.2
    /platform/SUNW,SPARC-Enterprise/lib/sparc

Re: OpenSSL version 3.3.0 published

[Dennis Clarke via openssl-users]

On 5/13/24 03:34, Matt Caswell wrote:



On 13/05/2024 02:42, Neil Horman wrote:
We added support for RCU locks in 3.3 which required the use of 
atomics (or emulated atomic where they couldn't be supported), but 
those were in libcrypro not liberal




Right - its supposed to fallback to emulated atomic calls where atomics 
aren't available on a particular platform.


Some platforms have some atomics support but you have to link in a 
separate atomics library to get it to work. You might try adding 
"-latomic" to Configure command line and see if that helps at all.



Well first the good news : managed to get past the need for C11 atomics
with the bundled libatomic.so.1 that the Oracle people provide in the
dev tools.

 So that works now.  Yay.

Now comes the next horrible hurdle to jump and that seems to be called
the quic protocol goodness.  For the record I am able to get a good
result if I go with "no-quic" in the config :

hubble $ $PERL ./Configure solaris64-sparcv9-cc \
> --prefix=/opt/bw no-asm no-engine shared zlib-dynamic \
> no-quic enable-weak-ssl-ciphers -DPEDANTIC 2>&1
Configuring OpenSSL version 3.3.0 for target solaris64-sparcv9-cc
Using os-specific seed configuration
Created configdata.pm
Running configdata.pm
Created Makefile.in
Created Makefile
Created include/openssl/configuration.h

**
***        ***
***   OpenSSL has been successfully configured ***
******
***   If you encounter a problem while building, please open an***
***   issue on GitHub <https://github.com/openssl/openssl/issues>  ***
***   and include the output from the following command:   ***
******
***   perl configdata.pm --dump***
***    ***
***   (If you are new to OpenSSL, you might want to consult the***
***   'Troubleshooting' section in the INSTALL.md file first)  ***
******
**
hubble $


That all builds neatly on this old platform and all the testsuite looks
to be sweet :

.
.
.
All tests successful.
Files=312, Tests=3182, 6723 wallclock secs (25.17 usr  3.15 sys + 
6375.57 cusr 171.52 csys = 6575.41 CPU)

Result: PASS
`test' is up to date.

So that is cute.

However, if I leave in the "quic"-ness then I eventually land on this
weird linking problem :

Undefined   first referenced
 symbol in file
ossl_quic_rxfc_get_final_size   test/cert_comp_test-bin-cert_comp_test.o
ossl_quic_sstream_get_final_sizetest/cert_comp_test-bin-cert_comp_test.o
ossl_quic_vlint_decode_uncheckedtest/cert_comp_test-bin-cert_comp_test.o
ld: fatal: symbol referencing errors. No output written to 
test/cert_comp_test

*** Error code 2
make: Fatal error: Command failed for target `test/cert_comp_test'
Current working directory /opt/bw/build/openssl-3.3.0_SunOS_5.10_SPARC64.004
*** Error code 1
make: Fatal error: Command failed for target `build_sw'

These files refer to the above symbols :

1) headers
-rw-r--r--   1 dclarke  devl4670 Apr  9 12:12 
./include/internal/packet_quic.h
-rw-r--r--   1 dclarke  devl   10769 Apr  9 12:12 
./include/internal/quic_fc.h
-rw-r--r--   1 dclarke  devl   17692 Apr  9 12:12 
./include/internal/quic_stream.h
-rw-r--r--   1 dclarke  devl   34987 Apr  9 12:12 
./include/internal/quic_stream_map.h
-rw-r--r--   1 dclarke  devl4212 Apr  9 12:12 
./include/internal/quic_vlint.h


2) C sources
-rw-r--r--   1 dclarke  devl2060 Apr  9 12:12 ./crypto/quic_vlint.c
-rw-r--r--   1 dclarke  devl  121348 Apr  9 12:12 ./ssl/quic/quic_impl.c
-rw-r--r--   1 dclarke  devl   12010 Apr  9 12:12 
./ssl/quic/quic_sstream.c
-rw-r--r--   1 dclarke  devl   26592 Apr  9 12:12 
./ssl/quic/quic_stream_map.c
-rw-r--r--   1 dclarke  devl   17658 Apr  9 12:12 
./ssl/quic/quic_tserver.c

-rw-r--r--   1 dclarke  devl  114209 Apr  9 12:12 ./ssl/quic/quic_txp.c

Looking into my compile logs I see that quic_vlint.c gets processed into
three output objects :

{CC foo} -c -o crypto/libcrypto-lib-quic_vlint.o   crypto/quic_vlint.c
{CC foo} -c -o crypto/libcrypto-shlib-quic_vlint.o crypto/quic_vlint.c
{CC foo} -c -o crypto/libssl-shlib-quic_vlint.ocrypto/quic_vlint.c

I see that quic_impl.c gets processed into two output objects :

{CC foo} -c -o ssl/quic/libssl-lib-quic_impl.o ssl/quic/quic_impl.c
{CC foo} -c -o ssl/quic/libssl-shlib-quic_impl.o   ssl/quic/quic_impl.c


Similarly we see that quic_sstream.c res

Re: OpenSSL version 3.3.0 published

[Dennis Clarke via openssl-users]

On 5/12/24 21:42, Neil Horman wrote:

We added support for RCU locks in 3.3 which required the use of atomics (or
emulated atomic where they couldn't be supported), but those were in
libcrypro not liberal



I see. I am having great difficulty with 3.3 on an old Sun SPARC64
server where there really is not any libatomic support. Well, there is
sort of but it is a hack. Given how portable the code is there must be a
configuration option somewhere to disable the need for those atomic ops.

Meanwhile, OpenSSL 3.0.x builds and tests flawlessly but ... how
long will that last?


--
--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken

Re: OpenSSL version 3.3.0 published

[Dennis Clarke via openssl-users]

On 4/9/24 08:56, OpenSSL wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


OpenSSL version 3.3.0 released
==




Trying to compile this on an old Solaris 10 machine and over and over 
and over I see these strange things as Undefined symbols :


Undefined   first referenced
 symbol in file
__atomic_store_4./libssl.so
__atomic_fetch_add_4./libssl.so
__atomic_fetch_sub_4./libssl.so
atomic_thread_fence ./libssl.so
__atomic_load_4 ./libssl.so
ld: fatal: symbol referencing errors. No output written to apps/openssl
gmake[1]: *** [Makefile:12601: apps/openssl] Error 2
gmake[1]: Leaving directory 
'/opt/bw/build/openssl-3.3.0_SunOS_5.10_SPARC64.002'

gmake: *** [Makefile:1978: build_sw] Error 2


Those look like strange C11 atomics. Are they really needed somewhere?

I see include/internal/refcount.h talks about C11 atomics and yet the
entire code base is supposed to be C90 clean.  See section the OpenSSL
Coding Style policy :

https://www.openssl.org/policies/technical/coding-style.html

Chapter 14: Portability

To maximise portability the version of C defined in
ISO/IEC 9899:1990 should be used. This is more commonly
referred to as C90. ISO/IEC 9899:1999 (also known as C99) is
not supported on some platforms that OpenSSL is used on and
therefore should be avoided.


Perhaps I need to define OPENSSL_DEV_NO_ATOMICS ?


Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken

Re: goto out not working in tests

[The Doctor via openssl-users]

On Mon, May 06, 2024 at 11:34:59PM -0600, The Doctor via openssl-users wrote:
> Using clang versino 18
> 
> and it is spewing at goto out 
> 

Line 417 and 434 of test/threadstest.c

in openssl-3.3 daily

-- 
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 ;

goto out not working in tests

[The Doctor via openssl-users]

Using clang versino 18

and it is spewing at goto out 

-- 
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 ;

RE: Open SSL 1.1.1 and Vxworks 5.4.2 - Query on Entropy source

[Prithvi Raj R (Nokia) via openssl-users]

Users,

An update here: See that we have OPENSSL_RAND_SEED_OS  defined on our VxWorks 
based system. Would it be a trusted entropy source ? The default for VxWorks 
seems to be OPENSSL_RAND_SEED_NONE.

Thanks,
Prithvi
From: Prithvi Raj R (Nokia)
Sent: Tuesday, April 30, 2024 12:47 AM
To: openssl-users@openssl.org
Subject: Open SSL 1.1.1 and Vxworks 5.4.2 - Query on Entropy source

Hi Users,

A beginner on cryptography and Open SSL here.

First query - On our VxWorks 5.4.2 based system with Open SSL 1.1.1, I would 
like to know what entropy source would be used by RAND_priv_bytes() to generate 
random numbers. Does Vxworks not use an OS based entropy source ?  I see so in 
the openssl link: 
https://mta.openssl.org/pipermail/openssl-users/2020-March/012087.html.
In our implementation, we have the OPENSSL_RAND_SEED_NONE macro definition 
commented in the opensslconf.h file. What would be the default entropy source 
then if OS based sources are not used ? Which Open SSL config file/compile 
parameter can help me zero in on the correct entropy source being used ?  
Wanted to know if the source is a trusted one or not. See that 
rand_drbg_get_entropy is being used (no parent drbg ;_rand_pool_acquire_entropy 
is used with entropy factor 2 being set) and entropy available is greater than 
0.

Second query - Please confirm if the following are valid:

  1.  Understand the Entropy size by default is 256 bits.
  2.  Understand that RAND_priv_bytes() is cryptographically secure (depends on 
the entropy source again ?)

Thanks,
Prithvi

Invalid code generated by GCC on 32-bit x86 in gcm128.c

[Michael Wojcik via openssl-users]

We recently debugged, and found a workaround for, a GCC [###version] 
code-generation error when compiling OpenSSL 3.0.8 for 32-bit on Intel x86. 
This error resulted in a use of a misaligned memory operand with a 
packed-quadword instruction, producing a SIGSEGV on RedHat 8. (I'm a bit 
surprised Linux doesn't raise SIGBUS for this particular trap, but whatever.) I 
wanted to document this here in case other people run into it.

Aside: This does raise the question: Why aren't other people running into it? 
And why are we only seeing it now? Honestly, I don't know. It is sensitive to 
stack layout, but in some of our tests we could reproduce it consistently. It's 
possible you'll never see this in a program where the path into the sensitive 
functions in gcm128.c, which appear to be CRYPTO_gcm128_aad, 
CRYPTO_gcm128_encrypt, and CRYPTO_gcm128_decrypt, is made up completely of code 
compiled with GCC. In our case we have non-GCC code along that path in some 
cases, and that non-GCC code does not follow GCC's rather arbitrary stack-frame 
alignment rules for x86, so GCC may be making an invalid assumption about 
callers further up the stack and how they'll pad and align stack frames.

(It's known that with default build flags and optimization, GCC requires that 
callers align *parameters* strictly, because it may generate SSE code for 
operations on 64-bit and larger operations. But the problem here isn't a 
parameter, as I'll show in a moment.)

Anyway, back to the issue.

The affected functions declare a 64-bit integer object with automatic storage 
class:

u64 alen = ctx->len.u[0];

and then operate on it:

alen += len;

GCC, under appropriate conditions, generates code that performs a 
packed-quadword operation (specifically a PADDQ) with alen as the destination. 
That requires alen have 64-bit alignment. However, the generated code puts alen 
on a 32-bit boundary; examining its address before the trap occurs confirms it 
ends with 0x8.

The fix we're using is to add -mstackrealign to the build flags for OpenSSL on 
GCC x86 platforms. That adds prologue code to each function which checks the 
stack alignment at runtime and fixes it if necessary. Unfortunately this does 
mean some performance cost, obviously, which we have not yet tried to measure.

After quite a bit of investigation, we're fairly confident we'd call this a GCC 
bug. It looks like a consequence of the "fix" for GCC bug 65105, which was made 
a couple of years ago, to use XMM registers in 32-bit generated code on x86. 
GCC has an unfortunate history of assuming stronger stack-alignment rules on 
this platform than are required by the ISA or enforced by other languages and 
compilers, and some members of the GCC team are a bit notorious for their ... 
enthusiasm ... in justifying this position.

We have not yet attempted to raise this as a GCC bug, because, well, I've read 
those discussions in the GCC forums.

-- 
Michael Wojcik

Re: [External] : Re: BIO_read() crash

[Benjamin Kaduk via openssl-users]

On Mon, Dec 05, 2022 at 11:31:18AM -0800, Thomas Dwyer III wrote:
> Why does EVP_get_digestbyname("md4") return non-NULL if the legacy provider
> isn't loaded? Similarly, why does it return non-NULL for "md5" after doing
> EVP_set_default_properties(NULL, "fips=yes")? This seems unintuitive. Legacy
> code that does not know about EVP_MD_fetch() checks the return value of
> EVP_get_digestbyname(). Isn't that where the error should be detected? Why
> let it get all the way to BIO_set_md() (or EVP_DigestInit() or whatever)
> before the error is detected?

To do so would introduce a time-of-check/time-of-use race, as the set of
providers available may change in the intervening period.

-Ben

OpenSSL version 3.1.0-alpha1 published

[OpenSSL]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


   OpenSSL version 3.1 alpha 1 released
   

   OpenSSL - The Open Source toolkit for SSL/TLS
   https://www.openssl.org/

   OpenSSL 3.1 is currently in alpha.

   OpenSSL 3.1 alpha 1 has now been made available.

   Note: This OpenSSL pre-release has been provided for testing ONLY.
   It should NOT be used for security critical purposes.

   Specific notes on upgrading to OpenSSL 3.1 from previous versions are
   available in the OpenSSL Migration Guide, here:

https://www.openssl.org/docs/man3.0/man7/migration_guide.html

   The alpha release is available for download via HTTPS and FTP from the
   following master locations (you can find the various FTP mirrors under
   https://www.openssl.org/source/mirror.html):

 * https://www.openssl.org/source/
 * ftp://ftp.openssl.org/source/

   The distribution file name is:

o openssl-3.1.0-alpha1.tar.gz
  Size: 15343477
  SHA1 checksum:  91a7cbcb761c4bb8a460899bccddcbd5d047d3c3
  SHA256 checksum:  
ef10f70023f4e3f701c434db0b4b0c8cfea1e1e473a0eb3c9ccbc5c54f5f5566

   The checksums were calculated using the following commands:

openssl sha1 openssl-3.1.0-alpha1.tar.gz
openssl sha256 openssl-3.1.0-alpha1.tar.gz

   Please download and check this alpha release as soon as possible.
   To report a bug, open an issue on GitHub:

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

   Please check the release notes and mailing lists to avoid duplicate
   reports of known issues. (Of course, the source is also available
   on GitHub.)

   Yours,

   The OpenSSL Project Team.

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEE3HAyZir4heL0fyQ/UnRmohynnm0FAmOIqpASHHRvbWFzQG9w
ZW5zc2wub3JnAAoJEFJ0ZqIcp55tWrIQAJHT40JekEs3DacHjQrTmGLc56TmzaFD
oDp8Md2E0RpX/vuANdIVGB89zGQMag13TPa9CzT1yk7wFBilPoiuapolmo8N0nvF
OnMLIQjF+sbsQN0gqchuMKKD98omc1ZNNcijq/GlKM9wH6ey1uHnFAi2aXF4f6ai
2SviauJvHQDgDOe9tFfA5lDF1EdYZt20D46Yc+yJf/zr4MJZFcX2T2qmo+oew6VA
djZ+cRPeeNmRXrl5Banqpfcy2iH4N57wvEcM4dtGaGY+4Pwr0H9XN6MxfamGUbLv
oSySdFpTagPENPGDBPoRilPSXdapCD5m8Xd2FERM1HF5E1GaemqaQKUYiXbANqL/
SDBftayilhYf+tXg3/22xksZVEkEjFD79M0mj75dn+UgQilOTR/AOdup2imTB7PG
7Cgq2HGz93ppO3kG0iuTS5uc95Gfu9AfkjgfcydA2eZf+rmHAoocm8kpThdxD/a5
avpMudgklyXysmO+2MJ16806Sa27L8N52YTPzy4Zthx/SLR/RA//bXBnlSlguRGw
7+hIDPncmaCfegaI65yq/TgtU9z/OLhNTPmYaUQi3IFtsCrAahZNVYg8qZtnMtgC
iaVYQkNZsqE0wSDalgJANJkZUa8VHdh2O3sOBSYbZvHWEiYJJ+9ATgLSLDjiGq0e
l9cvtybysQsx
=upN5
-END PGP SIGNATURE-

Re: Upgrading OpenSSL on Windows 10

[Michael Wojcik via openssl-users]

​​> From: Steven_M.irc 
> Sent: Thursday, November 24, 2022 21:21

> > This is not true in the general case. There are applications which are 
> > available on Linux which do not use the
> > distribution's package manager. There are applications which use their own 
> > OpenSSL build, possibly linked
> > statically or linked into one of their own shared objects or with the 
> > OpenSSL shared objects renamed. Linux
> > distributions have not magically solved the problem of keeping all software 
> > on the system current.

> That's disheartening. My next computer will be running Linux and I was 
> thinking that (as long as I stick to
> installing software from appropriate repositories) my update worries would be 
> over soon.

That's the state of general-purpose software development. Believe me, having 
software automatically updated would by no means solve the most pressing 
security issues in the current software industry.
 
> > It is possible, with relatively little effort, to find all the copies of 
> > the OpenSSL DLLs under their usual names on a system

> Could you please provide me with a list of the usual names?

At the moment I'm not in a position to do that, and it wouldn't achieve 
anything useful anyway.

> I've got a lot of libssl DLL's on my system, but I'm not sure if they're part 
> of OpenSSL or some other implementation
> of SSL.

Filenames wouldn't prove anything anyway.

> >I'm not sure OpenSSL versions should be particularly high on anyone's 
> >priority list.

> As I understand it, OpenSSL is responsible for establishing HTTPS 
> connections, the primary protocol
> for ensuring security and authenticity over the Internet, and you *don't* 
> think OpenSSL versions should
> be a high priority? I don't understand your lack of alarm here.

I'm not alarmed because I'm operating under a sensible threat model.

What vulnerabilities are you concerned about? Why? What versions of OpenSSL do 
those apply to? Being "alarmed" without being able to answer those questions 
just means you're shooting in the dark.

Frankly, after 2012 -- the year that brought us Heartbleed, Goto Fail, and 
severe vulnerabilities in most major TLS implementations -- there have been few 
published vulnerabilities of much concern to client-side TLS use, and most of 
those only apply to very high-value targets. TLS connections are not the 
low-hanging fruit. Attackers have much better return and much lower cost 
exploiting other vulnerabilities, including on the user side phishing and other 
social-engineering attacks, typosquatting, credential stuffing, and so on. On 
the service-provider side, software supply-chain attacks and poor 
organizational defenses are common threat vectors.

Very few people will bother attacking HTTPS at the protocol level. It's not 
worth the effort.

> >What are you actually trying to accomplish? What's your task? Your threat 
> >model?

> I want to be able to trust the HTTPS connections between my PC and servers on 
> the Internet again;

"Again" since when? "Trust" in what sense? "Trust", like "secure", doesn't mean 
anything useful in an absolute sense. It's only meaningful in the context of a 
threat model.

For a typical computer user, TLS implementations is the wrong thing to worry 
about. Most home and employee individual users who are successfully attacked 
will fall victim to some sort of social engineering, such as phishing; to poor 
personal security practices such as weak passwords or password reuse; or to a 
server-side compromise they have absolutely no control over. Some will be 
compromised due to a failure to install updates to the OS or major software 
packages such as Microsoft Office long after those updates are released, but 
that's a less-common vector.

HTTPS compromise is statistically insignificant. In the vast majority of cases, 
the dangers with HTTPS are what people use it for -- online shopping at sites 
with poor security, for example, or downloading malicious software -- not with 
the channel itself.

-- 
Michael Wojcik

RE: Upgrading OpenSSL on Windows 10

[Steven_M.irc via openssl-users]

Hi Job,
Thanks very much for your reply. Apologies for the lateness of mine.

I will ask around and get more information about Powershell and PDQ Inventory.

Thanks again,
Steven




Sent with Proton Mail secure email.

--- Original Message ---
On Wednesday, November 23rd, 2022 at 5:36 AM, Job Cacka  wrote:


> Michael's point should be asked and answered first for your environment.
> 
> To find all of the OpenSSL bits used on a windows system you would use
> Powershell or a tool that flexes its use like PDQ Inventory. There is a
> steep learning curve and it is probably off topic for this group but there
> are several different ways to use powershell to gain this information from
> different viewpoints (Installed files, registry, event log, etc...).
> 
> Thanks,
> Job
> 
> -Original Message-
> From: openssl-users openssl-users-boun...@openssl.org On Behalf Of Michael
> 
> Wojcik via openssl-users
> Sent: Monday, November 21, 2022 4:18 PM
> To: openssl-users@openssl.org
> Subject: Re: Upgrading OpenSSL on Windows 10
> 
> > From: openssl-users openssl-users-boun...@openssl.org on behalf of
> > Steven_M.irc via openssl-users openssl-users@openssl.org
> > Sent: Monday, November 21, 2022 15:56
> 
> > However, I am running Windows 10, and since (unlike Linux) every piece
> > of software outside of Windows itself needs to be updated
> > individually, I don't know how to track down every single application that
> 
> might be using OpenSSL and make sure that the copy of OpenSSL it uses is
> up-to-date.
> 
> You don't. There may be applications that have OpenSSL linked statically, or
> linked into one of its own DLLs, or just with the OpenSSL DLLs renamed.
> 
> > As many of you would know, under repository-based systems (such as
> > most Linux distros), this would not be an issue as I could update every
> 
> single application (system or non-system) at once.
> 
> This is not true in the general case. There are applications which are
> available on Linux which do not use the distribution's package manager.
> There are applications which use their own OpenSSL build, possibly linked
> statically or linked into one of their own shared objects or with the
> OpenSSL shared objects renamed. Linux distributions have not magically
> solved the problem of keeping all software on the system current.
> 
> 
> Back to Windows: It is possible, with relatively little effort, to find all
> the copies of the OpenSSL DLLs under their usual names on a system, and then
> glean from them their version information. With significantly more effort,
> you can search for exported OpenSSL symbols within third-party binaries,
> which will detect some more instances. With quite a lot of additional
> effort, you can winkle out binaries which contain significant portions of
> code matching some OpenSSL release (see various research efforts on
> function-point and code-block matching, and compare with alignment
> strategies in other fields, such as genomics). If your definition of
> "OpenSSL in an application" is not too ambitious, this might even be
> feasible.
> 
> But to what end? Each application will either be well-supported, in which
> case you can find out from the vendor what OpenSSL version it contains and
> whether an update is available; or it is not, in which you'll be out of
> luck.
> 
> This is true of essentially every software component, most of which are not
> as well-maintained or monitored as OpenSSL. Modern software development is
> mostly a haphazard hodgepodge of accumulating software of uncertain
> provenance and little trustworthiness into enormous systems with
> unpredictable behavior and failure modes. I'm not sure OpenSSL versions
> should be particularly high on anyone's priority list.
> 
> What are you actually trying to accomplish? What's your task? Your threat
> model?
> 
> --
> Michael Wojcik

Re: Upgrading OpenSSL on Windows 10

[Steven_M.irc via openssl-users]

Hi Michael,
Thanks very much for replying to my e-mail/post. I apologize for the lateness 
of my reply.

> This is not true in the general case. There are applications which are 
> available on Linux which do not use the distribution's package manager. There 
> are applications which use their own OpenSSL build, possibly linked 
> statically or linked into one of their own shared objects or with the OpenSSL 
> shared objects renamed. Linux distributions have not magically solved the 
> problem of keeping all software on the system current.

That's disheartening. My next computer will be running Linux and I was thinking 
that (as long as I stick to installing software from appropriate repositories) 
my update worries would be over soon.
 
>It is possible, with relatively little effort, to find all the copies of the 
>OpenSSL DLLs under their usual names on a system

Could you please provide me with a list of the usual names? I've got a lot of 
libssl DLL's on my system, but I'm not sure if they're part of OpenSSL or some 
other implementation of SSL.

>I'm not sure OpenSSL versions should be particularly high on anyone's priority 
>list.

As I understand it, OpenSSL is responsible for establishing HTTPS connections, 
the primary protocol for ensuring security and authenticity over the Internet, 
and you *don't* think OpenSSL versions should be a high priority? I don't 
understand your lack of alarm here.

>What are you actually trying to accomplish? What's your task? Your threat 
>model?

I want to be able to trust the HTTPS connections between my PC and servers on 
the Internet again; whether I'm using a browser, a software installer (that 
downloads data from the Internet before installing), a peer-to-peer 
application, or any other network application.

Thank you for your time.

Steven

Re: an oldie but a goodie .. ISO C90 does not support 'long long'

[Jakob Bohm via openssl-users]

On 2022-11-15 21:36, Phillip Susi wrote:


Jakob Bohm via openssl-users  writes:


Performance wise, using a newer compiler that implements int64_t etc. via
frequent library calls, while technically correct, is going to run
unnecessarily slow compared to having algorithms that actually use the
optimal integral sizes for the hardware/compiler combination.

Why would you think that?  If you can rewrite the code to break things
up into 32 bit chunks and handle overflows etc, the compiler certainly
can do so at least as well, and probably faster than you ever could.


When a compiler breaks up operations, it will do so separately for
every operation such as +, -, *, /, %, <<, >> .  In doing so,
compilers will generally use expansions that are supposedly
valid for all numbers, while manually breaking up code can often
skip cases not possible in the algorithm in question, for example
taking advantage of some values always being less than
SIZE_T_MAX.

Also, I already mentioned that some compilers do the breaking
incorrectly, resulting in code that makes incorrect calculations.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

Re: Upgrading OpenSSL on Windows 10

[Michael Wojcik via openssl-users]

> From: openssl-users  on behalf of 
> Steven_M.irc via openssl-users 
> Sent: Monday, November 21, 2022 15:56
 
> However, I am running Windows 10, and since (unlike Linux) every piece of 
> software outside of Windows itself
> needs to be updated individually, I don't know how to track down every single 
> application that might be using
> OpenSSL and make sure that the copy of OpenSSL it uses is up-to-date.

You don't. There may be applications that have OpenSSL linked statically, or 
linked into one of its own DLLs, or just with the OpenSSL DLLs renamed.

> As many of you would know, under repository-based systems (such as most Linux 
> distros), this would not be an
> issue as I could update every single application (system or non-system) at 
> once.

This is not true in the general case. There are applications which are 
available on Linux which do not use the distribution's package manager. There 
are applications which use their own OpenSSL build, possibly linked statically 
or linked into one of their own shared objects or with the OpenSSL shared 
objects renamed. Linux distributions have not magically solved the problem of 
keeping all software on the system current.


Back to Windows: It is possible, with relatively little effort, to find all the 
copies of the OpenSSL DLLs under their usual names on a system, and then glean 
from them their version information. With significantly more effort, you can 
search for exported OpenSSL symbols within third-party binaries, which will 
detect some more instances. With quite a lot of additional effort, you can 
winkle out binaries which contain significant portions of code matching some 
OpenSSL release (see various research efforts on function-point and code-block 
matching, and compare with alignment strategies in other fields, such as 
genomics). If your definition of "OpenSSL in an application" is not too 
ambitious, this might even be feasible.

But to what end? Each application will either be well-supported, in which case 
you can find out from the vendor what OpenSSL version it contains and whether 
an update is available; or it is not, in which you'll be out of luck.

This is true of essentially every software component, most of which are not as 
well-maintained or monitored as OpenSSL. Modern software development is mostly 
a haphazard hodgepodge of accumulating software of uncertain provenance and 
little trustworthiness into enormous systems with unpredictable behavior and 
failure modes. I'm not sure OpenSSL versions should be particularly high on 
anyone's priority list.

What are you actually trying to accomplish? What's your task? Your threat model?

-- 
Michael Wojcik

Upgrading OpenSSL on Windows 10

[Steven_M.irc via openssl-users]

Hi All,
A few weeks ago I sent this e-mail to the group: 
https://mta.openssl.org/pipermail/openssl-users/2022-November/015613.html I 
received a couple of replies, but sadly I have been too busy to respond to 
them. Regardless, I need a bit more information please.

In one of the replies, Viktor said "Just upgrade any affected systems and 
you'll be fine.". However, I am running Windows 10, and since (unlike Linux) 
every piece of software outside of Windows itself needs to be updated 
individually, I don't know how to track down every single application that 
might be using OpenSSL and make sure that the copy of OpenSSL it uses is 
up-to-date. As many of you would know, under repository-based systems (such as 
most Linux distros), this would not be an issue as I could update every single 
application (system or non-system) at once.

For those of you who may be thinking "but Windows doesn't use OpenSSL"; when 
the latest OpenSSL vulnerabilities were discovered I asked a Windows IRC 
channel whether or not Windows uses OpenSSL, the reply was that Windows itself 
does not use it, but many applications running on Windows do.

Thank you all for your time.

Re: X52219/X448 export public key coordinates

[ORNEST Matej - Contractor via openssl-users]

Thanks for the explanation, that probably makes sense.

Thank you
Matt

From: Kyle Hamilton 
Date: Monday, 21 November 2022 12:46
To: ORNEST Matej - Contractor 
Cc: openssl-users 
Subject: Re: X52219/X448 export public key coordinates
The reason has to do with the type of curve representation. X25519 is typically 
represented in (I believe, but I'm not an expert and I haven't looked at the 
primary sources recently so take this with a grain of salt) Montgomery form. 
Its digital signature counterpart Ed25519 uses the same curve represented in 
Edwards form.

Conversely, the NIST curves are in Weierstrass form. The EC_KEY interface deals 
solely with Weierstrass form.

To my understanding, you can convert any curve to any representation. However, 
different forms can be acted on with different values at different levels of 
efficiency, which is why the different forms exist.

I hope this helps!

-Kyle H

On Fri, Nov 18, 2022, 11:47 ORNEST Matej - Contractor via openssl-users 
mailto:openssl-users@openssl.org>> wrote:
Yeah, of course, sorry for the typo. I’ve already found a solution that seems 
to be working by using EVP_PKEY_get_raw_public_key() for these types of curves. 
I was confused why it’s not working with EC_KEY interfaces though it’s type of 
elliptic curve. Then I found somewhere that it’s implemented outside the 
context of EC. It’s not clear to me why but I believe there’s a good reason for 
it.
Anyway, thanks for your answer!
Regards
Matt


On 18. 11. 2022, at 17:13, Kyle Hamilton 
mailto:aerow...@gmail.com>> wrote:

X25519?

On Mon, Nov 14, 2022, 05:23 ORNEST Matej - Contractor via openssl-users 
mailto:openssl-users@openssl.org>> wrote:
Hi all,

I need to implement support for X52219/X448 for DH key exchange (and 
Ed52219/Ed448 for DSA) elliptic curves in our project. I need to export public 
key for DH exchange in form of DER encoded chunk in form 
tag+X-coordinate+Y-coordinate. Thus I need to get EC_POINT from EVP_PKEY and 
encode it as needed. I understand that those key types differs from EC types in 
way that I need just X coordinate and a flag bit to reconstruct the key, but 
still, how do I get the X coordinate?
My solution works for all other EC types such as SecpX and Brainpool families, 
but not for X52219/X448 keys and I do not completely understand why. 
Specifically when I decode public key previously encoded with i2d_PUBKEY() to 
EVP_PEKY and try to get EC_KEY by calling EVP_PKEY_get0_EC_KEY(), it returns 
NULL and issues an error that it’s not an EC key…

I’m using following code:


EVP_PKEY *key = … // Decode from DER encoded public key



if(key != nil) {



EC_KEY *ecKey = EVP_PKEY_get0_EC_KEY(key);

 /// When X52219 or X448 key is passed, ecKey is NULL

if(ecKey != NULL) {

const EC_POINT *point = EC_KEY_get0_public_key(ecKey);

const EC_GROUP *group = EC_KEY_get0_group(ecKey);



if(point != NULL && group != NULL) {

BIGNUM *bnX = BN_new();

BIGNUM *bnY = BN_new();



if(EC_POINT_get_affine_coordinates(group, point, bnX, bnY, 
NULL)) {

char *hexX = BN_bn2hex(bnX);

char *hexY = BN_bn2hex(bnY);



// Convert to custom data structures

  …

}



BN_free(bnX);

BN_free(bnY);

}

}

}


Is there any way how to export those key types in desired format?  I’m using 
OpenSSL version 1.1.1q.

Thank you very much for any hint
Matt

Re: X52219/X448 export public key coordinates

[ORNEST Matej - Contractor via openssl-users]

Yeah, of course, sorry for the typo. I’ve already found a solution that seems 
to be working by using EVP_PKEY_get_raw_public_key() for these types of curves. 
I was confused why it’s not working with EC_KEY interfaces though it’s type of 
elliptic curve. Then I found somewhere that it’s implemented outside the 
context of EC. It’s not clear to me why but I believe there’s a good reason for 
it.
Anyway, thanks for your answer!

Regards
Matt

On 18. 11. 2022, at 17:13, Kyle Hamilton  wrote:


X25519?

On Mon, Nov 14, 2022, 05:23 ORNEST Matej - Contractor via openssl-users 
mailto:openssl-users@openssl.org>> wrote:
Hi all,

I need to implement support for X52219/X448 for DH key exchange (and 
Ed52219/Ed448 for DSA) elliptic curves in our project. I need to export public 
key for DH exchange in form of DER encoded chunk in form 
tag+X-coordinate+Y-coordinate. Thus I need to get EC_POINT from EVP_PKEY and 
encode it as needed. I understand that those key types differs from EC types in 
way that I need just X coordinate and a flag bit to reconstruct the key, but 
still, how do I get the X coordinate?
My solution works for all other EC types such as SecpX and Brainpool families, 
but not for X52219/X448 keys and I do not completely understand why. 
Specifically when I decode public key previously encoded with i2d_PUBKEY() to 
EVP_PEKY and try to get EC_KEY by calling EVP_PKEY_get0_EC_KEY(), it returns 
NULL and issues an error that it’s not an EC key…

I’m using following code:


EVP_PKEY *key = … // Decode from DER encoded public key



if(key != nil) {



EC_KEY *ecKey = EVP_PKEY_get0_EC_KEY(key);

 /// When X52219 or X448 key is passed, ecKey is NULL

if(ecKey != NULL) {

const EC_POINT *point = EC_KEY_get0_public_key(ecKey);

const EC_GROUP *group = EC_KEY_get0_group(ecKey);



if(point != NULL && group != NULL) {

BIGNUM *bnX = BN_new();

BIGNUM *bnY = BN_new();



if(EC_POINT_get_affine_coordinates(group, point, bnX, bnY, 
NULL)) {

char *hexX = BN_bn2hex(bnX);

char *hexY = BN_bn2hex(bnY);



// Convert to custom data structures

  …

}



BN_free(bnX);

BN_free(bnY);

}

}

}


Is there any way how to export those key types in desired format?  I’m using 
OpenSSL version 1.1.1q.

Thank you very much for any hint
Matt

X52219/X448 export public key coordinates

[ORNEST Matej - Contractor via openssl-users]

Hi all,

I need to implement support for X52219/X448 for DH key exchange (and 
Ed52219/Ed448 for DSA) elliptic curves in our project. I need to export public 
key for DH exchange in form of DER encoded chunk in form 
tag+X-coordinate+Y-coordinate. Thus I need to get EC_POINT from EVP_PKEY and 
encode it as needed. I understand that those key types differs from EC types in 
way that I need just X coordinate and a flag bit to reconstruct the key, but 
still, how do I get the X coordinate?
My solution works for all other EC types such as SecpX and Brainpool families, 
but not for X52219/X448 keys and I do not completely understand why. 
Specifically when I decode public key previously encoded with i2d_PUBKEY() to 
EVP_PEKY and try to get EC_KEY by calling EVP_PKEY_get0_EC_KEY(), it returns 
NULL and issues an error that it’s not an EC key…

I’m using following code:


EVP_PKEY *key = … // Decode from DER encoded public key



if(key != nil) {



EC_KEY *ecKey = EVP_PKEY_get0_EC_KEY(key);

 /// When X52219 or X448 key is passed, ecKey is NULL

if(ecKey != NULL) {

const EC_POINT *point = EC_KEY_get0_public_key(ecKey);

const EC_GROUP *group = EC_KEY_get0_group(ecKey);



if(point != NULL && group != NULL) {

BIGNUM *bnX = BN_new();

BIGNUM *bnY = BN_new();



if(EC_POINT_get_affine_coordinates(group, point, bnX, bnY, 
NULL)) {

char *hexX = BN_bn2hex(bnX);

char *hexY = BN_bn2hex(bnY);



// Convert to custom data structures

  …

}



BN_free(bnX);

BN_free(bnY);

}

}

}


Is there any way how to export those key types in desired format?  I’m using 
OpenSSL version 1.1.1q.

Thank you very much for any hint
Matt

Fw:OpenSSL AES Decryption fails randomly C++

[WuJinze via openssl-users]

sorry for my mistake. I found that the gist url can not display well in mail 
and here is the 
url: https://gist.github.com/GoGim1/77c9bebec1cc71cea066515b4623a051




WuJinze
294843...@qq.com



 




-- Original --
From:   
 "WuJinze"  
  <294843...@qq.com>;
Date: Sat, Nov 12, 2022 06:17 PM
To: "openssl-users"

OpenSSL AES Decryption fails randomly C++

[WuJinze via openssl-users]

Dear OpenSSL Group,
Greetings. I was working on writing simple aes encrypt/decrypt wrapper 
function in c++ and running into a strange problem. The minimal reproducible 
examples in gist seems working fine but when i uncomment lines 90-92, it will 
fail to decrypt randomly. Can someone help me to figure out what's wrong with 
the code?Here is my code: OpenSSL AES Decryption fails randomly C++ 
(github.com). OpenSSL version is OpenSSL 1.1.1f. G++ version is 9.4.0.Regards, 
Jinze

Re: an oldie but a goodie .. ISO C90 does not support 'long long'

[Jakob Bohm via openssl-users]

On 2022-11-06 23:14, raf via openssl-users wrote:

On Sat, Nov 05, 2022 at 02:22:55PM +, Michael Wojcik 
 wrote:


From: openssl-users  On Behalf Of raf via
openssl-users
Sent: Friday, 4 November, 2022 18:54

On Wed, Nov 02, 2022 at 06:29:45PM +, Michael Wojcik via openssl-users
 wrote:


I'm inclined to agree. While there's an argument for backward compatibility,
C99 was standardized nearly a quarter of a century ago. OpenSSL 1.x is
younger than C99. It doesn't seem like an unreasonable requirement.

Would this be a choice between backwards-compatibility with C90
compilers and compatibility with 32-bit architectures?

I don't see how.

It's a question of the C implementation, not the underlying
architecture. A C implementation for a 32-bit system can certainly
provide a 64-bit integer type. If that C implementation conforms to
C99 or later, it ought to do so using long long and unsigned long
long. (I'm excluding C implementations for exotic systems where, for
example, CHAR_BIT != 8, such as some DSPs; those aren't going to be
viable targets for OpenSSL anyway.)


Is there another way to get 64-bit integers on 32-bit systems?

Sure. There's a standard one, which is to include  and
use int64_t and uint64_t. That also requires C99 or later and an
implementation which provides those types; they're not required.

Sorry. I assumed that it was clear from context that I was only
thinking about C90-compliant 64-bit integers on 32-bit systems.


And for some implementations there are implementation-specific
extensions, which by definition are not standard.

And you can roll your own. In a non-OO language like C, this would
be intrusive for the parts of the source base that rely on a 64-bit
integer type.


I suspect that that there are more 32-bit systems than there are
C90 compilers.

Perhaps, but I don't think it's relevant here. In any case, OpenSSL is
not in the business of supporting every platform and C implementation
in existence. There are the platforms supported by the project, and
there are contributed platforms which are included in the code base
and supported by the community (hopefully), and there are unsupported
platforms.

If someone wants OpenSSL on an unsupported platform, then it's up to
them to do the work.

So it sounds like C90 is now officially unsupported.
I got the impression that, before this thread, it was believed
that C90 was supported, and the suggestion of a pull request
indicated a willingness to retain/return support for C90.
Perhaps it just indicated a willingness to accept community
support for it.

I'd be amazed if anyone could actually still be using a
30 year old C90 compiler, rather than a compiler that
just gives warnings about C90. :-)


Regarding C90 compilers, it is important to realize that some system
vendors kept providing (arbitrarily extended) C90 compiler long after
1999.  Microsoft is one example, with many of their system compilers
for "older" OS versions being based on Microsoft's C90 compilers.
 These compilers did not provide a good stdint.h, but might be coached
to load a porter provided stdint.h that maps int64_t and uint64_t to
their vendor specific C90 extensions (named __int64 and unsigned __int64).

Even worse, I seem to recall at least one of those compilers miscompiling
64 bit integer arithmetic, but working acceptably with the older OpenSSL
1.0.x library implementations of stuff like bignums (BN) and various pure
C algorithm implementations in OpenSSL 1.0.x, that happened to do 
everything

by means of 32 and 16 bit types.

As part of our company business is to provide software for the affected
"older" systems, thus desiring the ability to compile OpenSSL 3.x with
options indicating "compiler has no good integral types larger than
uint32_t, floating point is also problematic"

Other major vendors with somewhat old C compilers include a few embedded
platforms such as older ARM and MIPS chips that were mass produced in
vast quantities.

Performance wise, using a newer compiler that implements int64_t etc. via
frequent library calls, while technically correct, is going to run
unnecessarily slow compared to having algorithms that actually use the
optimal integral sizes for the hardware/compiler combination.

I seem to recall using at least one bignum library (not sure if OpenSSL
or not) that could be configured to use uint32_t and uint16_t using the
same C code that combines uint64_t and uint32_t on newer hardware.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

Re: an oldie but a goodie .. ISO C90 does not support 'long long'

[raf via openssl-users]

On Sat, Nov 05, 2022 at 02:22:55PM +, Michael Wojcik 
 wrote:

> > From: openssl-users  On Behalf Of raf 
> > via
> > openssl-users
> > Sent: Friday, 4 November, 2022 18:54
> > 
> > On Wed, Nov 02, 2022 at 06:29:45PM +, Michael Wojcik via openssl-users
> >  wrote:
> > 
> > >
> > > I'm inclined to agree. While there's an argument for backward 
> > > compatibility,
> > > C99 was standardized nearly a quarter of a century ago. OpenSSL 1.x is
> > > younger than C99. It doesn't seem like an unreasonable requirement.
> > 
> > Would this be a choice between backwards-compatibility with C90
> > compilers and compatibility with 32-bit architectures?
> 
> I don't see how.
> 
> It's a question of the C implementation, not the underlying
> architecture. A C implementation for a 32-bit system can certainly
> provide a 64-bit integer type. If that C implementation conforms to
> C99 or later, it ought to do so using long long and unsigned long
> long. (I'm excluding C implementations for exotic systems where, for
> example, CHAR_BIT != 8, such as some DSPs; those aren't going to be
> viable targets for OpenSSL anyway.)
> 
> > Is there another way to get 64-bit integers on 32-bit systems?
> 
> Sure. There's a standard one, which is to include  and
> use int64_t and uint64_t. That also requires C99 or later and an
> implementation which provides those types; they're not required.

Sorry. I assumed that it was clear from context that I was only
thinking about C90-compliant 64-bit integers on 32-bit systems.

> And for some implementations there are implementation-specific
> extensions, which by definition are not standard.
> 
> And you can roll your own. In a non-OO language like C, this would
> be intrusive for the parts of the source base that rely on a 64-bit
> integer type.
> 
> > I suspect that that there are more 32-bit systems than there are
> > C90 compilers.
> 
> Perhaps, but I don't think it's relevant here. In any case, OpenSSL is
> not in the business of supporting every platform and C implementation
> in existence. There are the platforms supported by the project, and
> there are contributed platforms which are included in the code base
> and supported by the community (hopefully), and there are unsupported
> platforms.
> 
> If someone wants OpenSSL on an unsupported platform, then it's up to
> them to do the work.

So it sounds like C90 is now officially unsupported.
I got the impression that, before this thread, it was believed
that C90 was supported, and the suggestion of a pull request
indicated a willingness to retain/return support for C90.
Perhaps it just indicated a willingness to accept community
support for it.

I'd be amazed if anyone could actually still be using a
30 year old C90 compiler, rather than a compiler that
just gives warnings about C90. :-)

> -- 
> Michael Wojcik

cheers,
raf

Re: TLS 1.3 Early data

[Benjamin Kaduk via openssl-users]

On Sat, Nov 05, 2022 at 11:50:18AM +0100, Dirk Menstermann wrote:
> Hello,
> 
> I did few experiments with early data but was not successful in solving my
> exotic use case: "Using early data dependent on the SNI"
> 
> I control the server (linux, supports http2) based on OpenSSL 111q and use a
> recent firefox as client:
> 
> 1) Setting SSL_CTX_set_max_early_data in the SSL_CTX* works (FF sends early 
> data)
> 2) Setting SSL_set_max_early_data on the just created SSL* works (FF sends 
> early
> data)
> 3) Setting SSL_set_max_early_data in the SNI callback during the handshake 
> does
> not work (FF does not send early data)
> 
> I guess there is a dirty way to "peek" into the client hello and parse it
> without OpenSSL, extracting the SNI and make it then like in 2), but I wonder 
> if
> there is a better way.
> 
> Any idea?

The SNI callback runs far too late for this purpose (and, to be honest, a lot of
other purposes).  You should be able to use the client_hello callback for it,
though 
(https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_client_hello_cb.html).

Note that SSL_get_servername() does not provide something useful within the
client hello callback execution and you'll have to do something like
https://github.com/openssl/openssl/blob/master/test/helpers/handshake.c#L146-L198
in order to access the provided SNI value from the client.

-Ben

RE: an oldie but a goodie .. ISO C90 does not support 'long long'

[Michael Wojcik via openssl-users]

> From: openssl-users  On Behalf Of raf via
> openssl-users
> Sent: Friday, 4 November, 2022 18:54
> 
> On Wed, Nov 02, 2022 at 06:29:45PM +, Michael Wojcik via openssl-users
>  wrote:
> 
> >
> > I'm inclined to agree. While there's an argument for backward compatibility,
> > C99 was standardized nearly a quarter of a century ago. OpenSSL 1.x is
> > younger than C99. It doesn't seem like an unreasonable requirement.
> 
> Would this be a choice between backwards-compatibility with C90
> compilers and compatibility with 32-bit architectures?

I don't see how.

It's a question of the C implementation, not the underlying architecture. A C 
implementation for a 32-bit system can certainly provide a 64-bit integer type. 
If that C implementation conforms to C99 or later, it ought to do so using long 
long and unsigned long long. (I'm excluding C implementations for exotic 
systems where, for example, CHAR_BIT != 8, such as some DSPs; those aren't 
going to be viable targets for OpenSSL anyway.)

> Is there another way to get 64-bit integers on 32-bit systems?

Sure. There's a standard one, which is to include  and use int64_t 
and uint64_t. That also requires C99 or later and an implementation which 
provides those types; they're not required.

And for some implementations there are implementation-specific extensions, 
which by definition are not standard.

And you can roll your own. In a non-OO language like C, this would be intrusive 
for the parts of the source base that rely on a 64-bit integer type.

> I suspect that that there are more 32-bit systems than there are
> C90 compilers.

Perhaps, but I don't think it's relevant here. In any case, OpenSSL is not in 
the business of supporting every platform and C implementation in existence. 
There are the platforms supported by the project, and there are contributed 
platforms which are included in the code base and supported by the community 
(hopefully), and there are unsupported platforms.

If someone wants OpenSSL on an unsupported platform, then it's up to them to do 
the work.

-- 
Michael Wojcik

Re: an oldie but a goodie .. ISO C90 does not support 'long long'

[raf via openssl-users]

On Wed, Nov 02, 2022 at 06:29:45PM +, Michael Wojcik via openssl-users 
 wrote:

> > From: openssl-users  On Behalf Of Phillip
> > Susi
> > Sent: Wednesday, 2 November, 2022 11:45
> > 
> > The only thing to fix is don't put your compiler in strict C90 mode.
> 
> I'm inclined to agree. While there's an argument for backward compatibility,
> C99 was standardized nearly a quarter of a century ago. OpenSSL 1.x is
> younger than C99. It doesn't seem like an unreasonable requirement.
> 
> But as Tomas wrote, anyone who thinks it is can submit a pull request.
> 
> -- 
> Michael Wojcik

Would this be a choice between backwards-compatibility with C90
compilers and compatibility with 32-bit architectures?

Is there another way to get 64-bit integers on 32-bit systems?

I suspect that that there are more 32-bit systems than there are
C90 compilers.

cheers,
raf

RE: OpenSSL 3.0.7 make failure on Debian 10 (buster)

[Michael Wojcik via openssl-users]

> From: openssl-users  On Behalf Of Matt
> Caswell
> Sent: Friday, 4 November, 2022 06:43
> 
> This looks like something environmental rather than a problem with
> OpenSSL itself. /usr/lib/gcc/x86_64-linux-gnu/8/include-fixed/limits.h
> is clearly a system include file, trying to include some other system
> include file ("recurse down to the real one") which it is failing to find.

Specifically, limits.h is part of the C standard library (see e.g. ISO 
9899:1999 7.10). This is a GCC issue; there's something wrong with John's GCC 
installation, or how his environment configures it.

GCC often appears to have adopted "too clever by half" as a design goal.

-- 
Michael Wojcik

Re: Output buffer length in EVP_EncryptUpdate for ECB mode

[Wiktor Kwapisiewicz via openssl-users]

Matt,

EVP_EncryptUpdate() can be called repeatedly, incrementally feeding in 
the data to be encrypted. The ECB mode (when used with AES-128) will 
encrypt input data 16 bytes at a time, and the output size will also be 
16 bytes per input block. If the data that you feed in to 
EVP_EncryptUpdate() is not a multiple of 16 bytes then the amount of 
data that is over a multiple of 16 bytes will be cached until a 
subsequent call where it does have 16 bytes.


Let's say you call EVP_EncryptUpdate() with 15 bytes of data. In that 
case all 15 bytes will be cached and 0 bytes will be output.


If you then call it again with 17 bytes of data, then added to the 15 
bytes already cached we have a total of 32 bytes. This is a multiple of 
16, so 2 blocks (32 bytes) will be output, so:


(inl + cipher_block_size - 1) = (17 + 16 - 1) = 32


This explanation makes perfect sense. Thank you!

The context I asked is that the rust-openssl wrapper always requires the 
output buffer to be at least as big as the input buffer + the cipher's 
block size [0] (assuming pessimistic case). That is even if I always 
feed the EVP_EncryptUpdate with blocks exactly 16 bytes long the wrapper 
requires 32 byte output buffers, while, based on your description 16 
byte output buffers should be sufficient.


Thank you for your time!

Kind regards,
Wiktor

[0]: https://docs.rs/openssl/latest/src/openssl/cipher_ctx.rs.html#504

RE: SSL_read empty -> close?

[Michael Wojcik via openssl-users]

> From: Felipe Gasper 
> Sent: Thursday, 3 November, 2022 10:43
> >
> > And your description looks wrong anyway: shutdown(SHUT_RD) has
> > implementation-defined behavior for TCP sockets (because TCP does not
> > announce the read side of half-close to the peer), and on Linux causes
> > blocked receives and subsequent receives to return 0 (according to 
> > references
> 
> perl -MSocket -MIO::Socket::INET -e'my $s = IO::Socket::INET->new( Server =>
> 1, Listen => 1 ) or die; my $port = $s->sockport(); my $c = IO::Socket::INET-
> >new("localhost:$port") or die; syswrite $c, "hello"; my $sc = $s->accept();
> shutdown($sc, SHUT_RD); sysread $sc, my $buf, 512 or die $!; print $buf'
> 
> ^^ The above, I believe, demonstrates to the contrary: the read buffer is
> populated prior to shutdown and drained afterward.

As I noted, I hadn't tested it. The Linux man page is ambiguous:

   If how is SHUT_RD, further receptions will be disallowed.

It doesn't define "receptions". It's entirely possible that SHUT_RD will cause 
the stack to reject further application data (i.e. packets that increment the 
sequence number for anything other than ACK) from the peer, but permit the 
socket owner to continue to receive already-buffered data. That's arguably a 
poor implementation, and not what the man page appears to imply. And it looks 
to be in conflict with the Single UNIX Specification Issue 7 (not that Linux 
claims to be UNIX-conformant), which states that SHUT_SD "Disables further 
receive operations"; "operations" certainly seems to refer to actions taken by 
the caller, not by the peer.

There is a fair bit of debate about this online, and a number of people opine 
that the Linux behavior is correct, and SUS (they often refer to "POSIX", but 
POSIX has been superseded by SUS) is wrong. Others disagree.

The Linux kernel does take some action for a TCP socket that has SHUT_RD 
requested for it, but the behavior is not simple. (One SO comment mentions it 
causes it to exit the read loop in tcp_splice_read(), for example.) I'd be 
leery about relying on it.

I'm not sure how shutdown(SHUT_RD) is useful in the case of a TCP socket being 
used for TLS, to be perfectly honest. If the application protocol delimits 
messages properly and is half-duplex (request/response), then one side should 
know that no more data is expected and the other can detect incomplete 
messages, so there's likely no issue. If not, there's no way to guarantee you 
haven't encountered an incomplete message in bounded time (FPL Theorem 
applies). SHUT_RD does not signal the peer, so the peer can still get a RST if 
it continues to send. Perhaps I'm missing something, but I don't see what 
failure mode is being avoided by using SHUT_RD.

-- 
Michael Wojcik

RE: SSL_read empty -> close?

[Michael Wojcik via openssl-users]

> From: Felipe Gasper 
> Sent: Thursday, 3 November, 2022 08:51
> 
> You probably know this, but: On Linux, at least, if a TCP socket close()s
> with a non-empty read buffer, the kernel sends TCP RST to the peer.

Yes, that's a conditional-compliance (SHOULD) requirement from the Host 
Requirements RFC. See RFC 1122, 4.2.2.13.

> Some
> applications “panic” when they receive the RST and discard data.

Well, applications do a lot of things. Receiving an RST informs the peer that 
some of the data they sent was not successfully processed by the local 
application, so treating that as an error condition is not inappropriate.

But generally it's better if the application protocol imposes its own record 
structure and control information on top of TCP's very basic stream.

> It’s a rare
> issue, but when it does it’s a head-scratcher. To avoid that, it’s necessary
> to shutdown(SHUT_RD) then drain the read buffer before close().

Well, it's not *necessary* to do a half-close. Applications often know when 
they've received all the data the peer intends to send, thanks to 
record-delimiting mechanisms in the application protocol.

And your description looks wrong anyway: shutdown(SHUT_RD) has 
implementation-defined behavior for TCP sockets (because TCP does not announce 
the read side of half-close to the peer), and on Linux causes blocked receives 
and subsequent receives to return 0 (according to references -- I have't tested 
it), which means after shutdown(SHUT_RD) you *can't* drain the receive buffer. 
shutdown(SHUT_WR) would work, since it sends a FIN, telling the peer you won't 
be sending any more data, and still allows you to receive.

> So it seems like this *shouldn’t* be obscure, if applications do the
> shutdown/drain thing.

It's obscure in the sense that a great many people trying to use TLS get much 
more basic things wrong.

More generally, the OpenSSL documentation mostly covers the OpenSSL APIs, and 
leaves networking up to the OpenSSL consumer to figure out. The OpenSSL wiki 
covers topics that people have written, and those are going to focus on common 
questions and areas of particular interest for someone. If the interactions 
among the OpenSSL API, the TLS protocol (in its various versions), and the 
shutdown system call haven't historically been a problem for many people, then 
it's "obscure" in the literal sense of not having 
attracted much notice.

And in practice, the majority of TLS use is with HTTP, and HTTP does a fairly 
good job of determining when more data is expected, and handling cases where it 
isn't. An HTTP client that receives a complete response and then attempts to 
use the conversation for its next request, and gets an RST on that, for 
example, will just open a new conversation; it doesn't care that the old one 
was terminated. HTTP servers are simliarly tolerant because interactive user 
agents in particular cancel requests by closing (or, unfortunately, aborting) 
the connection all the time.

> I would guess that many don’t and just don’t see the
> RST thing frequently enough to worry about it. Regardless, the documentation
> is already pretty voluminous, so if this doesn’t bite many folks, then hey.

Yes, but wiki articles are always appreciated.

-- 
Michael Wojcik

Output buffer length in EVP_EncryptUpdate for ECB mode

[Wiktor Kwapisiewicz via openssl-users]

Hello,

I'd like to clarify one aspect of the API regarding EVP_EncryptUpdate
[0] that is the length of the output buffer that should be passed to
that function ("out" parameter). (Actually I'm using EVP_CipherUpdate 
but the docs are more comprehensive for EVP_EncryptUpdate).


[0]: https://www.openssl.org/docs/manmaster/man3/EVP_EncryptUpdate.html

For the record I'm using AES-128 cipher in ECB mode and the docs say:


For most ciphers and modes, the amount of data written can be
anything from zero bytes to (inl + cipher_block_size - 1) bytes. For
wrap cipher modes, the amount of data written can be anything from
zero bytes to (inl + cipher_block_size) bytes. For stream ciphers,
the amount of data written can be anything from zero bytes to inl
bytes.


AES-128-ECB doesn't appear to be a stream cipher (since the "block size" 
returns 16 not the magical value of 1) and I'm unable to find any 
mentions of "wrap cipher modes" in search engines. Apparently ECB is a 
block cipher mode.


Does that mean that "wrap cipher modes" == "block cipher modes"?

Is there any documentation I could read on the reasoning of why a space 
for additional block is needed in this case ("(inl + cipher_block_size) 
bytes")? I'm trying to understand the differences between OpenSSL and 
other cryptographic backends in an OpenPGP library [1].


Thank you for your time and help!

Kind regards,
Wiktor

[1]: 
https://gitlab.com/sequoia-pgp/sequoia/-/merge_requests/1361#note_1150958453

RE: SSL_read empty -> close?

[Michael Wojcik via openssl-users]

> From: Felipe Gasper 
> Sent: Thursday, 3 November, 2022 07:42
> 
> It sounds, then like shutdown() (i.e., TCP half-close) is a no-no during a
> TLS session.

Um, maybe. Might generally be OK in practice, particularly with TLSv1.3, which 
got rid of some of the less-well-considered ideas of earlier TLS versions. 
Honestly I'd have to spend some time digging through chapter & verse of the 
RFCs to arrive at any reliable opinion on the matter, though. Someone else here 
may have already considered it.

> Does OpenSSL’s documentation mention that? (I’m not exhaustively
> familiar with it, but I don’t remember having seen such.)

I doubt it. I don't see anything on the wiki, and this is a pretty obscure 
issue, all things considered.

> It almost seems like, given that TLS notify-close then TCP close() (i.e.,
> without awaiting the peer’s TLS notify-close) is legitimate, OpenSSL could
> gainfully tolerate/hide the EPIPE that that close() likely produces, and have
> SSL_read() et al just return empty-string.

Well, it could, but OpenSSL generally doesn't try to provide that type of 
abstraction.

Also note this paragraph from the wiki page on TLSv1.3 
(https://wiki.openssl.org/index.php/TLS1.3):

   If a client sends it's [sic] data and directly sends the close
   notify request and closes the connection, the server will still
   try to send tickets if configured to do so. Since the connection
   is already closed by the client, this might result in a write
   error and receiving the SIGPIPE signal. The write error will be
   ignored if it's a session ticket. But server applications can
   still get SIGPIPE they didn't get before.

So session tickets can also be a source of EPIPE when a client closes the 
connection.

> It surprises me that notify-close then close() is considered legitimate use.

There are so many TLS implementations and TLS-using applications out there that 
interoperability would be hugely compromised if we didn't allow a large helping 
of Postel's Interoperability Principle. So most applications try to be 
accommodating. There's even an OpenSSL flag to ignore the case where a peer 
closes without sending a close-notify, in case you run into one of those and 
want to suppress the error.

-- 
Michael Wojcik

RE: Worried about the vulnerabilities recently found in OpenSSL versions 3.0.0 - 3.0.6.

[Michael Wojcik via openssl-users]

> From: openssl-users  On Behalf Of
> Steven_M.irc via openssl-users
> Sent: Wednesday, 2 November, 2022 17:18
> 
> I'm really worried about the vulnerabilities recently found in OpenSSL
> versions 3.0.0 - 3.0.6.

Why? What's your threat model?

> If I understand things correctly (and please do
> correct me if I'm wrong), it doesn't matter which version of OpenSSL clients
> are running, only which version of OpenSSL *servers* are running. Thus it
> seems like end-users can do very little to protect themselves.

Protect themselves from what?

Take the most recent issues, CVE-2022-3786 and -3602. 3786 is a potential 
4-byte buffer overflow when parsing an email address component of a 
distinguished name in a certificate. (Note, contrary to what you wrote above, 
this could affect both servers and clients, since it would be triggered by 
parsing a malformed certificate.) This is probably not exploitable, per the 
OpenSSL blog post and analyses performed elsewhere, but let's imagine the worst 
case: OpenSSL 3.0.6 running on some platform where it's possible to leverage 
this BOF into an RCE.

If that's a server system, then:
1) If the server doesn't request client certificates, it should reject a 
Certificate message from the client, and not try to parse any, so there's no 
exposure.
2) We'll assume *you* aren't going to send a malicious certificate, so for your 
connection the vulnerability is irrelevant.
3) So the only case we care about is where some other actor sends a malicious 
certificate and chains the RCE with other attacks to pivot and escalate and 
subvert the server. We're on a pretty narrow branch of the attack tree here, 
and more importantly, the same could be true of a vast array of potential 
vulnerabilities in the server site. This is only an issue if an attacker can't 
find any other more useful vulnerability in the site. If you pay attention to 
IT security, you know *that* isn't likely.

If it's a client system, then you only care if it's *your* client, and you 
visit a malicious site. If you're in the habit of using OpenSSL 3.0.6 to 
connect to malicious servers, well, 3786 is not likely to be high on your list 
of problems.

3602 is even less likely to be exploitable.

Vulnerabilities are only meaningful in the context of a threat model. I don't 
see a plausible threat model where these should matter to a client-side end 
user.

-- 
Michael Wojcik

How to upgrade openssl from 3.0.2 to 3.0.7

[Anupam Dutta via openssl-users]

Hi Team,

I want to upgrade the openssl version from 3.0.2 to 3.0.7. My OS version is
Ubuntu 22.04.1 LTS (Jammy Jellyfish). Please help .It is urgent.

Regards,
Anupam

自动回复: Re: Worried about the vulnerabilities recently found in OpenSSLversions 3.0.0 - 3.0.6.

[kjjhh7 via openssl-users]

这是一封自动回复邮件。已经收到您的来信，我会尽快回复。

Worried about the vulnerabilities recently found in OpenSSL versions 3.0.0 - 3.0.6.

[Steven_M.irc via openssl-users]

Hi All,
I'm really worried about the vulnerabilities recently found in OpenSSL versions 
3.0.0 - 3.0.6. If I understand things correctly (and please do correct me if 
I'm wrong), it doesn't matter which version of OpenSSL clients are running, 
only which version of OpenSSL *servers* are running. Thus it seems like 
end-users can do very little to protect themselves. For example, how can an 
end-user tell if a website they're visiting is using a safe or an unsafe 
version of OpenSSL?

I did try putting my bank's website through an SSL tester (www.ssllabs.com), 
but I couldn't find an easy way to determine which version of OpenSSL they're 
running. I did get a protocol report, which read as follows:
TLS 1.3 Yes
TLS 1.2 Yes
TLS 1.1 No
TLS 1.0 No
SSL 3 No
SSL 2 No

However, I don't know if any of those protocol version numbers give any 
indication as to the OpenSSL version number(s)?

Any advice would be greatly appreciated.

Many thanks,
Steven_M



Sent with Proton Mail secure email.

RE: SSL_read empty -> close?

[Michael Wojcik via openssl-users]

> From: Felipe Gasper 
> Sent: Wednesday, 2 November, 2022 12:46
> 
> I wouldn’t normally expect EPIPE from a read operation. I get why it happens;
> it just seems odd. Given that it’s legitimate for a TLS peer to send the
> close_notify and then immediately do TCP close, it also seems like EPIPE is a
> “fact of life” here.

Yeah. That's because an OpenSSL "read" operation can do sends under the covers, 
and an OpenSSL "send" can do receives, in order to satisfy the requirements of 
TLS. Depending on the TLS version and cipher suite being used, it might need to 
do that for renegotiation or the like. Or if the socket is non-blocking you can 
get WANT_READ from a send and WANT_WRITE from a receive.

In your example it was actually a sendmsg that produced the EPIPE, but within 
the logical "read" operation.

The original idea of SSL was "just be a duplex bytestream service for the 
application", i.e. be socket-like; but that abstraction proved to be rather 
leaky. Much as sockets themselves are a leaky abstraction once you try to do 
anything non-trivial.

-- 
Michael Wojcik

Re: an oldie but a goodie .. ISO C90 does not support 'long long'

[Dennis Clarke via openssl-users]

On 11/2/22 18:29, Michael Wojcik via openssl-users wrote:

From: openssl-users  On Behalf Of Phillip
Susi
Sent: Wednesday, 2 November, 2022 11:45

The only thing to fix is don't put your compiler in strict C90 mode.


I'm inclined to agree. While there's an argument for backward compatibility, 
C99 was standardized nearly a quarter of a century ago. OpenSSL 1.x is younger 
than C99. It doesn't seem like an unreasonable requirement.

But as Tomas wrote, anyone who thinks it is can submit a pull request.




The more that I dig into this and look at the new OpenSSL 3.x the
more I am inclined to think C99 is good enough. Everywhere. Also I doubt
that the age of the thing matters much. The portability does.

Now I await with a flame proof suit for someone to yell "rewrite it
all in rust!"  Not bloodly likely.


--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

RE: an oldie but a goodie .. ISO C90 does not support 'long long'

[Michael Wojcik via openssl-users]

> From: openssl-users  On Behalf Of Phillip
> Susi
> Sent: Wednesday, 2 November, 2022 11:45
> 
> The only thing to fix is don't put your compiler in strict C90 mode.

I'm inclined to agree. While there's an argument for backward compatibility, 
C99 was standardized nearly a quarter of a century ago. OpenSSL 1.x is younger 
than C99. It doesn't seem like an unreasonable requirement.

But as Tomas wrote, anyone who thinks it is can submit a pull request.

-- 
Michael Wojcik

Re: an oldie but a goodie .. ISO C90 does not support 'long long'

[Dennis Clarke via openssl-users]

On 11/2/22 07:30, Tomas Mraz wrote:

No, long long and unsigned long long is required and it was required
for quite some time. The code is mostly C90 but not strictly.

I suppose on platforms with 64bit long type we could make it work
without long long though. Pull requests are welcome.

Tomas Mraz, OpenSSL




So fix it?

Feels like we are just going around and around in circles here :


Strict C90 CFLAGS results in sha.h:91 ISO C90 does not support long long
https://github.com/openssl/openssl/issues/10547


OPENSSL_strnlen SIGSEGV in o_str.c line 76
https://github.com/openssl/openssl/issues/8048



So the code is *mostly* C90 but not really. Got it.
Certainly worth looking at.




--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

RE: ungrade openssl 3.0.2 to 3.0.7

[Dr. Matthias St. Pierre via openssl-users]

Anupam,

please don’t attempt to install an openssl version which you built yourself to 
your Linux system, it might brake your applications. Your Linux distribution 
(Ubuntu) installs their own compiled versions  which you can upgrade using its 
package manager (apt)

Regards,

Matthias


From: openssl-users  On Behalf Of Anupam 
Dutta via openssl-users
Sent: Wednesday, November 2, 2022 9:12 AM
To: openssl-users@openssl.org
Subject: ungrade openssl 3.0.2 to 3.0.7

Hi Team,

I want to upgrade openssl from 3.0.2 to 3.0.7. I have downloaded 3.0.7 from 
https://www.openssl.org/source and installed successfully. But, still it is 
showing version 3.0.2.Please help. It's urgent.

My OS: 22.04.1 LTS (Jammy Jellyfish)

Regards,
Anupam


smime.p7s
Description: S/MIME cryptographic signature