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

[BENTLEY Thom via openssl-users]

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



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

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

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


Yes, they should search for TS_VERIFY_CTX_set_certs or

TS_VERIFY_CTX_set_flags (that would work for 1.1.1 as well).



Tomas Mraz, OpenSS



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

>

>

>

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

> configuration should be searching for a different function name?

>

> The HAVE_OPENSSL_PROTOTYPE_TS_VERIFY_CTS_SET_CERTS is a macro that

> checks for the existence of the TS_VERIFY_CTS_set_certs function in

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

> when verifying a TimeStampToken (TST)1.

>

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

> function is TS_VERIFY_CTX_set_certs, and the misspelled

> version TS_VERIFY_CTS_set_certs has been retained for compatibility

> reasons, but it is deprecated1.

>

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

> configured to handle this change in OpenSSL 3.0.8.

>

>

>

>

>

>

> Thom Bentley| Senior Software Engineer |

> Medidata, a Dassault Systèmes company

>

>

>

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

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

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

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

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

>

>

>

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

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

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

> are the errors I see. > >

>

>

>

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

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

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

> > 3.0.8 at least.

> > Here are the errors I see.

> >

> > dcmdsig:

> > 16:34:48:290

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

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

> > undefined type 'TS_verify_ctx'

> > 16:34:48:290

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

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

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

>

>

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

>

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

> like

> this:

>

>  TS_VERIFY_CTS_set_certs(ctx, NULL);

>

> Earlier on in that file we see this:

>

> #ifndef HAVE_OPENSSL_PROTOTYPE_TS_VERIFY_CTS_SET_CERTS

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

> #endif

>

> So if HAVE_OPENSSL_PROTOTYPE_TS_VERIFY_CTS_SET_CERTS isn't defined

> then

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

> not allowed from 1.1.1 onwards because it is opaque.

>

> My guess is the setting of

> HAVE_OPENSSL_PROTOTYPE_TS_VERIFY_CTS_SET_CERTS is going wrong with

> OpenSSL 3.X

>

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

>

>CHECK_FUNCTIONWITHHEADER_EXISTS("TS_VERIFY_CTS_set_certs(0,0)"

> "openssl/ts.h" HAVE_OPENSSL_PROTOTYPE_TS_VERIFY_CTS_SET_CERTS)

>

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

> instead a macro:

>

> # ifndef OPENSSL_NO_DEPRECATED_3_0

> #  define TS_VERIFY_CTS_set_certs(ctx, cert)

> TS_VERIFY_CTX_set_certs(ctx,cert)

> # endif

>

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

> worked correctly there.

>

> Matt

>

>

>

> >

> > dcmpstat:

> > 16:36:48:689

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

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

> > redefinition; different basic types

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

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

> > 16:36:48:753

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

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

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

> >

> > dcmtls:

> > 16:35:16:392

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

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

> > 

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

[Tomas Mraz]

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

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

Tomas Mraz, OpenSSL


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

-- 
Tomáš Mráz, OpenSSL

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

[Vishal Kevat via openssl-users]

Hi OpenSSL,

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

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

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

Regards,
Vishal Kevat




General

FIPS with Openssl 3.1

[Stiju]

Hi,

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

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


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



-- 


  Stiju Easo


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

OpenSSL provider question

[tomasz bartczak]

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

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

[Vishal Kevat via openssl-users]

That answers my questions.

Thanks Viktor.


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

[External email: Use caution with links and attachments]





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

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

Exactly 128 bits, no more, no less.

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

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

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

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

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

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

In that case, the excess bytes were ignored.

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

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

--
Viktor.

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

[Viktor Dukhovni]

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

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

Exactly 128 bits, no more, no less.

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

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

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

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

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

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

In that case, the excess bytes were ignored.

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

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

-- 
Viktor.

openssl-enc: needs additional base64 garbage check?

[Steffen Nurpmeso]

Hello.

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

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

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

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

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

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

github issue?

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

Maximum encryption key length supported by AES-128 CBC

[Vishal Kevat via openssl-users]

Hi OpenSLL users,

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

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

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

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

Regards,
Vishal Kevat


General

Programmatic way to get x509 to be signed digest

[Kenneth Goldman]

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

Is i2d_X509() the proper way? 

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

--
Work 1-914-945-2415




smime.p7s
Description: S/MIME cryptographic signature

Re: Certificate verification with cross signed CAs (James)

[James]

Certificates below

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

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

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

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

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


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

Re: Certificate verification with cross signed CAs (James)

[Martin Bonner via openssl-users]

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

> The certificates are attached below.

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

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

Re: Certificate verification with cross signed CAs

[James]

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

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


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


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


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


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

Re: Certificate verification with cross signed CAs

[Viktor Dukhovni]

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

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

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

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

-- 
Viktor.

Certificate verification with cross signed CAs

[James Chapman]

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

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

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

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

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

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

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

Many thanks
James

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

[Tomas Mraz]

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

Tomas Mraz, OpenSS

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

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

[BENTLEY Thom via openssl-users]

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


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

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

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




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

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

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






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

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

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

> 3.0.8 at least.

> Here are the errors I see.

>

> dcmdsig:

> 16:34:48:290

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

> 16:34:48:290

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

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





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



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

this:



 TS_VERIFY_CTS_set_certs(ctx, NULL);



Earlier on in that file we see this:



#ifndef HAVE_OPENSSL_PROTOTYPE_TS_VERIFY_CTS_SET_CERTS

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

#endif



So if HAVE_OPENSSL_PROTOTYPE_TS_VERIFY_CTS_SET_CERTS isn't defined then

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

not allowed from 1.1.1 onwards because it is opaque.



My guess is the setting of

HAVE_OPENSSL_PROTOTYPE_TS_VERIFY_CTS_SET_CERTS is going wrong with

OpenSSL 3.X



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



   CHECK_FUNCTIONWITHHEADER_EXISTS("TS_VERIFY_CTS_set_certs(0,0)"

"openssl/ts.h" HAVE_OPENSSL_PROTOTYPE_TS_VERIFY_CTS_SET_CERTS)



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

instead a macro:



# ifndef OPENSSL_NO_DEPRECATED_3_0

#  define TS_VERIFY_CTS_set_certs(ctx, cert)

TS_VERIFY_CTX_set_certs(ctx,cert)

# endif



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

worked correctly there.



Matt







>

> dcmpstat:

> 16:36:48:689

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

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

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

> 16:36:48:753

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

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

>

> dcmtls:

> 16:35:16:392

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

> 16:35:16:392

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

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

>

> **

>

> **

>

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

> company 

>

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

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

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

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

>

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

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

> TS_VERIFY_CTX_set* functions. If there are any particular accessors

> missing, please report that as a

>

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

>

> access its members directly. To set them you need 

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

[BENTLEY Thom via openssl-users]

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

Thanks.

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


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

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






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

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

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

> 3.0.8 at least.

> Here are the errors I see.

>

> dcmdsig:

> 16:34:48:290

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

> 16:34:48:290

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

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





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



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

this:



 TS_VERIFY_CTS_set_certs(ctx, NULL);



Earlier on in that file we see this:



#ifndef HAVE_OPENSSL_PROTOTYPE_TS_VERIFY_CTS_SET_CERTS

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

#endif



So if HAVE_OPENSSL_PROTOTYPE_TS_VERIFY_CTS_SET_CERTS isn't defined then

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

not allowed from 1.1.1 onwards because it is opaque.



My guess is the setting of

HAVE_OPENSSL_PROTOTYPE_TS_VERIFY_CTS_SET_CERTS is going wrong with

OpenSSL 3.X



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



   CHECK_FUNCTIONWITHHEADER_EXISTS("TS_VERIFY_CTS_set_certs(0,0)"

"openssl/ts.h" HAVE_OPENSSL_PROTOTYPE_TS_VERIFY_CTS_SET_CERTS)



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

instead a macro:



# ifndef OPENSSL_NO_DEPRECATED_3_0

#  define TS_VERIFY_CTS_set_certs(ctx, cert)

TS_VERIFY_CTX_set_certs(ctx,cert)

# endif



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

worked correctly there.



Matt







>

> dcmpstat:

> 16:36:48:689

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

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

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

> 16:36:48:753

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

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

>

> dcmtls:

> 16:35:16:392

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

> 16:35:16:392

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

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

>

> **

>

> **

>

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

> company 

>

> *From:*Tomas Mraz 

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

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

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

>

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

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

> TS_VERIFY_CTX_set* functions. If there are any particular accessors

> missing, please report that as a

>

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

>

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

>

> TS_VERIFY_CTX_set* functions.

>

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

>

> bug to

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

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

[Matt Caswell]

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

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

Here are the errors I see.

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

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



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

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


TS_VERIFY_CTS_set_certs(ctx, NULL);

Earlier on in that file we see this:

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

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


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


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

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


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


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

# endif

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


Matt





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

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

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

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

**

**

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


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

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


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

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

TS_VERIFY_CTX_set* functions.

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

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


Tomas Mraz, OpenSSL

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

wrote:













Hi All, 


 



I build and installed version 3.0.8 on Windows with Visual Studio



using the instructions provided.



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



would be found by the CMake for the



DCMTK toolkit version 3.6.8.



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



can’t find the definition ofTS_verify_ctx.



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


 



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



install package?



Thank.


 










 


 



Thom Bentley| Senior Software Engineer |



Medidata, a Dassault Systèmes company


 



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



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



and/or privileged.



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



email in error,



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



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



this email and all attachments,



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



responsibility for any use of or reliance on this email.







Please be informed that your personal data are processed according to



our data privacy policy as described on our website. Should 

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

[BENTLEY Thom via openssl-users]

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

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

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



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

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

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


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

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

TS_VERIFY_CTX_set* functions.



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

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





Tomas Mraz, OpenSSL





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

wrote:

>

>

>

> Hi All,

>

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

> using the instructions provided.

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

> would be found by the CMake for the

> DCMTK toolkit version 3.6.8.

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

> can’t find the definition ofTS_verify_ctx.

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

>

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

> install package?

> Thank.

>

>

>

>

>

> Thom Bentley| Senior Software Engineer |

> Medidata, a Dassault Systèmes company

>

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

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

> and/or privileged.

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

> email in error,

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

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

> this email and all attachments,

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

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

>

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

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

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

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

>

>



--

Tomáš Mráz, OpenSSL



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

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

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

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

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


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

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

[BENTLEY Thom via openssl-users]

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

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

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



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

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

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






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

> Hi All,

>

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

> the instructions provided.

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

> be found by the CMake for the

>

> DCMTK toolkit version 3.6.8.

>

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

> can’t find the definition of TS_verify_ctx.

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

>



What exactly is the error you are seeing?



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

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

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



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

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

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



Matt





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

> install package?

>

> Thank.

>

> **

>

> **

>

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

> company 

>

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

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

> and/or privileged.

>

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

> in error,

>

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

>

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

> email and all attachments,

>

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

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

>

>

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

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

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

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

> 

>

>

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

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

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

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

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


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

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

[Matt Caswell]

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

Hi All,

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


DCMTK toolkit version 3.6.8.

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

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



What exactly is the error you are seeing?

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


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


Matt


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


Thank.

**

**

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


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


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


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

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


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



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

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

[Tomas Mraz]

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

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


Tomas Mraz, OpenSSL


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

-- 
Tomáš Mráz, OpenSSL

Missing header file ts_local.h in install location.

[BENTLEY Thom via openssl-users]

Hi All,

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

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



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


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

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

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

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

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


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

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

[BENTLEY Thom via openssl-users]

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

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


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

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

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


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



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

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



Tomas Mraz, OpenSSL



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

>

>

>

> Thanks Tomas.

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

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

>

>

>

>

>

>

>

> --

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

> Systèmes company

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

>

>

>

>

> From:Tomas Mraz 

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

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

> 

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

> -prefix and --openssldir

>

>

>

>

>

> Hello, you have to use "--

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

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

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

>

> Hello,

>

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

>

> Regards,

>

> Tomas Mraz, OpenSSL

>

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

> wrote:

> >

> >

> >

> > Hi All,

> >

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

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

> > prefix=C:\OpenSSLInstallDir

> > VC-WIN64A`

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

> > (offending arg: VC-WIN64A)

> >

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

> > the

> > configure happens fine but the install fails.

> > Here are the steps after the reconfigure.

> > nmake clean

> > nmake

> > nmake test

> > nmake install.

> >

> > The install shows this error:

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

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

> > return code '0x2'

> > Stop.

> >

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

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

> > work.

> >

> > Thanks.

> >

> >

> >

> >

> > Thom Bentley| Senior Software Engineer |

> > Medidata, a Dassault Systèmes company

> >

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

> > the

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

> > confidential

> > and/or privileged.

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

> > email in error,

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

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

> > this email and all attachments,

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

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

> >

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

> > to

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

> > have

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

> > 3DS

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

> >

> >

>

> --

> Tomáš Mráz, OpenSSL

>

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

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

> and/or privileged.

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

> email in error,

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

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

> this email and all attachments,

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

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

>

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

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

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

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

>

>



--

Tomáš Mráz, OpenSSL



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

If you are not one of the named recipients or 

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

[Tomas Mraz]

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

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

Tomas Mraz, OpenSSL

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

-- 
Tomáš Mráz, OpenSSL

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

[BENTLEY Thom via openssl-users]

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

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


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

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

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


Hello,



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



Regards,



Tomas Mraz, OpenSSL



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

wrote:

>

>

>

> Hi All,

>

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

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

> VC-WIN64A`

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

> (offending arg: VC-WIN64A)

>

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

> configure happens fine but the install fails.

> Here are the steps after the reconfigure.

> nmake clean

> nmake

> nmake test

> nmake install.

>

> The install shows this error:

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

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

> return code '0x2'

> Stop.

>

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

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

> work.

>

> Thanks.

>

>

>

>

> Thom Bentley| Senior Software Engineer |

> Medidata, a Dassault Systèmes company

>

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

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

> and/or privileged.

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

> email in error,

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

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

> this email and all attachments,

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

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

>

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

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

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

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

>

>



--

Tomáš Mráz, OpenSSL



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

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

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

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

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


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

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

[Tomas Mraz]

Hello,

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

Regards,

Tomas Mraz, OpenSSL

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

-- 
Tomáš Mráz, OpenSSL

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

[BENTLEY Thom via openssl-users]

Hi All,

I get an error running `perl Configure --openssldir 
"C:\OpenSSLInstallDir\CommonFiles\SSL" --prefix=C:\OpenSSLInstallDir VC-WIN64A`
target already defined - C:\OpenSSLInstallDir\Common Files\SSL (offending arg: 
VC-WIN64A)

If I remove --openssldir "C:\OpenSSLInstallDir\CommonFiles\SSL", the configure 
happens fine but the install fails.
Here are the steps after the reconfigure.
nmake clean
nmake
nmake test
nmake install.

The install shows this error:
NMAKE : fatal error U1077: '"C:\Strawberry\perl\bin\perl.exe" 
".\util\mkdir-p.pl" "C:\Program Files\Common Files\SSL\certs"' : return code 
'0x2'
Stop.

What step did I miss or is this a bug?  I thought I could override the common 
files location with -openssldir but that doesn't seem to work.

Thanks.


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


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

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

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

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

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


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

Re: Syntax of OID values

[Neil Horman]

I believe the oid_file key in the config is used by the ca and req applets
and is meant to be a value rather than a section (i.e. oid_file =
/path/to/oid/file/name)

To do what I believe you are trying to do above, you need to follow the
directions here:
https://www.openssl.org/docs/man1.1.1/man5/config.html

by assigning an oid_section like this:
oid_section = my_oid_section_name

And then creating the section:
[my_oid_section_name]
 some_new_oid = 1.2.3.4

On Thu, Jun 27, 2024 at 1:48 AM Dvorcovoy Dmitry V. via openssl-users <
openssl-users@openssl.org> wrote:

> I want to make my own tiny rootca.
> There are problem with supporting OIDS. I found in documentation about
> oid_file, but can not decode syntax of values.
> DER: works fine, but I want to use more readeable format.
>
> All I can find is the same docs without a tiny working example how to use
> my defined oids.
> sample:
> [oid_file]
>  1.3.6.1.4.1.311.21.1 msCAversion XCN_OID_CERTSRV_CA_VERSION
>  1.3.6.1.4.1.311.21.4 msCRLNextPublish XCN_OID_CRL_NEXT_PUBLISH
>
> [ca.conf]
>  oid_file =oid.txt
>  ...
> [ crl_ext ]
> authorityKeyIdentifier=keyid:always
> msCAversion = DER:020101
> msCRLNextPublish = DER:170D3234303930393131333635395A
>
> with these options all works ok.
> >openssl ca -config ca.conf -gencrl -crlexts crl_ext -out crl.pem
>
> but when I try anything like this:
>  msCAversion = 1
>  msCAversion = INT:01
>  msCAversion = INTEGER:0x01
> (and many other combinations)
>
> I'll got the same error:
> Using configuration from ca.conf
> Error checking CRL extension section crl_ext
> 00CEC9A0FA7F:error:1181:X509 V3 routines:do_ext_nconf:unknown
> extension:crypto/x509/v3_conf.c:92:
> 00CEC9A0FA7F:error:1180:X509 V3
> routines:X509V3_EXT_nconf_int:error in
> extension:crypto/x509/v3_conf.c:48:section=crl_ext, name=msCAversion,
> value=INTEGER:0x01
>
> Same with datetime, there are no help about it's format:
> msCRLNextPublish =UTC
> =: UTCTIME:"2024-Sep-09 11:36:59"
>  =ANS1.UTCTIME
>
> How to properly fromat values and please, include it with examples to
> documentation?
>
> And what to do to make -text outpul with readeable format, not just dump
> of OIDs? I think, there have to be some global OID config file, but where
> is it?
>

OpenSSL Security Advisory

[Matt Caswell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

OpenSSL Security Advisory [27th June 2024]
==

SSL_select_next_proto buffer overread (CVE-2024-5535)
=

Severity: Low

Issue summary: Calling the OpenSSL API function SSL_select_next_proto with an
empty supported client protocols buffer may cause a crash or memory contents to
be sent to the peer.

Impact summary: A buffer overread can have a range of potential consequences
such as unexpected application beahviour or a crash. In particular this issue
could result in up to 255 bytes of arbitrary private data from memory being sent
to the peer leading to a loss of confidentiality. However, only applications
that directly call the SSL_select_next_proto function with a 0 length list of
supported client protocols are affected by this issue. This would normally never
be a valid scenario and is typically not under attacker control but may occur by
accident in the case of a configuration or programming error in the calling
application.

The OpenSSL API function SSL_select_next_proto is typically used by TLS
applications that support ALPN (Application Layer Protocol Negotiation) or NPN
(Next Protocol Negotiation). NPN is older, was never standardised and
is deprecated in favour of ALPN. We believe that ALPN is significantly more
widely deployed than NPN. The SSL_select_next_proto function accepts a list of
protocols from the server and a list of protocols from the client and returns
the first protocol that appears in the server list that also appears in the
client list. In the case of no overlap between the two lists it returns the
first item in the client list. In either case it will signal whether an overlap
between the two lists was found. In the case where SSL_select_next_proto is
called with a zero length client list it fails to notice this condition and
returns the memory immediately following the client list pointer (and reports
that there was no overlap in the lists).

This function is typically called from a server side application callback for
ALPN or a client side application callback for NPN. In the case of ALPN the list
of protocols supplied by the client is guaranteed by libssl to never be zero in
length. The list of server protocols comes from the application and should never
normally be expected to be of zero length. In this case if the
SSL_select_next_proto function has been called as expected (with the list
supplied by the client passed in the client/client_len parameters), then the
application will not be vulnerable to this issue. If the application has
accidentally been configured with a zero length server list, and has
accidentally passed that zero length server list in the client/client_len
parameters, and has additionally failed to correctly handle a "no overlap"
response (which would normally result in a handshake failure in ALPN) then it
will be vulnerable to this problem.

In the case of NPN, the protocol permits the client to opportunistically select
a protocol when there is no overlap. OpenSSL returns the first client protocol
in the no overlap case in support of this. The list of client protocols comes
from the application and should never normally be expected to be of zero length.
However if the SSL_select_next_proto function is accidentally called with a
client_len of 0 then an invalid memory pointer will be returned instead. If the
application uses this output as the opportunistic protocol then the loss of
confidentiality will occur.

This issue has been assessed as Low severity because applications are most
likely to be vulnerable if they are using NPN instead of ALPN - but NPN is not
widely used. It also requires an application configuration or programming error.
Finally, this issue would not typically be under attacker control making active
exploitation unlikely.

The FIPS modules in 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.

OpenSSL 3.3, 3.2, 3.1, 3.0, 1.1.1 and 1.0.2 are vulnerable to this issue.

OpenSSL 3.3 users should upgrade to OpenSSL 3.3.2 once it is released.

OpenSSL 3.2 users should upgrade to OpenSSL 3.2.3 once it is released.

OpenSSL 3.1 users should upgrade to OpenSSL 3.1.7 once it is released.

OpenSSL 3.0 users should upgrade to OpenSSL 3.0.15 once it is released.

OpenSSL 1.1.1 users should upgrade to OpenSSL 1.1.1za once it is released
(premium support customers only).

OpenSSL 1.0.2 users should upgrade to OpenSSL 1.0.2zk once it is released
(premium support customers only).

Due to the low severity of this issue we are not issuing new releases of
OpenSSL at this time. The fix will be included in the next releases when they
become available. The fix is also available in commit e86ac436f0 (for 3.3),
commit 99fb785a5f (for 3.2), commit 4ada436a19 (for 3.1) and commit cf6f91f612
(for 3.0) in the OpenSSL git repository. It is available to premium support
customers in commit b78ec0824d (for 1.1.1) and commit 

Syntax of OID values

[Dvorcovoy Dmitry V. via openssl-users]

I want to make my own tiny rootca.
There are problem with supporting OIDS. I found in documentation about 
oid_file, but can not decode syntax of values.
DER: works fine, but I want to use more readeable format.

All I can find is the same docs without a tiny working example how to use my 
defined oids.
sample:
[oid_file]
 1.3.6.1.4.1.311.21.1 msCAversion XCN_OID_CERTSRV_CA_VERSION
 1.3.6.1.4.1.311.21.4 msCRLNextPublish XCN_OID_CRL_NEXT_PUBLISH

[ca.conf]
 oid_file =oid.txt
 ...
[ crl_ext ]
authorityKeyIdentifier=keyid:always
msCAversion = DER:020101
msCRLNextPublish = DER:170D3234303930393131333635395A

with these options all works ok.
>openssl ca -config ca.conf -gencrl -crlexts crl_ext -out crl.pem

but when I try anything like this:
 msCAversion = 1
 msCAversion = INT:01
 msCAversion = INTEGER:0x01
(and many other combinations)

I'll got the same error:
Using configuration from ca.conf
Error checking CRL extension section crl_ext
00CEC9A0FA7F:error:1181:X509 V3 routines:do_ext_nconf:unknown 
extension:crypto/x509/v3_conf.c:92:
00CEC9A0FA7F:error:1180:X509 V3 routines:X509V3_EXT_nconf_int:error in
extension:crypto/x509/v3_conf.c:48:section=crl_ext, name=msCAversion, 
value=INTEGER:0x01

Same with datetime, there are no help about it's format:
msCRLNextPublish =UTC
=: UTCTIME:"2024-Sep-09 11:36:59"
 =ANS1.UTCTIME

How to properly fromat values and please, include it with examples to 
documentation?

And what to do to make -text outpul with readeable format, not just dump of 
OIDs? I think, there have to be some global OID config file, but where is it?

RE: Issue building after configuring for VC-WIN64A (version 3.0.8)

[BENTLEY Thom via openssl-users]

Thanks Neil.  Realized that shortly after posting.
I did a `nmake clean`.
I haven’t cloned the repo so I couldn’t use git clean
I’m running `nmake test` now.

I’m back to C++/C coding on Windows after not doing any for about 15-20 years.
Last was a little to build code to be wrapped for use in python on Linux.
Using docker build images to do the work is a bit cleaner than using Visual 
Studio at the command line.

Thanks again.



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

From: Neil Horman 
Sent: Wednesday, June 26, 2024 3:29 PM
To: BENTLEY Thom 
Cc: openssl-users@openssl.org
Subject: Re: Issue building after configuring for VC-WIN64A (version 3.0.8)

You will almost certainly need to preform an nmake distclean (or just run git 
clean on your tree) prior to reconfiguring. nmake is really bad about getting 
lost in dependency resolution. Its quite likely that there is a remaining 
object file

You will almost certainly need to preform an nmake distclean (or just run git 
clean on your tree) prior to reconfiguring.  nmake is really bad about getting 
lost in dependency resolution.  Its quite likely that there is a remaining 
object file somewhere that didn't get rebuilt for x64 when you ran your second 
configure.

Start with a clean tree, run vcvarsall.bat x64 to set up your tool chain, then 
Configure for VC-WIN64A and nmake, it should work fine.

On Wed, Jun 26, 2024 at 3:20 PM BENTLEY Thom via openssl-users 
mailto:openssl-users@openssl.org>> wrote:
Hi All,

I followed the instructions for building OpenSSL 3.0.8 at 
https://github.com/openssl/openssl/blob/openssl-3.0.8/NOTES-WINDOWS.md#native-builds-using-visual-c
The nmake step failed with the following error:
   cmd /C ""cl" /Zs /showIncludes  /Zi /Fdossl_static.pdb /Gs0 /GF /Gy /MD 
/W3 /wd4090 /nologo /O2 -I"crypto" -I"include" 
-I"providers\implementations\include" -I"providers\common\include" -D"L_ENDIAN" 
-D"OPENSSL_PIC" -D"OPENSSLDIR=\"C:\\Program Files\\Common Files\\SSL\"" 
-D"ENGINESDIR=\"C:\\Program Files\\OpenSSL\\lib\\engines-3\"" 
-D"MODULESDIR=\"C:\\Program Files\\OpenSSL\\lib\\ossl-modules\"" 
-D"OPENSSL_BUILDING_OPENSSL" -D"OPENSSL_SYS_WIN32" -D"WIN32_LEAN_AND_MEAN" 
-D"UNICODE" -D"_UNICODE" -D"_CRT_SECURE_NO_DEPRECATE" 
-D"_WINSOCK_DEPRECATED_NO_WARNINGS" -D"NDEBUG"   -DOPENSSL_BN_ASM_GF2m 
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_CPUID_OBJ 
-DOPENSSL_IA32_SSE2 "ssl\record\tls_pad.c" > ssl\record\libcommon-lib-tls_pad.d 
2>&1"
"lib" /nologo /out:providers\libcommon.lib 
@C:\Users\tbentley\AppData\Local\Temp\1\nmFF6D.tmp
IF EXIST .manifest DEL /F /Q .manifest
IF EXIST libcrypto-3-x64.dll DEL /F /Q libcrypto-3-x64.dll
cmd /C ""link" /nologo /debug /dll  /nologo /debug 
@C:\Users\tbentley\AppData\Local\Temp\1\nm96.tmp /implib:libcrypto.lib || (DEL 
/Q libcrypto-3-x64.* libcrypto.lib & EXIT 1)"
crypto\aes\libcrypto-shlib-aes_cfb.obj : fatal error LNK1112: module machine 
type 'x86' conflicts with target machine type 'x64'
Could Not Find C:\OpenSSL\openssl-3.0.8\openssl-3.0.8\libcrypto-3-x64.*
NMAKE : fatal error U1077: 'cmd /C ""link" /nologo /debug /dll  /nologo /debug 
@C:\Users\tbentley\AppData\Local\Temp\1\nm96.tmp /implib:libcrypto.lib || (DEL 
/Q libcrypto-3-x64.* libcrypto.lib & EXIT 1)"' : return code '0x1'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual 
Studio\2022\Professional\VC\Tools\MSVC\14.38.33130\bin\HostX86\x86\nmake.exe" / 
  _build_sw' : return code '0x2'
Stop.

I then realized that the wrong version of cl.exe was in the path so I ran:
"C:\Program Files\Microsoft Visual 
Studio\2022\Professional\VC\Auxiliary\Build\vcvarsall.bat" x64

I re-ran
perl Configure VC-WIN64A

and re-ran nmake.

I still have a mismatch error during linking

cmd /C ""cl" /Zs /showIncludes  /Zi /Fdossl_static.pdb /Gs0 /GF /Gy /MD 
/W3 /wd4090 /nologo /O2 -I"." -I"include" -I"apps\include" -D"L_ENDIAN" 
-D"OPENSSL_PIC" -D"OPENSSLDIR=\"C:\\Program Files\\Common Files\\SSL\"" 
-D"ENGINESDIR=\"C:\\Program Files\\OpenSSL\\lib\\engines-3\"" 
-D"MODULESDIR=\"C:\\Program Files\\OpenSSL\\lib\\ossl-modules\"" 
-D"OPENSSL_BUILDING_OPENSSL" -D"OPENSSL_SYS_WIN32" -D"WIN32_LEAN_AND_MEAN" 
-D"UNICODE" -D"_UNICODE" -D"_CRT_SECURE_NO_DEPRECATE" 
-D"_WINSOCK_DEPRECATED_NO_WARNINGS" -D"NDEBUG"   "apps\lib\tlssrp_depr.c" > 
apps\lib\libapps-lib-tlssrp_depr.d 2>&1"
"lib" /nologo /out:apps\libapps.lib 
@C:\Users\tbentley\AppData\Local\Temp\1\nm9792.tmp
apps\lib\libapps-lib-fmt.obj : fatal error LNK1112: module machine type 'x86' 
conflicts with target machine type 'x64'
NMAKE : fatal error U1077: '"lib" /nologo /out:apps\libapps.lib 

Re: Issue building after configuring for VC-WIN64A (version 3.0.8)

[Neil Horman]

You will almost certainly need to preform an nmake distclean (or just run
git clean on your tree) prior to reconfiguring.  nmake is really bad about
getting lost in dependency resolution.  Its quite likely that there is a
remaining object file somewhere that didn't get rebuilt for x64 when you
ran your second configure.

Start with a clean tree, run vcvarsall.bat x64 to set up your tool chain,
then Configure for VC-WIN64A and nmake, it should work fine.

On Wed, Jun 26, 2024 at 3:20 PM BENTLEY Thom via openssl-users <
openssl-users@openssl.org> wrote:

> Hi All,
>
>
>
> I followed the instructions for building OpenSSL 3.0.8 at
> https://github.com/openssl/openssl/blob/openssl-3.0.8/NOTES-WINDOWS.md#native-builds-using-visual-c
>
> The nmake step failed with the following error:
>cmd /C ""cl" /Zs /showIncludes  /Zi /Fdossl_static.pdb /Gs0 /GF /Gy
> /MD /W3 /wd4090 /nologo /O2 -I"crypto" -I"include"
> -I"providers\implementations\include" -I"providers\common\include"
> -D"L_ENDIAN" -D"OPENSSL_PIC" -D"OPENSSLDIR=\"C:\\Program Files\\Common
> Files\\SSL\"" -D"ENGINESDIR=\"C:\\Program Files\\OpenSSL\\lib\\engines-3\""
> -D"MODULESDIR=\"C:\\Program Files\\OpenSSL\\lib\\ossl-modules\""
> -D"OPENSSL_BUILDING_OPENSSL" -D"OPENSSL_SYS_WIN32" -D"WIN32_LEAN_AND_MEAN"
> -D"UNICODE" -D"_UNICODE" -D"_CRT_SECURE_NO_DEPRECATE"
> -D"_WINSOCK_DEPRECATED_NO_WARNINGS" -D"NDEBUG"   -DOPENSSL_BN_ASM_GF2m
> -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_CPUID_OBJ
> -DOPENSSL_IA32_SSE2 "ssl\record\tls_pad.c" >
> ssl\record\libcommon-lib-tls_pad.d 2>&1"
>
> "lib" /nologo /out:providers\libcommon.lib
> @C:\Users\tbentley\AppData\Local\Temp\1\nmFF6D.tmp
>
> IF EXIST .manifest DEL /F /Q .manifest
>
> IF EXIST libcrypto-3-x64.dll DEL /F /Q libcrypto-3-x64.dll
>
> cmd /C ""link" /nologo /debug /dll  /nologo /debug
> @C:\Users\tbentley\AppData\Local\Temp\1\nm96.tmp /implib:libcrypto.lib ||
> (DEL /Q libcrypto-3-x64.* libcrypto.lib & EXIT 1)"
>
> crypto\aes\libcrypto-shlib-aes_cfb.obj : fatal error LNK1112: module
> machine type 'x86' conflicts with target machine type 'x64'
>
> Could Not Find C:\OpenSSL\openssl-3.0.8\openssl-3.0.8\libcrypto-3-x64.*
>
> NMAKE : fatal error U1077: 'cmd /C ""link" /nologo /debug /dll  /nologo
> /debug @C:\Users\tbentley\AppData\Local\Temp\1\nm96.tmp
> /implib:libcrypto.lib || (DEL /Q libcrypto-3-x64.* libcrypto.lib & EXIT
> 1)"' : return code '0x1'
>
> Stop.
>
> NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual
> Studio\2022\Professional\VC\Tools\MSVC\14.38.33130\bin\HostX86\x86\nmake.exe"
> /   _build_sw' : return code '0x2'
>
> Stop.
>
>
>
> I then realized that the wrong version of cl.exe was in the path so I ran:
> "C:\Program Files\Microsoft Visual
> Studio\2022\Professional\VC\Auxiliary\Build\vcvarsall.bat" x64
>
>
>
> I re-ran
>
> perl Configure VC-WIN64A
>
>
>
> and re-ran nmake.
>
> I still have a mismatch error during linking
>
> cmd /C ""cl" /Zs /showIncludes  /Zi /Fdossl_static.pdb /Gs0 /GF
> /Gy /MD /W3 /wd4090 /nologo /O2 -I"." -I"include" -I"apps\include"
> -D"L_ENDIAN" -D"OPENSSL_PIC" -D"OPENSSLDIR=\"C:\\Program Files\\Common
> Files\\SSL\"" -D"ENGINESDIR=\"C:\\Program Files\\OpenSSL\\lib\\engines-3\""
> -D"MODULESDIR=\"C:\\Program Files\\OpenSSL\\lib\\ossl-modules\""
> -D"OPENSSL_BUILDING_OPENSSL" -D"OPENSSL_SYS_WIN32" -D"WIN32_LEAN_AND_MEAN"
> -D"UNICODE" -D"_UNICODE" -D"_CRT_SECURE_NO_DEPRECATE"
> -D"_WINSOCK_DEPRECATED_NO_WARNINGS" -D"NDEBUG"   "apps\lib\tlssrp_depr.c" >
> apps\lib\libapps-lib-tlssrp_depr.d 2>&1"
>
> "lib" /nologo /out:apps\libapps.lib
> @C:\Users\tbentley\AppData\Local\Temp\1\nm9792.tmp
>
> apps\lib\libapps-lib-fmt.obj : fatal error LNK1112: module machine type
> 'x86' conflicts with target machine type 'x64'
>
> NMAKE : fatal error U1077: '"lib" /nologo /out:apps\libapps.lib
> @C:\Users\tbentley\AppData\Local\Temp\1\nm9792.tmp' : return code '0x458'
>
> Stop.
>
> NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual
> Studio\2022\Professional\VC\Tools\MSVC\14.38.33130\bin\HostX64\x64\nmake.exe"
> /   _build_sw' : return code '0x2'
>
> Stop.
>
>
>
> If I run cl.exe I see:
> Microsoft (R) C/C++ Optimizing Compiler Version 19.38.33133 for x64
>
> Copyright (C) Microsoft Corporation.  All rights reserved.
>
>
>
> Thanks.
>
>
>
>
>
>
>
>
>
> *Thom Bentley *| Senior Software Engineer | Medidata, a Dassault Systèmes
> company 
>
>
>
> This email and any attachments are intended solely for the use of the
> individual or entity to whom it is addressed and may be confidential and/or
> privileged.
>
> If you are not one of the named recipients or have received this email in
> error,
>
> (i) you should not read, disclose, or copy it,
>
> (ii) please notify sender of your receipt by reply email and delete this
> email and all attachments,
>
> (iii) Dassault Systèmes does not accept or assume any liability or
> responsibility for any use of or 

RE: Issue building after configuring for VC-WIN64A (version 3.0.8)

[Michael Wojcik via openssl-users]

Did you do an "nmake clean" after switching to the correct compiler? You need 
to get rid of those 32-bit objects, or you'll continue to have a machine-type 
mismatch.

--
Michael Wojcik
Rocket Software

Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

Issue building after configuring for VC-WIN64A (version 3.0.8)

[BENTLEY Thom via openssl-users]

Hi All,

I followed the instructions for building OpenSSL 3.0.8 at 
https://github.com/openssl/openssl/blob/openssl-3.0.8/NOTES-WINDOWS.md#native-builds-using-visual-c
The nmake step failed with the following error:
   cmd /C ""cl" /Zs /showIncludes  /Zi /Fdossl_static.pdb /Gs0 /GF /Gy /MD 
/W3 /wd4090 /nologo /O2 -I"crypto" -I"include" 
-I"providers\implementations\include" -I"providers\common\include" -D"L_ENDIAN" 
-D"OPENSSL_PIC" -D"OPENSSLDIR=\"C:\\Program Files\\Common Files\\SSL\"" 
-D"ENGINESDIR=\"C:\\Program Files\\OpenSSL\\lib\\engines-3\"" 
-D"MODULESDIR=\"C:\\Program Files\\OpenSSL\\lib\\ossl-modules\"" 
-D"OPENSSL_BUILDING_OPENSSL" -D"OPENSSL_SYS_WIN32" -D"WIN32_LEAN_AND_MEAN" 
-D"UNICODE" -D"_UNICODE" -D"_CRT_SECURE_NO_DEPRECATE" 
-D"_WINSOCK_DEPRECATED_NO_WARNINGS" -D"NDEBUG"   -DOPENSSL_BN_ASM_GF2m 
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_CPUID_OBJ 
-DOPENSSL_IA32_SSE2 "ssl\record\tls_pad.c" > ssl\record\libcommon-lib-tls_pad.d 
2>&1"
"lib" /nologo /out:providers\libcommon.lib 
@C:\Users\tbentley\AppData\Local\Temp\1\nmFF6D.tmp
IF EXIST .manifest DEL /F /Q .manifest
IF EXIST libcrypto-3-x64.dll DEL /F /Q libcrypto-3-x64.dll
cmd /C ""link" /nologo /debug /dll  /nologo /debug 
@C:\Users\tbentley\AppData\Local\Temp\1\nm96.tmp /implib:libcrypto.lib || (DEL 
/Q libcrypto-3-x64.* libcrypto.lib & EXIT 1)"
crypto\aes\libcrypto-shlib-aes_cfb.obj : fatal error LNK1112: module machine 
type 'x86' conflicts with target machine type 'x64'
Could Not Find C:\OpenSSL\openssl-3.0.8\openssl-3.0.8\libcrypto-3-x64.*
NMAKE : fatal error U1077: 'cmd /C ""link" /nologo /debug /dll  /nologo /debug 
@C:\Users\tbentley\AppData\Local\Temp\1\nm96.tmp /implib:libcrypto.lib || (DEL 
/Q libcrypto-3-x64.* libcrypto.lib & EXIT 1)"' : return code '0x1'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual 
Studio\2022\Professional\VC\Tools\MSVC\14.38.33130\bin\HostX86\x86\nmake.exe" / 
  _build_sw' : return code '0x2'
Stop.

I then realized that the wrong version of cl.exe was in the path so I ran:
"C:\Program Files\Microsoft Visual 
Studio\2022\Professional\VC\Auxiliary\Build\vcvarsall.bat" x64

I re-ran
perl Configure VC-WIN64A

and re-ran nmake.

I still have a mismatch error during linking

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

If I run cl.exe I see:
Microsoft (R) C/C++ Optimizing Compiler Version 19.38.33133 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

Thanks.




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


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

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

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

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

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


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

Re: secp256r1 65 byte key size in packet capture

[Lokesh Chakka]

Is there a way to have all those man pages installed in my system.
I'm using Ubuntu 24.

On Wed, Jun 19, 2024, 17:49 Matt Caswell  wrote:

>
>
> On 19/06/2024 12:14, Lokesh Chakka wrote:
> > Now I need to explore C APIs for getting those keys as hex array.
> > Could you please suggest any good references for beginners.
>
> You would need to first load the key from the file to create an EVP_PKEY
> object. For example you could use the PEM_read_PUBKEY() function for
> this. See:
>
> https://www.openssl.org/docs/man3.3/man3/PEM_read_PUBKEY.html
>
> Once you have the key as an EVP_PKEY object, you can get the raw
> encoding as a char array in a format suitable for TLS using the
> EVP_PKEY_get1_encoded_public_key() function. See:
>
>
> https://www.openssl.org/docs/man3.3/man3/EVP_PKEY_get1_encoded_public_key.html
>
> Matt
>
>
>
> >
> > Regards
> > --
> > Lokesh Chakka.
> >
> >
> > On Wed, Jun 19, 2024 at 4:21 PM Matt Caswell  > > wrote:
> >
> >
> >
> > On 19/06/2024 09:15, Lokesh Chakka wrote:
> >  > hello,
> >  >
> >  > I'm trying to generate public/private keys with following
> commands:
> >  >
> >  > openssl ecparam -name secp256r1 -genkey -out pvtkey.pem
> >  > openssl ec -in pvtkey.pem -pubout
> >  >
> >  > I'm seeing the sizeof private key as 164 bytes and public key as
> > 124 bytes.
> >  >
> >  > In a wireshark capture( attached ), I'm seeing key length as 65
> > bytes.
> >
> > What you are doing is confusing. You have generated public/private
> key
> > pair for secp256r1 - but the wireshark capture you show seems to be
> the
> > key share from a TLSv1.3 handshake. TLSv1.3 key shares are ephemeral
> so
> > - you'll get a different key share every time. You don't need to
> create
> > a public/private key for this. OpenSSL does it for you.
> >
> > Anyway. Taking the key that you generated:
> >
> > -BEGIN PUBLIC KEY-
> > MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEVSmp4UnlQbzbe6eopByeEUzkmYHP
> > GgaKvSt/xdAgvDp7FXKTpST8UM9LpF8f4JETOXgDDGvNlIDqVFo+T0hdtQ==
> > -END PUBLIC KEY-
> >
> > This is just a PEM encoding of the real key (base 64 encoding of DER
> > structured data in PEM headers). Not sure where you get 124 bytes
> from,
> > but you can look take a look at the actual key data like this:
> >
> > $ openssl pkey -in /tmp/key.pem -pubin -noout -text
> > Public-Key: (256 bit)
> > pub:
> >   04:55:29:a9:e1:49:e5:41:bc:db:7b:a7:a8:a4:1c:
> >   9e:11:4c:e4:99:81:cf:1a:06:8a:bd:2b:7f:c5:d0:
> >   20:bc:3a:7b:15:72:93:a5:24:fc:50:cf:4b:a4:5f:
> >   1f:e0:91:13:39:78:03:0c:6b:cd:94:80:ea:54:5a:
> >   3e:4f:48:5d:b5
> > ASN1 OID: prime256v1
> > NIST CURVE: P-256
> >
> > This shows you the 65 bytes of raw public key data contained within
> the
> > key file.
> >
> > This key is in "uncompressed" format (the 04 byte at the start
> > indicates
> > this). Since it is uncompressed we then get an x and a y value to
> > indicate the point on the curve. Each of these are 32 bytes long (256
> > bits) - so this gives you 65 bytes in total.
> >
> > Matt
> >
> >
> >
> >  >
> >  > Can someone help me understand why the difference?
> >  >
> >  > Thanks & Regards
> >  > --
> >  > Lokesh Chakka.
> >
>

Re: 20240619 snapshots

[Richard Levitte]

The Doctor via openssl-users  writes:

> On Wed, Jun 19, 2024 at 09:53:19AM +0200, Tomas Mraz wrote:
>> They are there. Maybe you've looked too soon before the CDN caches were
>> synchronized.
>> 
>> 
>> On Tue, 2024-06-18 at 21:12 -0600, The Doctor via openssl-users wrote:
>> > Where are they?
>> 
>> -- 
>> Tom Mr??z, OpenSSL
>> 
>
> I use lynx

That's absolutely fine and makes no difference.  The snapshots got in
place, but probably became visible after you looked.

Cheers,
Richard

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

Re: secp256r1 65 byte key size in packet capture

[Matt Caswell]

On 19/06/2024 12:14, Lokesh Chakka wrote:

Now I need to explore C APIs for getting those keys as hex array.
Could you please suggest any good references for beginners.


You would need to first load the key from the file to create an EVP_PKEY 
object. For example you could use the PEM_read_PUBKEY() function for 
this. See:


https://www.openssl.org/docs/man3.3/man3/PEM_read_PUBKEY.html

Once you have the key as an EVP_PKEY object, you can get the raw 
encoding as a char array in a format suitable for TLS using the 
EVP_PKEY_get1_encoded_public_key() function. See:


https://www.openssl.org/docs/man3.3/man3/EVP_PKEY_get1_encoded_public_key.html

Matt





Regards
--
Lokesh Chakka.


On Wed, Jun 19, 2024 at 4:21 PM Matt Caswell > wrote:




On 19/06/2024 09:15, Lokesh Chakka wrote:
 > hello,
 >
 > I'm trying to generate public/private keys with following commands:
 >
 > openssl ecparam -name secp256r1 -genkey -out pvtkey.pem
 > openssl ec -in pvtkey.pem -pubout
 >
 > I'm seeing the sizeof private key as 164 bytes and public key as
124 bytes.
 >
 > In a wireshark capture( attached ), I'm seeing key length as 65
bytes.

What you are doing is confusing. You have generated public/private key
pair for secp256r1 - but the wireshark capture you show seems to be the
key share from a TLSv1.3 handshake. TLSv1.3 key shares are ephemeral so
- you'll get a different key share every time. You don't need to create
a public/private key for this. OpenSSL does it for you.

Anyway. Taking the key that you generated:

-BEGIN PUBLIC KEY-
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEVSmp4UnlQbzbe6eopByeEUzkmYHP
GgaKvSt/xdAgvDp7FXKTpST8UM9LpF8f4JETOXgDDGvNlIDqVFo+T0hdtQ==
-END PUBLIC KEY-

This is just a PEM encoding of the real key (base 64 encoding of DER
structured data in PEM headers). Not sure where you get 124 bytes from,
but you can look take a look at the actual key data like this:

$ openssl pkey -in /tmp/key.pem -pubin -noout -text
Public-Key: (256 bit)
pub:
      04:55:29:a9:e1:49:e5:41:bc:db:7b:a7:a8:a4:1c:
      9e:11:4c:e4:99:81:cf:1a:06:8a:bd:2b:7f:c5:d0:
      20:bc:3a:7b:15:72:93:a5:24:fc:50:cf:4b:a4:5f:
      1f:e0:91:13:39:78:03:0c:6b:cd:94:80:ea:54:5a:
      3e:4f:48:5d:b5
ASN1 OID: prime256v1
NIST CURVE: P-256

This shows you the 65 bytes of raw public key data contained within the
key file.

This key is in "uncompressed" format (the 04 byte at the start
indicates
this). Since it is uncompressed we then get an x and a y value to
indicate the point on the curve. Each of these are 32 bytes long (256
bits) - so this gives you 65 bytes in total.

Matt



 >
 > Can someone help me understand why the difference?
 >
 > Thanks & Regards
 > --
 > Lokesh Chakka.

Re: 20240619 snapshots

[The Doctor via openssl-users]

On Wed, Jun 19, 2024 at 09:53:19AM +0200, Tomas Mraz wrote:
> They are there. Maybe you've looked too soon before the CDN caches were
> synchronized.
> 
> 
> On Tue, 2024-06-18 at 21:12 -0600, The Doctor via openssl-users wrote:
> > Where are they?
> 
> -- 
> Tom Mr??z, OpenSSL
> 

I use lynx
-- 
Member - Liberal International This is doc...@nk.ca Ici doc...@nk.ca
Yahweh, King & country!Never Satan President Republic!Beware AntiChrist rising!
Look at Psalms 14 and 53 on Atheism ;
United Kingdom save the NAtion on 4 July 2024 vote Liberal Democrat

Re: secp256r1 65 byte key size in packet capture

[Lokesh Chakka]

Hi Matt,

I'm trying to craft a client hello packet using a C program. I'm learning
about these keys, openssl, TLS etc.

So

openssl ecparam -name secp256r1 -genkey -out pvtkey.pem
openssl ec -in pvtkey.pem -pubout -out pubkey.pem
openssl pkey -in pubkey.pem -pubin -noout -text

will give me the 65 bytes. Understood. Thanks alot.

Now I need to explore C APIs for getting those keys as hex array.
Could you please suggest any good references for beginners.

Regards
--
Lokesh Chakka.


On Wed, Jun 19, 2024 at 4:21 PM Matt Caswell  wrote:

>
>
> On 19/06/2024 09:15, Lokesh Chakka wrote:
> > hello,
> >
> > I'm trying to generate public/private keys with following commands:
> >
> > openssl ecparam -name secp256r1 -genkey -out pvtkey.pem
> > openssl ec -in pvtkey.pem -pubout
> >
> > I'm seeing the sizeof private key as 164 bytes and public key as 124
> bytes.
> >
> > In a wireshark capture( attached ), I'm seeing key length as 65 bytes.
>
> What you are doing is confusing. You have generated public/private key
> pair for secp256r1 - but the wireshark capture you show seems to be the
> key share from a TLSv1.3 handshake. TLSv1.3 key shares are ephemeral so
> - you'll get a different key share every time. You don't need to create
> a public/private key for this. OpenSSL does it for you.
>
> Anyway. Taking the key that you generated:
>
> -BEGIN PUBLIC KEY-
> MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEVSmp4UnlQbzbe6eopByeEUzkmYHP
> GgaKvSt/xdAgvDp7FXKTpST8UM9LpF8f4JETOXgDDGvNlIDqVFo+T0hdtQ==
> -END PUBLIC KEY-
>
> This is just a PEM encoding of the real key (base 64 encoding of DER
> structured data in PEM headers). Not sure where you get 124 bytes from,
> but you can look take a look at the actual key data like this:
>
> $ openssl pkey -in /tmp/key.pem -pubin -noout -text
> Public-Key: (256 bit)
> pub:
>  04:55:29:a9:e1:49:e5:41:bc:db:7b:a7:a8:a4:1c:
>  9e:11:4c:e4:99:81:cf:1a:06:8a:bd:2b:7f:c5:d0:
>  20:bc:3a:7b:15:72:93:a5:24:fc:50:cf:4b:a4:5f:
>  1f:e0:91:13:39:78:03:0c:6b:cd:94:80:ea:54:5a:
>  3e:4f:48:5d:b5
> ASN1 OID: prime256v1
> NIST CURVE: P-256
>
> This shows you the 65 bytes of raw public key data contained within the
> key file.
>
> This key is in "uncompressed" format (the 04 byte at the start indicates
> this). Since it is uncompressed we then get an x and a y value to
> indicate the point on the curve. Each of these are 32 bytes long (256
> bits) - so this gives you 65 bytes in total.
>
> Matt
>
>
>
> >
> > Can someone help me understand why the difference?
> >
> > Thanks & Regards
> > --
> > Lokesh Chakka.
>

Re: secp256r1 65 byte key size in packet capture

[Matt Caswell]

On 19/06/2024 09:15, Lokesh Chakka wrote:

hello,

I'm trying to generate public/private keys with following commands:

openssl ecparam -name secp256r1 -genkey -out pvtkey.pem
openssl ec -in pvtkey.pem -pubout

I'm seeing the sizeof private key as 164 bytes and public key as 124 bytes.

In a wireshark capture( attached ), I'm seeing key length as 65 bytes.


What you are doing is confusing. You have generated public/private key 
pair for secp256r1 - but the wireshark capture you show seems to be the 
key share from a TLSv1.3 handshake. TLSv1.3 key shares are ephemeral so 
- you'll get a different key share every time. You don't need to create 
a public/private key for this. OpenSSL does it for you.


Anyway. Taking the key that you generated:

-BEGIN PUBLIC KEY-
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEVSmp4UnlQbzbe6eopByeEUzkmYHP
GgaKvSt/xdAgvDp7FXKTpST8UM9LpF8f4JETOXgDDGvNlIDqVFo+T0hdtQ==
-END PUBLIC KEY-

This is just a PEM encoding of the real key (base 64 encoding of DER 
structured data in PEM headers). Not sure where you get 124 bytes from, 
but you can look take a look at the actual key data like this:


$ openssl pkey -in /tmp/key.pem -pubin -noout -text
Public-Key: (256 bit)
pub:
04:55:29:a9:e1:49:e5:41:bc:db:7b:a7:a8:a4:1c:
9e:11:4c:e4:99:81:cf:1a:06:8a:bd:2b:7f:c5:d0:
20:bc:3a:7b:15:72:93:a5:24:fc:50:cf:4b:a4:5f:
1f:e0:91:13:39:78:03:0c:6b:cd:94:80:ea:54:5a:
3e:4f:48:5d:b5
ASN1 OID: prime256v1
NIST CURVE: P-256

This shows you the 65 bytes of raw public key data contained within the 
key file.


This key is in "uncompressed" format (the 04 byte at the start indicates 
this). Since it is uncompressed we then get an x and a y value to 
indicate the point on the curve. Each of these are 32 bytes long (256 
bits) - so this gives you 65 bytes in total.


Matt





Can someone help me understand why the difference?

Thanks & Regards
--
Lokesh Chakka.

Re: secp256r1 65 byte key size in packet capture

[Lokesh Chakka]

Understood. Thanks alot.
But I'm still Not able to understand why it is 65 bytes in the key value.


Thanks & Regards
--
Lokesh Chakka.


On Wed, Jun 19, 2024 at 3:03 PM Tomas Mraz  wrote:

> You need to do base64 decoding to find out the real size of the ASN.1
> encoded data.
>
> Tomas Mraz, OpenSSL
>
> On Wed, 2024-06-19 at 14:58 +0530, Lokesh Chakka wrote:
> > hi,
> >
> > please check the following :
> >
> > =
> > =
> > $ openssl ecparam -name secp256r1 -genkey -out pvtkey.pem
> > using curve name prime256v1 instead of secp256r1
> > $ cat pvtkey.pem
> > -BEGIN EC PARAMETERS-
> > BggqhkjOPQMBBw==
> > -END EC PARAMETERS-
> > -BEGIN EC PRIVATE KEY-
> > MHcCAQEEIAXXAWUj/cUQT8pDLKp5r269mw58aTzr/hYAEXQZVQqUoAoGCCqGSM49
> > AwEHoUQDQgAEVSmp4UnlQbzbe6eopByeEUzkmYHPGgaKvSt/xdAgvDp7FXKTpST8
> > UM9LpF8f4JETOXgDDGvNlIDqVFo+T0hdtQ==
> > -END EC PRIVATE KEY-
> > $ openssl ec -in pvtkey.pem -pubout
> > read EC key
> > writing EC key
> > -BEGIN PUBLIC KEY-
> > MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEVSmp4UnlQbzbe6eopByeEUzkmYHP
> > GgaKvSt/xdAgvDp7FXKTpST8UM9LpF8f4JETOXgDDGvNlIDqVFo+T0hdtQ==
> > -END PUBLIC KEY-
> > =
> > =
> >
> > sizeof private key is 164 bytes and the public key is 124 bytes.
> >
> >
> > Thanks & Regards
> > --
> > Lokesh Chakka.
> >
> >
> > On Wed, Jun 19, 2024 at 2:28 PM Tomas Mraz  wrote:
> > > Hi Lokesh,
> > >
> > > I am not sure how do you count the sizes of 164 bytes and 124 bytes
> > > for
> > > the pem files.
> > >
> > > If I use -outform DER (and use -noout with the ecparam to avoid
> > > outputting the params because the private key already contains info
> > > about the params used) I see the following sizes for the DER
> > > encoded
> > > data:
> > >
> > > private key: 121 bytes
> > > public key: 91 bytes
> > >
> > > Given both files contain information about the group used and other
> > > ASN.1 encoding related stuff, and that the private key file
> > > contains 32
> > > bytes of the private key but also the encoded uncompressed public
> > > key
> > > of 65 bytes, this is fully expected.
> > >
> > > Tomas Mraz, OpenSSL
> > >
> > > On Wed, 2024-06-19 at 13:45 +0530, Lokesh Chakka wrote:
> > > > hello,
> > > >
> > > > I'm trying to generate public/private keys with following
> > > > commands:
> > > >
> > > > openssl ecparam -name secp256r1 -genkey -out pvtkey.pem
> > > > openssl ec -in pvtkey.pem -pubout
> > > >
> > > > I'm seeing the sizeof private key as 164 bytes and public key as
> > > > 124
> > > > bytes.
> > > >
> > > > In a wireshark capture( attached ), I'm seeing key length as 65
> > > > bytes.
> > > >
> > > > Can someone help me understand why the difference?
> > > >
> > > > Thanks & Regards
> > > > --
> > > > Lokesh Chakka.
> > >
>
> --
> Tomáš Mráz, OpenSSL
>
>

Re: secp256r1 65 byte key size in packet capture

[Tomas Mraz]

You need to do base64 decoding to find out the real size of the ASN.1
encoded data.

Tomas Mraz, OpenSSL

On Wed, 2024-06-19 at 14:58 +0530, Lokesh Chakka wrote:
> hi,
> 
> please check the following :
> 
> =
> =
> $ openssl ecparam -name secp256r1 -genkey -out pvtkey.pem
> using curve name prime256v1 instead of secp256r1
> $ cat pvtkey.pem 
> -BEGIN EC PARAMETERS-
> BggqhkjOPQMBBw==
> -END EC PARAMETERS-
> -BEGIN EC PRIVATE KEY-
> MHcCAQEEIAXXAWUj/cUQT8pDLKp5r269mw58aTzr/hYAEXQZVQqUoAoGCCqGSM49
> AwEHoUQDQgAEVSmp4UnlQbzbe6eopByeEUzkmYHPGgaKvSt/xdAgvDp7FXKTpST8
> UM9LpF8f4JETOXgDDGvNlIDqVFo+T0hdtQ==
> -END EC PRIVATE KEY-
> $ openssl ec -in pvtkey.pem -pubout
> read EC key
> writing EC key
> -BEGIN PUBLIC KEY-
> MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEVSmp4UnlQbzbe6eopByeEUzkmYHP
> GgaKvSt/xdAgvDp7FXKTpST8UM9LpF8f4JETOXgDDGvNlIDqVFo+T0hdtQ==
> -END PUBLIC KEY-
> =
> =
> 
> sizeof private key is 164 bytes and the public key is 124 bytes.
> 
> 
> Thanks & Regards
> --
> Lokesh Chakka.
> 
> 
> On Wed, Jun 19, 2024 at 2:28 PM Tomas Mraz  wrote:
> > Hi Lokesh,
> > 
> > I am not sure how do you count the sizes of 164 bytes and 124 bytes
> > for
> > the pem files.
> > 
> > If I use -outform DER (and use -noout with the ecparam to avoid
> > outputting the params because the private key already contains info
> > about the params used) I see the following sizes for the DER
> > encoded
> > data:
> > 
> > private key: 121 bytes
> > public key: 91 bytes
> > 
> > Given both files contain information about the group used and other
> > ASN.1 encoding related stuff, and that the private key file
> > contains 32
> > bytes of the private key but also the encoded uncompressed public
> > key
> > of 65 bytes, this is fully expected.
> > 
> > Tomas Mraz, OpenSSL
> > 
> > On Wed, 2024-06-19 at 13:45 +0530, Lokesh Chakka wrote:
> > > hello,
> > > 
> > > I'm trying to generate public/private keys with following
> > > commands:
> > > 
> > > openssl ecparam -name secp256r1 -genkey -out pvtkey.pem
> > > openssl ec -in pvtkey.pem -pubout
> > > 
> > > I'm seeing the sizeof private key as 164 bytes and public key as
> > > 124
> > > bytes.
> > > 
> > > In a wireshark capture( attached ), I'm seeing key length as 65
> > > bytes.
> > > 
> > > Can someone help me understand why the difference?
> > > 
> > > Thanks & Regards
> > > --
> > > Lokesh Chakka.
> > 

-- 
Tomáš Mráz, OpenSSL

Re: secp256r1 65 byte key size in packet capture

[Lokesh Chakka]

hi,

please check the following :

==
$ openssl ecparam -name secp256r1 -genkey -out pvtkey.pem
using curve name prime256v1 instead of secp256r1
$ cat pvtkey.pem
-BEGIN EC PARAMETERS-
BggqhkjOPQMBBw==
-END EC PARAMETERS-
-BEGIN EC PRIVATE KEY-
MHcCAQEEIAXXAWUj/cUQT8pDLKp5r269mw58aTzr/hYAEXQZVQqUoAoGCCqGSM49
AwEHoUQDQgAEVSmp4UnlQbzbe6eopByeEUzkmYHPGgaKvSt/xdAgvDp7FXKTpST8
UM9LpF8f4JETOXgDDGvNlIDqVFo+T0hdtQ==
-END EC PRIVATE KEY-
$ openssl ec -in pvtkey.pem -pubout
read EC key
writing EC key
-BEGIN PUBLIC KEY-
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEVSmp4UnlQbzbe6eopByeEUzkmYHP
GgaKvSt/xdAgvDp7FXKTpST8UM9LpF8f4JETOXgDDGvNlIDqVFo+T0hdtQ==
-END PUBLIC KEY-
==

sizeof private key is 164 bytes and the public key is 124 bytes.


Thanks & Regards
--
Lokesh Chakka.


On Wed, Jun 19, 2024 at 2:28 PM Tomas Mraz  wrote:

> Hi Lokesh,
>
> I am not sure how do you count the sizes of 164 bytes and 124 bytes for
> the pem files.
>
> If I use -outform DER (and use -noout with the ecparam to avoid
> outputting the params because the private key already contains info
> about the params used) I see the following sizes for the DER encoded
> data:
>
> private key: 121 bytes
> public key: 91 bytes
>
> Given both files contain information about the group used and other
> ASN.1 encoding related stuff, and that the private key file contains 32
> bytes of the private key but also the encoded uncompressed public key
> of 65 bytes, this is fully expected.
>
> Tomas Mraz, OpenSSL
>
> On Wed, 2024-06-19 at 13:45 +0530, Lokesh Chakka wrote:
> > hello,
> >
> > I'm trying to generate public/private keys with following commands:
> >
> > openssl ecparam -name secp256r1 -genkey -out pvtkey.pem
> > openssl ec -in pvtkey.pem -pubout
> >
> > I'm seeing the sizeof private key as 164 bytes and public key as 124
> > bytes.
> >
> > In a wireshark capture( attached ), I'm seeing key length as 65
> > bytes.
> >
> > Can someone help me understand why the difference?
> >
> > Thanks & Regards
> > --
> > Lokesh Chakka.
>
> --
> Tomáš Mráz, OpenSSL
>
>

Re: secp256r1 65 byte key size in packet capture

[Tomas Mraz]

Hi Lokesh,

I am not sure how do you count the sizes of 164 bytes and 124 bytes for
the pem files.

If I use -outform DER (and use -noout with the ecparam to avoid
outputting the params because the private key already contains info
about the params used) I see the following sizes for the DER encoded
data:

private key: 121 bytes
public key: 91 bytes

Given both files contain information about the group used and other
ASN.1 encoding related stuff, and that the private key file contains 32
bytes of the private key but also the encoded uncompressed public key
of 65 bytes, this is fully expected.

Tomas Mraz, OpenSSL

On Wed, 2024-06-19 at 13:45 +0530, Lokesh Chakka wrote:
> hello,
> 
> I'm trying to generate public/private keys with following commands:
> 
> openssl ecparam -name secp256r1 -genkey -out pvtkey.pem
> openssl ec -in pvtkey.pem -pubout
> 
> I'm seeing the sizeof private key as 164 bytes and public key as 124
> bytes.
> 
> In a wireshark capture( attached ), I'm seeing key length as 65
> bytes.
> 
> Can someone help me understand why the difference?
> 
> Thanks & Regards
> --
> Lokesh Chakka.

-- 
Tomáš Mráz, OpenSSL

secp256r1 65 byte key size in packet capture

[Lokesh Chakka]

hello,

I'm trying to generate public/private keys with following commands:

openssl ecparam -name secp256r1 -genkey -out pvtkey.pem
openssl ec -in pvtkey.pem -pubout

I'm seeing the sizeof private key as 164 bytes and public key as 124 bytes.

In a wireshark capture( attached ), I'm seeing key length as 65 bytes.

Can someone help me understand why the difference?

Thanks & Regards
--
Lokesh Chakka.

Re: 20240619 snapshots

[Tomas Mraz]

They are there. Maybe you've looked too soon before the CDN caches were
synchronized.


On Tue, 2024-06-18 at 21:12 -0600, The Doctor via openssl-users wrote:
> Where are they?

-- 
Tomáš Mráz, OpenSSL

20240619 snapshots

[The Doctor via openssl-users]

Where are they?
-- 
Member - Liberal International This is doc...@nk.ca Ici doc...@nk.ca
Yahweh, King & country!Never Satan President Republic!Beware AntiChrist rising!
Look at Psalms 14 and 53 on Atheism ;
United Kingdom save the NAtion on 4 July 2024 vote Liberal Democrat

RE: [EXTERNAL] - 32-bit OpenSSL binary found in Suprema BioStar 2 door access system

[Turritopsis Dohrnii Teo En Ming via openssl-users]

On Wednesday, April 17th, 2024 at 6:57 AM, Michael Wojcik via openssl-users 
 wrote:

> > From: Turritopsis Dohrnii Teo En Ming teo.en.m...@protonmail.com
> > Sent: Monday, 15 April, 2024 07:36
> > 
> > > > From: openssl-users openssl-users-boun...@openssl.org On Behalf Of
> > > > Turritopsis Dohrnii Teo En Ming via openssl-users
> > > > Sent: Saturday, 9 March, 2024 06:59
> > > > To: openssl-users@openssl.org
> > > > 
> > > > On 7 March 2024 Thursday, when I was installing new self-signed SSL
> > > > certificate for the door access system for a law firm in Singapore, I 
> > > > notice that
> > > > Suprema BioStar 2 also has 32-bit OpenSSL binary.
> > > > 
> > > > The path is:
> > > > 
> > > > C:\Program Files\BioStar 2(x64)\ta\OpenSSL-Win32\bin
> > > > 
> > > > I am wondering if I can install 64-bit OpenSSL binary from another 
> > > > packager.
> > > > Will there be any conflict?
> 
> > I am thinking of installing Third Party OpenSSL Related Binary 
> > Distributions like
> > FireDaemon.
> 
> 
> I can't comment on that; I don't know what it contains, or how its 
> installation process works.
> 
> > I think there shouldn't be a conflict.
> 
> 
> This is more a question about Windows and how it loads DLLs, than it is an 
> OpenSSL question.
> 
> Assuming BioStar 2 loads the OpenSSL DLLs using the normal Windows mechanism, 
> from EXEs in the same directory as those DLLs, then it should continue to 
> load its own OpenSSL DLLs. Windows puts the EXE's directory at the start of 
> the DLL search path when doing a normal implicit load, assuming no SxS 
> nonsense interferes. Though that said, it's odd that BioStar 2 puts the 
> OpenSSL DLLs in a "bin" directory (apparently) of their own. I can't say what 
> BioStar 2 is up to here; I have no idea how the developers of that package 
> expect things to work.
> 
> The other concern is whether any other programs which use OpenSSL will end up 
> loading it from the BioStar 2 OpenSSL-Win32\bin directory rather than the 
> FireDaemon installation directory, whatever that might be. Applications which 
> simply have an implicit dependency on the OpenSSL DLLs, or which do a 
> conventional LoadLibrary, will typically end up searching the directories in 
> their PATH environment value. So you would want to ensure that the FireDaemon 
> directory containing the OpenSSL DLLs is earlier in the PATH for at least 
> those applications, and probably for everything — assuming BioStar 2 does 
> something sensible like specify its library-loading source.
> 
> In short, it's impossible for anyone to say whether there will be a problem 
> without recreating your environment. This is a universal difficulty with 
> loading shared modules. The best approach for professional software is to 
> avoid using modules which might conflict, by being explicit with their 
> linking or using alternative file and symbol names or whatever. But many ISVs 
> do not take that precaution.
> 
> --
> Michael Wojcik

Dear Michael,

Noted with thanks.

Mr. Turritopsis Dohrnii Teo En Ming
Targeted Individual in Singapore

Re: New OpenSSL Releases

[Matt Caswell]

On 09/06/2024 19:59, Dennis Clarke via openssl-users wrote:

On 5/30/24 11:15, Michael Wojcik via openssl-users wrote:
From: openssl-users  On Behalf Of 
Dennis

Clarke via openssl-users
Sent: Thursday, 30 May, 2024 07:29

OKay, thank you. I guess today is a good day to test on a few oddball
system architectures. I suspect there are very very few people out there
running actual HPE Itanium hardware or big-endian IBM POWER and that
often raises a few bugs that slip under the radar.


Itanium is rare (we've stopped supporting it)...


Well I can report only two tests fail :

Test Summary Report
---
04-test_bio_dgram.t   (Wstat: 256 (exited 1) Tests: 1 
Failed: 1)

   Failed test:  1
   Non-zero exit status: 1
65-test_cmp_client.t  (Wstat: 256 (exited 1) Tests: 2 
Failed: 1)

   Failed test:  1
   Non-zero exit status: 1
Files=312, Tests=3685, 18523 wallclock secs (46.06 usr  1.22 sys + 
18271.89 cusr 170.74 csys = 18489.91 CPU)

Result: FAIL


So that is pretty cool on an Itanium :

garak$
garak$ uname -a
Linux garak 6.6.30-gentoo-ia64 #1 SMP Tue May 14 20:07:58 UTC 2024 ia64 
Madison GenuineIntel GNU/Linux

garak$

Now I am going to go digging and see where those tests fail. May be
something trivial.

garak$
garak$ find . | grep 'test_bio_dgram'
./test-runs/test_bio_dgram
./test/recipes/04-test_bio_dgram.t
garak$
garak$ find . | grep 'test_cmp_client'
./test-runs/test_cmp_client
./test/recipes/65-test_cmp_client_data
./test/recipes/65-test_cmp_client_data/client.csr
./test/recipes/65-test_cmp_client_data/client.key
./test/recipes/65-test_cmp_client_data/server.key
./test/recipes/65-test_cmp_client_data/server.crt
./test/recipes/65-test_cmp_client_data/client.crt
./test/recipes/65-test_cmp_client.t
garak$

No obvious output log files there.



Try this to give more verbose output for a specific test failure:

make TESTS=test_bio_dgram V=1 test


Matt

OpenSSL 3 support for status_request_v2

[James]

Hi, I have a requirement to support the TLS status_request_v2 extension for
TLS 1.2 (rfc6961) using OpenSSL 3.x...
Looking at the API I've successfully used SSL_CTX_add_custom_ext() to add
the extension to the client hello, my server code is also picking this and
generating the extension in the server hello, however I can't find an
option to create the certificate status message(after the certificate
message and before server key exchange).
SSL_set_tlsext_status_ocsp_resp() seems to do this but isn't used for
status_request_v2.
Is this the right starting point or is there another API/functions I should
be using? Are there hooks for being able to influence the messages between
server hello and server hello done?
or is there a patch... that already adds this?
Many thanks
James

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?

[Christian F. Gonzalez Di Antonio]

Hi Thomas,

Thank you very much, Understood.

I created a new branch with the change I created two versions:
1.  one more c++ style (
https://github.com/christiangda/LicenseValidator/blob/c988c226e3e998aebe840386525a364273f41807/src/License.cpp#L80
)
2. with the change you proposed (
https://github.com/christiangda/LicenseValidator/blob/c591e2174ad049f7e773092202bf627ec5862210/src/License.cpp#L79
)

and now in both versions, I have a new and similar error:

```
Failed to verify license
008C96F90100:error:0268:rsa routines:ossl_rsa_verify:bad
signature:crypto/rsa/rsa_sign.c:426:
008C96F90100:error:1C880004:Provider routines:rsa_verify:RSA
lib:providers/implementations/signature/rsa_sig.c:785:
License key is invalid
```
Do you have any idea of how to solve this new error? any guidance?



On Mon, Jun 10, 2024 at 11:52 PM Thomas Dwyer III via openssl-users <
openssl-users@openssl.org> wrote:

> 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
> 
>
> I'm writing an c++ program LicenseValidator ->
> https://github.com/christiangda/LicenseValidator
> 
>  to
> validate a hypothetical program license using OpenSSL 3.1 Library
> ,
> 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
> 
>  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
> 
> :
>
> 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, 

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 
 



I'm writing an c++ program LicenseValidator -> 
https://github.com/christiangda/LicenseValidator 
 to 
validate a hypothetical |program license| using OpenSSL 3.1 Library 
, 
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 
 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 
:


|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

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?

[Christian F. Gonzalez Di Antonio]

I posted this on
https://stackoverflow.com/questions/78604338/why-do-i-get-the-following-error-wrong-signature-length-when-i-try-to-validate

I'm writing an c++ program LicenseValidator ->
https://github.com/christiangda/LicenseValidator
 to validate a
hypothetical program license using OpenSSL 3.1 Library
, 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
 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

:

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: openssl hmac and key on the command line

[Viktor Dukhovni]

On Sat, Jun 08, 2024 at 08:12:57AM -0400, Neil Horman wrote:

> > I see someone at
> > https://github.com/openssl/openssl/issues/13382#issuecomment-1181577183
> > with a similar concern suggested -macopt keyfile:file

The requested feature (explicit keyfile option) makes sense to me.  Is
there a motivated volunteer to implement it?

-- 
Viktor.

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

Fwd: [.] ssl update needs rebuilds

[Steffen Nurpmeso]

Hello.

non-grata posting, but i think a fix would be a widely appreciated
clarification.  I think noloader is on this list, so i do not bcc
him.

--- Forwarded from Steffen Nurpmeso  ---
Date: Sun, 09 Jun 2024 01:58:54 +0200
Author: Steffen Nurpmeso 
..
 |>|>   Jun  7 23:41:16 outwall/smtpd[19222]: warning: run-time library \
 |>|>   vs. compile-time header version mismatch: OpenSSL 3.3.0 may not \
 |>|>   be compatible with OpenSSL 3.2.0
 |>  ...
 |>|[.] OpenSSL 3.2.0 and 3.3.0
 |>|are ABI and API compatible. I would not expect to see a warning or
 |>|error. See |tml>.
 |
 |Some irrelevant background: that document covers OpenSSL 3.0 and
 |later (earlier releases use a different versioning scheme).
 |
 |>|From the document under Minor Release:
 |>|
 |>|A minor release is indicated by changing the second number of the
 |>|version. A minor release can, and generally will, introduce new
 |>|features. However both the API and ABI will be preserved.
 |
 |That same document says under "Patch release":
 |
 |A patch release is indicated by changing the final number of
 |the version. A patch release will only contain bug and security
 |fixes. Both the API and ABI will remain compatible across patch
 |releases.
 |
 |Note that only the text for "Patch release" promises that the "Both
 |the API and ABI will remain compatible".

Hm, you have read the page, and i think Jeffrey is right in noting
that, effectively, the [.] log message is technically false.

However i also think the OpenSSL page is very confusing, as you
correctly point out, since

  For example, a program built with OpenSSL release 3.0.1 will be
  able to run with OpenSSL 3.1.0 but might not be able to take
  advantage of new features without modification.

how could a program compiled for 3.0.1 use features at all which
were introduced with a later minor version.
Btw they also say it *could* happen also here, with the same
"Exceptions to these rules require a vote by the OMC." clause they
use for API/ABI breakage for minor releases.

  ...
 |> [.] I must say, out of my head i have no idea
 |> whether it has always been like that for minor releases for one,
 |> and whether that is also true for LibreSSL, and the other SSL
 |> libraries that [.] possibly works with.  And [.] did
 |> use LibreSSL for some time in the past.
 ...
 -- End forward <20240608235854.g9q49DTf@steffen%sdaoden.eu>

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

Re: openssl hmac and key on the command line

[Carson Gaspar]

On 6/8/2024 5:12 AM, Neil Horman wrote:
printf '%s' "hello" | LD_LIBRARY_PATH=$PWD ./apps/openssl dgst -sha1 
-hmac $(cat key.txt)

SHA1(stdin)= c3b424548c3dbd02161a9541d89287e689f076d7


That will expose the key in the process args, so is NOT secure.

--

Carson

Re: openssl hmac and key on the command line

[Neil Horman]

the openssl-mac utility already contains such a option (though it doesn't
circumvent the issue as the option for the key is also passed on the
command line)

It seems some bash magic solves this problem though.  By putting your key
in a file, you can use command substitution to solve this:

nhorman@fedora:~/git/worktrees/windows$ printf '%s' "hello" |
LD_LIBRARY_PATH=$PWD ./apps/openssl dgst -sha1 -hmac
"AAA"
SHA1(stdin)= c3b424548c3dbd02161a9541d89287e689f076d7

printf '%s' "hello" | LD_LIBRARY_PATH=$PWD ./apps/openssl dgst -sha1 -hmac
$(cat key.txt)
SHA1(stdin)= c3b424548c3dbd02161a9541d89287e689f076d7

Getting the key into the file without landing in the audit log is of course
an exercise left to the user

Neil


On Sat, Jun 8, 2024 at 7:05 AM Stephane Chazelas 
wrote:

> 2024-06-08 08:43:26 +0100, Stephane Chazelas:
> [...]
> > Would it be possible to have a: -macopt keyenv:varname and
> > -macopt keyexenv:varname for instance to be able to pass the
> > secret via environment variables instead (which on most systems
> > are a lot less public than command arguments)?
> [...]
>
> I see someone at
> https://github.com/openssl/openssl/issues/13382#issuecomment-1181577183
> with a similar concern suggested -macopt keyfile:file
>
> --
> Stephane
>

Re: openssl hmac and key on the command line

[Stephane Chazelas]

2024-06-08 08:43:26 +0100, Stephane Chazelas:
[...]
> Would it be possible to have a: -macopt keyenv:varname and
> -macopt keyexenv:varname for instance to be able to pass the
> secret via environment variables instead (which on most systems
> are a lot less public than command arguments)?
[...]

I see someone at
https://github.com/openssl/openssl/issues/13382#issuecomment-1181577183
with a similar concern suggested -macopt keyfile:file 

-- 
Stephane

Re: openssl hmac and key on the command line

[Stephane Chazelas]

2022-08-07 18:20:56 +0200, Francois:
[...]
> I am reading some doc instructing me to run
> 
> printf '%s' "${challenge}" | openssl dgst -sha1 -hmac ${APP_TOKEN}
> 
> Doing so would leak the APP_TOKEN on the command line arguments (so a
> user running a "ps" at the right time would see the APP_TOKEN in
> clear). Due to my machine setup,  programs started and their arguments
> also end up in an audit log.
> 
> I am reading the documentation on
> https://www.openssl.org/docs/manmaster/man1/openssl-dgst.html, that
> points at the preferred
> https://www.openssl.org/docs/manmaster/man1/openssl-mac.html
> , and all
> the examples have the key in clear text on the command line.
> 
> Is there an equivalent command I can run that will not leak the key?
[...]

Hello,

I had the exact same concern and found this post by Francois in
the mailing list archives.

I see it was never answered.

Does it mean there is currently no safe way to pass the hmac
secret to the openssl utility to do HMAC in shell scripts?

Would it be possible to have a: -macopt keyenv:varname and
-macopt keyexenv:varname for instance to be able to pass the
secret via environment variables instead (which on most systems
are a lot less public than command arguments)?

I'd generally welcome any move to deprecate all APIs that rely
on passing secrets on the command line.

Best regards,
Stephane

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, , 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.

When building openssl with mingw64, make test is hang up.

[anlex N]

Hello everyone, I want to contribute my source code to openssl, But I am in
trouble:

When building openssl with MinGW64, make test is hung up
.

For so many days, nobody has replied to me, I value your feedback.

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

[Viktor Dukhovni]

On Fri, May 31, 2024 at 07:47:40AM +, Vishal Kevat via openssl-users wrote:
> 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
> };

You've copied only the leading 128 bits of two of the standard
prime groups.  The above isn't the droid you're looking for.


https://isrc.iscas.ac.cn/gitlab/mirrors/github.com/wolfssl_wolfssl/-/raw/c9be50c3a0eadc7925f9ff987fe3d361b1a6e602/src/ssl.c

/* This sets a big number with the 768-bit prime from RFC 2409.
 *
 * bn  if not NULL then the big number structure is used. If NULL then a new
 * big number structure is created.
 *
 * Returns a WOLFSSL_BIGNUM structure on success and NULL with failure.
 */
WOLFSSL_BIGNUM* wolfSSL_DH_768_prime(WOLFSSL_BIGNUM* bn)
{
const char prm[] = {
"C90FDAA22168C234"
"C4C6628B80DC1CD129024E088A67CC74"
"020BBEA63B139B22514A08798E3404DD"
"EF9519B3CD3A431B302B0A6DF25F1437"
"4FE1356D6D51C245E485B576625E7EC6"
"F44C42E9A63A3620"
};
...
}

/* This sets a big number with the 1024-bit prime from RFC 2409.
 *
 * bn  if not NULL then the big number structure is used. If NULL then a new
 * big number structure is created.
 *
 * Returns a WOLFSSL_BIGNUM structure on success and NULL with failure.
 */
WOLFSSL_BIGNUM* wolfSSL_DH_1024_prime(WOLFSSL_BIGNUM* bn)
{
const char prm[] = {
"C90FDAA22168C234"
"C4C6628B80DC1CD129024E088A67CC74"
"020BBEA63B139B22514A08798E3404DD"
"EF9519B3CD3A431B302B0A6DF25F1437"
"4FE1356D6D51C245E485B576625E7EC6"
"F44C42E9A637ED6B0BFF5CB6F406B7ED"
"EE386BFB5A899FA5AE9F24117C4B1FE6"
"49286651ECE65381"
};
...
}

-- 
Viktor.

Re: Issue in DH Algorithm Keys Generation in OpenSSL 3.3.0

[Viktor Dukhovni]

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

[Viktor Dukhovni]

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: Need help on self test post failure - programmatically load FIPS provider

[Matt Caswell]

On 24/05/2024 16:57, murugesh pitchaiah wrote:

Thanks Matt for looking into this.

Here is the output:

  # openssl list --providers -provider fips -provider base

Providers:

   base

     name: OpenSSL Base Provider

     version: 3.0.9

     status: active

   fips

     name: OpenSSL FIPS Provider

     version: 3.0.9

     status: active



So this suggests that the fips provider is correctly installed and 
configured and is able to activate without problems. So its currently 
unclear why you can't do this programmatically.




Also please find the fipsmodule.conf file contents before and after 
fipsinstall which I missed to attach in previous mail:


before install fipsmodule.cnf is :


Err...so you already had a fips module installed before you ran 
fipsinstall, and you are replacing it with a new one?


Where did you put the new fips.so file? Were you overwriting the 
previous one?



Matt







After fips install :

  [fips_sect]

install-version = 1

conditional-errors = 1

security-checks = 1

module-mac = 
5E:4A:02:9F:6E:26:2F:FE:FD:4D:45:6A:7E:D1:18:18:59:9C:04:56:50:6C:59:FC:3B:2F:BE:39:D4:79:08:E3


install-mac = 
41:9C:38:C2:8F:59:09:43:2C:AA:2F:58:36:2D:D9:04:F9:6C:56:8B:09:E0:18:3A:2E:D6:CC:69:05:04:E1:11


install-status = INSTALL_SELF_TEST_KATS_RUN


Note: Removed the 'activate=1' manually.


Thanks,

Murugesh


On Fri, May 24, 2024 at 8:35 PM Matt Caswell > wrote:


What do you get by loading the provider via the "openssl list" command,
i.e. what is the output from:

$ openssl list --providers -provider fips -provider base


Matt

On 24/05/2024 15:48, murugesh pitchaiah wrote:
 > Thanks Neil for your response. Please find more details below.
 >
 > Yes we run fipsinstall and then edit the fipsmodule.conf file to
remove
 > the 'activate=1' line. Then try to programmatically load FIPS
provider.
 > Here are the details steps.
 > Once the device boots up , The device has fipsmoudle.cnfpresent in
 > /usr/lib/ssl-3 which does not have install_mac and
insatll_status. We
 > have edited openssl.cnf file as mentioned below:
 >
 >     |.include /usr/local/ssl/fipsmodule.cnf|
 >
 >     |[openssl_init]|
 >
 >     |providers = provider_sect|
 >
 >     |
 >     |
 >
 >     |[provider_sect]|
 >
 >     |fips = fips_sect|
 >
 >     |base = base_sect|
 >
 >     |
 >     |
 >
 >     |[base_sect]|
 >
 >     |activate = 1|
 >
 > We executed below command to install which also
 > generates/updates fipsmodule.cnf file
 >
 >       openssl fipsinstall -module /usr/lib/ossl-modules/fips.so -out
 >     /usr/lib/ssl-3/fipsmodule.cnf
 >
 >   The above command successfully executed and updated
install-status to
 > fipsmodule.cnf file. The resultant fipsmodule.cnf file is as follows:
 >
 >     [fips_sect]
 >
 >     activate = 1
 >
 >     install-version = 1
 >
 >     conditional-errors = 1
 >
 >     security-checks = 1
 >
 >     module-mac =
 >   
  5E:4A:02:9F:6E:26:2F:FE:FD:4D:45:6A:7E:D1:18:18:59:9C:04:56:50:6C:59:FC:3B:2F:BE:39:D4:79:08:E3

 >
 >     install-mac =
 >   
  41:9C:38:C2:8F:59:09:43:2C:AA:2F:58:36:2D:D9:04:F9:6C:56:8B:09:E0:18:3A:2E:D6:CC:69:05:04:E1:11

 >
 >     install-status = INSTALL_SELF_TEST_KATS_RUN
 >
 > Then we removed the line "activate = 1" from fipsmodule.cnf
file.  After
 > this we triggered the programatically load fips code, which
caused the
 > error:
 >
 >     >/*80D1CD65667F:error:1C8000D4:Provider
 >     routines:SELF_TEST_post:invalid /
 >
 >     >/state:../openssl-3.0.9/providers/fips/self_test.c:262:* /
 >
 >     >/*80D1CD65667F:error:1C8000D8:Provider /
 >
 >     >/routines:OSSL_provider_init_int:self test post /
 >
 >     >/failure:../openssl-3.0.9/providers/fips/fipsprov.c:707:* /
 >
 >     >/*80D1CD65667F:error:078C0105:common libcrypto /
 >
 >     >/routines:provider_init:init /
 >
 >     >/fail:../openssl-3.0.9/crypto/provider_core.c:932:name=fips* /
 >
 >     >/*Error loading FIPS provider.*/
 >
 >
 > Please share if we are missing something. Thanks in advance.
 >
 >
 > Regards,
 >
 > Murugesh
 >
 >
 >
 > On Fri, May 24, 2024 at 6:55 PM Neil Horman mailto:nhor...@openssl.org>
 > >> wrote:
 >
 >     I assume that, after building the openssl library you ran openssl
 >     fipsinstall?  i.e. you're not just using a previously generated
 >     fipsmodule.cnf file?  The above errors initially seem like self
 >     tests failed on the fips provider load, suggesting that the
 >     module-mac or 

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: Need help on self test post failure - programmatically load FIPS provider

[murugesh pitchaiah]

Hi Matt,

Could you please share any insights on why these errors seen on
programmatically loading fips provider :

*80D1CD65667F:error:1C8000D4:Provider routines:SELF_TEST_post:invalid
state:../openssl-3.0.9/providers/fips/self_test.c:262:*
*80D1CD65667F:error:1C8000D8:Provider
routines:OSSL_provider_init_int:self test post
failure:../openssl-3.0.9/providers/fips/fipsprov.c:707:*
*80D1CD65667F:error:078C0105:common libcrypto
routines:provider_init:init
fail:../openssl-3.0.9/crypto/provider_core.c:932:name=fips*
*Error loading FIPS provider.*


Code for loading fips:

#include 



int main(void)

{

OSSL_PROVIDER *fips;

OSSL_PROVIDER *base;



fips = OSSL_PROVIDER_load(NULL, "fips");

if (fips == NULL) {

printf("Failed to load FIPS provider\n");

exit(EXIT_FAILURE);

}

base = OSSL_PROVIDER_load(NULL, "base");

if (base == NULL) {

OSSL_PROVIDER_unload(fips);

printf("Failed to load base provider\n");

exit(EXIT_FAILURE);

}



/* Rest of application */



OSSL_PROVIDER_unload(base);

OSSL_PROVIDER_unload(fips);

exit(EXIT_SUCCESS);

}


Thanks,
Murugesh

On Fri, May 24, 2024 at 9:27 PM murugesh pitchaiah <
murugesh.pitcha...@gmail.com> wrote:

> Thanks Matt for looking into this.
>
> Here is the output:
>
>  # openssl list --providers -provider fips -provider base
>
> Providers:
>
>   base
>
> name: OpenSSL Base Provider
>
> version: 3.0.9
>
> status: active
>
>   fips
>
> name: OpenSSL FIPS Provider
>
> version: 3.0.9
>
> status: active
>
>
> Also please find the fipsmodule.conf file contents before and after
> fipsinstall which I missed to attach in previous mail:
>
> before install fipsmodule.cnf is :
>
>  # cat /usr/lib/ssl-3/fipsmodule.cnf
>
> [fips_sect]
>
> activate = 1
>
> conditional-errors = 1
>
> security-checks = 1
>
> module-mac =
> F9:2B:17:EB:57:57:C5:DA:4F:4B:BE:02:05:16:50:0A:4B:5F:02:C7:38:62:B4:36:DF:D1:6E:E1:BA:FA:12:69
>
>
> After fips install :
>
>  [fips_sect]
>
> install-version = 1
>
> conditional-errors = 1
>
> security-checks = 1
>
> module-mac =
> 5E:4A:02:9F:6E:26:2F:FE:FD:4D:45:6A:7E:D1:18:18:59:9C:04:56:50:6C:59:FC:3B:2F:BE:39:D4:79:08:E3
>
> install-mac =
> 41:9C:38:C2:8F:59:09:43:2C:AA:2F:58:36:2D:D9:04:F9:6C:56:8B:09:E0:18:3A:2E:D6:CC:69:05:04:E1:11
>
> install-status = INSTALL_SELF_TEST_KATS_RUN
>
>
> Note: Removed the 'activate=1' manually.
>
>
> Thanks,
>
> Murugesh
>
> On Fri, May 24, 2024 at 8:35 PM Matt Caswell  wrote:
>
>> What do you get by loading the provider via the "openssl list" command,
>> i.e. what is the output from:
>>
>> $ openssl list --providers -provider fips -provider base
>>
>>
>> Matt
>>
>> On 24/05/2024 15:48, murugesh pitchaiah wrote:
>> > Thanks Neil for your response. Please find more details below.
>> >
>> > Yes we run fipsinstall and then edit the fipsmodule.conf file to remove
>> > the 'activate=1' line. Then try to programmatically load FIPS provider.
>> > Here are the details steps.
>> > Once the device boots up , The device has fipsmoudle.cnfpresent in
>> > /usr/lib/ssl-3 which does not have install_mac and insatll_status. We
>> > have edited openssl.cnf file as mentioned below:
>> >
>> > |.include /usr/local/ssl/fipsmodule.cnf|
>> >
>> > |[openssl_init]|
>> >
>> > |providers = provider_sect|
>> >
>> > |
>> > |
>> >
>> > |[provider_sect]|
>> >
>> > |fips = fips_sect|
>> >
>> > |base = base_sect|
>> >
>> > |
>> > |
>> >
>> > |[base_sect]|
>> >
>> > |activate = 1|
>> >
>> > We executed below command to install which also
>> > generates/updates fipsmodule.cnf file
>> >
>> >   openssl fipsinstall -module /usr/lib/ossl-modules/fips.so -out
>> > /usr/lib/ssl-3/fipsmodule.cnf
>> >
>> >   The above command successfully executed and updated install-status to
>> > fipsmodule.cnf file. The resultant fipsmodule.cnf file is as follows:
>> >
>> > [fips_sect]
>> >
>> > activate = 1
>> >
>> > install-version = 1
>> >
>> > conditional-errors = 1
>> >
>> > security-checks = 1
>> >
>> > module-mac =
>> >
>>  
>> 5E:4A:02:9F:6E:26:2F:FE:FD:4D:45:6A:7E:D1:18:18:59:9C:04:56:50:6C:59:FC:3B:2F:BE:39:D4:79:08:E3
>> >
>> > install-mac =
>> >
>>  
>> 41:9C:38:C2:8F:59:09:43:2C:AA:2F:58:36:2D:D9:04:F9:6C:56:8B:09:E0:18:3A:2E:D6:CC:69:05:04:E1:11
>> >
>> > install-status = INSTALL_SELF_TEST_KATS_RUN
>> >
>> > Then we removed the line "activate = 1" from fipsmodule.cnf file.
>> After
>> > this we triggered the programatically load fips code, which caused the
>> > error:
>> >
>> > >/*80D1CD65667F:error:1C8000D4:Provider
>> > routines:SELF_TEST_post:invalid /
>> >
>> > >/state:../openssl-3.0.9/providers/fips/self_test.c:262:* /
>> >
>> > >/*80D1CD65667F:error:1C8000D8:Provider /
>> >
>> > >/routines:OSSL_provider_init_int:self test post /
>> >
>> > >/failure:../openssl-3.0.9/providers/fips/fipsprov.c:707:* /
>> >
>> > 

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

[Tomas Mraz]

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.

Regards,
Tomas Mraz, OpenSSL

On Wed, 2024-05-29 at 17:09 -0400, Dennis Clarke via openssl-users
wrote:
> 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 ?
> 
> 
> 

-- 
Tomáš Mráz, OpenSSL

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

OpenSSL Security Advisory

[Matt Caswell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

OpenSSL Security Advisory [28th May 2024]
=

Use After Free with SSL_free_buffers (CVE-2024-4741)


Severity: Low

Issue summary: Calling the OpenSSL API function SSL_free_buffers may cause
memory to be accessed that was previously freed in some situations

Impact summary: A use after free can have a range of potential consequences such
as the corruption of valid data, crashes or execution of arbitrary code.
However, only applications that directly call the SSL_free_buffers function are
affected by this issue. Applications that do not call this function are not
vulnerable. Our investigations indicate that this function is rarely used by
applications.

The SSL_free_buffers function is used to free the internal OpenSSL buffer used
when processing an incoming record from the network. The call is only expected
to succeed if the buffer is not currently in use. However, two scenarios have
been identified where the buffer is freed even when still in use.

The first scenario occurs where a record header has been received from the
network and processed by OpenSSL, but the full record body has not yet arrived.
In this case calling SSL_free_buffers will succeed even though a record has only
been partially processed and the buffer is still in use.

The second scenario occurs where a full record containing application data has
been received and processed by OpenSSL but the application has only read part of
this data. Again a call to SSL_free_buffers will succeed even though the buffer
is still in use.

While these scenarios could occur accidentally during normal operation a
malicious attacker could attempt to engineer a stituation where this occurs.
We are not aware of this issue being actively exploited.

The FIPS modules in 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.

OpenSSL 1.0.2 is also not affected by this issue.

OpenSSL 3.3, 3.2, 3.1, 3.0 and 1.1.1 are vulnerable to this issue.

OpenSSL 3.3 users should upgrade to OpenSSL 3.3.1 once it is released.

OpenSSL 3.2 users should upgrade to OpenSSL 3.2.2 once it is released.

OpenSSL 3.1 users should upgrade to OpenSSL 3.1.6 once it is released.

OpenSSL 3.0 users should upgrade to OpenSSL 3.0.14 once it is released.

OpenSSL 1.1.1 users should upgrade to OpenSSL 1.1.1y once it is released
(premium support customers only).

Due to the low severity of this issue we are not issuing new releases of
OpenSSL at this time. The fix will be included in the next releases when they
become available. The fix is also available in commit e5093133c3 (for 3.3),
commit c88c3de510 (for 3.2), commit 704f725b96 (for 3.1) and commit b3f0eb0a29
(for 3.0) in the OpenSSL git repository. It is available to premium support
customers in commit f7a045f314 (for 1.1.1).

This issue was reported on 10th April 2024 by William Ahern (Akamai). The fix
was developed by Matt Caswell and Watson Ladd (Akamai).

General Advisory Notes
==

URL for this Security Advisory:
https://www.openssl.org/news/secadv/20240528.txt

Note: the online version of the advisory may be updated with additional details
over time.

For details of OpenSSL severity classifications please see:
https://www.openssl.org/policies/secpolicy.html
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAmZV9w0ACgkQ2cTSbQ5g
RJFleggAunT15ijQEKk29rztc82qEl01c/mDCAKCNLD0WqCr/D00lIjYhOjAcj7W
f4h9c7N8TqX4fkc1pBmV3KMM4qCzMkNdFE+lxYiDn2A/HAsZgSmh+WGpcMju7obI
5TvaINrBZbndXTa3o+10Wo4QT7oVGji/WLwsc06QzofZRLWj7BxU1h7i2JDR9Gd/
SYkg5ivgwixAgMzxpy7nQetQYKAfl6spKSUDHDymkYk0ATTvr9P14pQ5+Sr2T/gT
V8V5uTOYcxjpJCRipUbUPDN5ZUy379thry3XmR9wd2GE0AeXoVOJQMpOVK7TDhzm
TFookLZ04kCDtSU6gM0XXI8WAoEDUQ==
=UFjh
-END PGP SIGNATURE-

New OpenSSL Releases

[Tomas Mraz]

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.

We will be also releasing extended support OpenSSL version
1.1.1y which will be available to premium support customers.

These releases will be made available on Tuesday 4th June 2024
between 1300-1700 UTC.

These are security-fix releases. The highest severity issue fixed in
each of these releases is Low:

https://www.openssl.org/policies/secpolicy.html

Yours
The OpenSSL Project Team



signature.asc
Description: This is a digitally signed message part

Re: Need help on self test post failure - programmatically load FIPS provider

[murugesh pitchaiah]

Thanks Matt for looking into this.

Here is the output:

 # openssl list --providers -provider fips -provider base

Providers:

  base

name: OpenSSL Base Provider

version: 3.0.9

status: active

  fips

name: OpenSSL FIPS Provider

version: 3.0.9

status: active


Also please find the fipsmodule.conf file contents before and after
fipsinstall which I missed to attach in previous mail:

before install fipsmodule.cnf is :

 # cat /usr/lib/ssl-3/fipsmodule.cnf

[fips_sect]

activate = 1

conditional-errors = 1

security-checks = 1

module-mac =
F9:2B:17:EB:57:57:C5:DA:4F:4B:BE:02:05:16:50:0A:4B:5F:02:C7:38:62:B4:36:DF:D1:6E:E1:BA:FA:12:69


After fips install :

 [fips_sect]

install-version = 1

conditional-errors = 1

security-checks = 1

module-mac =
5E:4A:02:9F:6E:26:2F:FE:FD:4D:45:6A:7E:D1:18:18:59:9C:04:56:50:6C:59:FC:3B:2F:BE:39:D4:79:08:E3

install-mac =
41:9C:38:C2:8F:59:09:43:2C:AA:2F:58:36:2D:D9:04:F9:6C:56:8B:09:E0:18:3A:2E:D6:CC:69:05:04:E1:11

install-status = INSTALL_SELF_TEST_KATS_RUN


Note: Removed the 'activate=1' manually.


Thanks,

Murugesh

On Fri, May 24, 2024 at 8:35 PM Matt Caswell  wrote:

> What do you get by loading the provider via the "openssl list" command,
> i.e. what is the output from:
>
> $ openssl list --providers -provider fips -provider base
>
>
> Matt
>
> On 24/05/2024 15:48, murugesh pitchaiah wrote:
> > Thanks Neil for your response. Please find more details below.
> >
> > Yes we run fipsinstall and then edit the fipsmodule.conf file to remove
> > the 'activate=1' line. Then try to programmatically load FIPS provider.
> > Here are the details steps.
> > Once the device boots up , The device has fipsmoudle.cnfpresent in
> > /usr/lib/ssl-3 which does not have install_mac and insatll_status. We
> > have edited openssl.cnf file as mentioned below:
> >
> > |.include /usr/local/ssl/fipsmodule.cnf|
> >
> > |[openssl_init]|
> >
> > |providers = provider_sect|
> >
> > |
> > |
> >
> > |[provider_sect]|
> >
> > |fips = fips_sect|
> >
> > |base = base_sect|
> >
> > |
> > |
> >
> > |[base_sect]|
> >
> > |activate = 1|
> >
> > We executed below command to install which also
> > generates/updates fipsmodule.cnf file
> >
> >   openssl fipsinstall -module /usr/lib/ossl-modules/fips.so -out
> > /usr/lib/ssl-3/fipsmodule.cnf
> >
> >   The above command successfully executed and updated install-status to
> > fipsmodule.cnf file. The resultant fipsmodule.cnf file is as follows:
> >
> > [fips_sect]
> >
> > activate = 1
> >
> > install-version = 1
> >
> > conditional-errors = 1
> >
> > security-checks = 1
> >
> > module-mac =
> >
>  
> 5E:4A:02:9F:6E:26:2F:FE:FD:4D:45:6A:7E:D1:18:18:59:9C:04:56:50:6C:59:FC:3B:2F:BE:39:D4:79:08:E3
> >
> > install-mac =
> >
>  
> 41:9C:38:C2:8F:59:09:43:2C:AA:2F:58:36:2D:D9:04:F9:6C:56:8B:09:E0:18:3A:2E:D6:CC:69:05:04:E1:11
> >
> > install-status = INSTALL_SELF_TEST_KATS_RUN
> >
> > Then we removed the line "activate = 1" from fipsmodule.cnf file.  After
> > this we triggered the programatically load fips code, which caused the
> > error:
> >
> > >/*80D1CD65667F:error:1C8000D4:Provider
> > routines:SELF_TEST_post:invalid /
> >
> > >/state:../openssl-3.0.9/providers/fips/self_test.c:262:* /
> >
> > >/*80D1CD65667F:error:1C8000D8:Provider /
> >
> > >/routines:OSSL_provider_init_int:self test post /
> >
> > >/failure:../openssl-3.0.9/providers/fips/fipsprov.c:707:* /
> >
> > >/*80D1CD65667F:error:078C0105:common libcrypto /
> >
> > >/routines:provider_init:init /
> >
> > >/fail:../openssl-3.0.9/crypto/provider_core.c:932:name=fips* /
> >
> > >/*Error loading FIPS provider.*/
> >
> >
> > Please share if we are missing something. Thanks in advance.
> >
> >
> > Regards,
> >
> > Murugesh
> >
> >
> >
> > On Fri, May 24, 2024 at 6:55 PM Neil Horman  > > wrote:
> >
> > I assume that, after building the openssl library you ran openssl
> > fipsinstall?  i.e. you're not just using a previously generated
> > fipsmodule.cnf file?  The above errors initially seem like self
> > tests failed on the fips provider load, suggesting that the
> > module-mac or install-mac is incorrect in your config
> > 'Neil
> >
> > On Fri, May 24, 2024 at 2:05 AM murugesh pitchaiah
> > mailto:murugesh.pitcha...@gmail.com>>
> > wrote:
> >
> > Hi,
> >
> > Need your help on using openssl fips provider
> > programmatically with openssl 3.0.9.
> >
> > Error seen:
> >
> > *80D1CD65667F:error:1C8000D4:Provider
> > routines:SELF_TEST_post:invalid
> > state:../openssl-3.0.9/providers/fips/self_test.c:262:*
> > *80D1CD65667F:error:1C8000D8:Provider
> > routines:OSSL_provider_init_int:self test post
> > failure:../openssl-3.0.9/providers/fips/fipsprov.c:707:*
> > 

Re: Need help on self test post failure - programmatically load FIPS provider

[Matt Caswell]

What do you get by loading the provider via the "openssl list" command, 
i.e. what is the output from:


$ openssl list --providers -provider fips -provider base


Matt

On 24/05/2024 15:48, murugesh pitchaiah wrote:

Thanks Neil for your response. Please find more details below.

Yes we run fipsinstall and then edit the fipsmodule.conf file to remove 
the 'activate=1' line. Then try to programmatically load FIPS provider. 
Here are the details steps.
Once the device boots up , The device has fipsmoudle.cnfpresent in 
/usr/lib/ssl-3 which does not have install_mac and insatll_status. We 
have edited openssl.cnf file as mentioned below:


|.include /usr/local/ssl/fipsmodule.cnf|

|[openssl_init]|

|providers = provider_sect|

|
|

|[provider_sect]|

|fips = fips_sect|

|base = base_sect|

|
|

|[base_sect]|

|activate = 1|

We executed below command to install which also 
generates/updates fipsmodule.cnf file


  openssl fipsinstall -module /usr/lib/ossl-modules/fips.so -out
/usr/lib/ssl-3/fipsmodule.cnf

  The above command successfully executed and updated install-status to 
fipsmodule.cnf file. The resultant fipsmodule.cnf file is as follows:


[fips_sect]

activate = 1

install-version = 1

conditional-errors = 1

security-checks = 1

module-mac =

5E:4A:02:9F:6E:26:2F:FE:FD:4D:45:6A:7E:D1:18:18:59:9C:04:56:50:6C:59:FC:3B:2F:BE:39:D4:79:08:E3

install-mac =

41:9C:38:C2:8F:59:09:43:2C:AA:2F:58:36:2D:D9:04:F9:6C:56:8B:09:E0:18:3A:2E:D6:CC:69:05:04:E1:11

install-status = INSTALL_SELF_TEST_KATS_RUN

Then we removed the line "activate = 1" from fipsmodule.cnf file.  After 
this we triggered the programatically load fips code, which caused the 
error:


>/*80D1CD65667F:error:1C8000D4:Provider
routines:SELF_TEST_post:invalid /

>/state:../openssl-3.0.9/providers/fips/self_test.c:262:* /

>/*80D1CD65667F:error:1C8000D8:Provider /

>/routines:OSSL_provider_init_int:self test post /

>/failure:../openssl-3.0.9/providers/fips/fipsprov.c:707:* /

>/*80D1CD65667F:error:078C0105:common libcrypto /

>/routines:provider_init:init /

>/fail:../openssl-3.0.9/crypto/provider_core.c:932:name=fips* /

>/*Error loading FIPS provider.*/


Please share if we are missing something. Thanks in advance.


Regards,

Murugesh



On Fri, May 24, 2024 at 6:55 PM Neil Horman > wrote:


I assume that, after building the openssl library you ran openssl
fipsinstall?  i.e. you're not just using a previously generated
fipsmodule.cnf file?  The above errors initially seem like self
tests failed on the fips provider load, suggesting that the
module-mac or install-mac is incorrect in your config
'Neil

On Fri, May 24, 2024 at 2:05 AM murugesh pitchaiah
mailto:murugesh.pitcha...@gmail.com>>
wrote:

Hi,

Need your help on using openssl fips provider
programmatically with openssl 3.0.9.

Error seen:

*80D1CD65667F:error:1C8000D4:Provider
routines:SELF_TEST_post:invalid
state:../openssl-3.0.9/providers/fips/self_test.c:262:*
*80D1CD65667F:error:1C8000D8:Provider
routines:OSSL_provider_init_int:self test post
failure:../openssl-3.0.9/providers/fips/fipsprov.c:707:*
*80D1CD65667F:error:078C0105:common libcrypto
routines:provider_init:init
fail:../openssl-3.0.9/crypto/provider_core.c:932:name=fips*
*Error loading FIPS provider.*

*
*
Steps:

Followed the steps @
https://www.openssl.org/docs/man3.0/man7/fips_module.html



#include 

int main(void)

{

     OSSL_PROVIDER *fips;

     OSSL_PROVIDER *base;

     fips = OSSL_PROVIDER_load(NULL, "fips");

     if (fips == NULL) {

     printf("Failed to load FIPS provider\n");

     exit(EXIT_FAILURE);

     }

     base = OSSL_PROVIDER_load(NULL, "base");

     if (base == NULL) {

     OSSL_PROVIDER_unload(fips);

     printf("Failed to load base provider\n");

     exit(EXIT_FAILURE);

     }

     /* Rest of application */

     OSSL_PROVIDER_unload(base);

     OSSL_PROVIDER_unload(fips);

     exit(EXIT_SUCCESS);

Re: Need help on self test post failure - programmatically load FIPS provider

[murugesh pitchaiah]

Thanks Neil for your response. Please find more details below.

Yes we run fipsinstall and then edit the fipsmodule.conf file to remove the
'activate=1' line. Then try to programmatically load FIPS provider. Here
are the details steps.
Once the device boots up , The device has fipsmoudle.cnf present in
/usr/lib/ssl-3 which does not have install_mac and insatll_status. We have
edited openssl.cnf file as mentioned below:

.include /usr/local/ssl/fipsmodule.cnf

[openssl_init]

providers = provider_sect


[provider_sect]

fips = fips_sect

base = base_sect


[base_sect]

activate = 1

We executed below command to install which also
generates/updates fipsmodule.cnf file

 openssl fipsinstall -module /usr/lib/ossl-modules/fips.so -out
/usr/lib/ssl-3/fipsmodule.cnf

 The above command successfully executed and updated install-status to
fipsmodule.cnf file. The resultant fipsmodule.cnf file is as follows:

[fips_sect]

activate = 1

install-version = 1

conditional-errors = 1

security-checks = 1

module-mac =
5E:4A:02:9F:6E:26:2F:FE:FD:4D:45:6A:7E:D1:18:18:59:9C:04:56:50:6C:59:FC:3B:2F:BE:39:D4:79:08:E3

install-mac =
41:9C:38:C2:8F:59:09:43:2C:AA:2F:58:36:2D:D9:04:F9:6C:56:8B:09:E0:18:3A:2E:D6:CC:69:05:04:E1:11

install-status = INSTALL_SELF_TEST_KATS_RUN

Then we removed the line "activate = 1" from fipsmodule.cnf file.  After
this we triggered the programatically load fips code, which caused the
error:

>* *80D1CD65667F:error:1C8000D4:Provider routines:SELF_TEST_post:invalid
*

>* state:../openssl-3.0.9/providers/fips/self_test.c:262:*
*

>* *80D1CD65667F:error:1C8000D8:Provider
*

>* routines:OSSL_provider_init_int:self test post
*

>* failure:../openssl-3.0.9/providers/fips/fipsprov.c:707:*
*

>* *80D1CD65667F:error:078C0105:common libcrypto
*

>* routines:provider_init:init
*

>* fail:../openssl-3.0.9/crypto/provider_core.c:932:name=fips*
*

>* *Error loading FIPS provider.**


Please share if we are missing something. Thanks in advance.


Regards,

Murugesh



On Fri, May 24, 2024 at 6:55 PM Neil Horman  wrote:

> I assume that, after building the openssl library you ran openssl
> fipsinstall?  i.e. you're not just using a previously generated
> fipsmodule.cnf file?  The above errors initially seem like self tests
> failed on the fips provider load, suggesting that the module-mac or
> install-mac is incorrect in your config
> 'Neil
>
> On Fri, May 24, 2024 at 2:05 AM murugesh pitchaiah <
> murugesh.pitcha...@gmail.com> wrote:
>
>> Hi,
>>
>> Need your help on using openssl fips provider programmatically with
>> openssl 3.0.9.
>>
>> Error seen:
>>
>> *80D1CD65667F:error:1C8000D4:Provider routines:SELF_TEST_post:invalid
>> state:../openssl-3.0.9/providers/fips/self_test.c:262:*
>> *80D1CD65667F:error:1C8000D8:Provider
>> routines:OSSL_provider_init_int:self test post
>> failure:../openssl-3.0.9/providers/fips/fipsprov.c:707:*
>> *80D1CD65667F:error:078C0105:common libcrypto
>> routines:provider_init:init
>> fail:../openssl-3.0.9/crypto/provider_core.c:932:name=fips*
>> *Error loading FIPS provider.*
>>
>>
>> Steps:
>>
>> Followed the steps @
>> https://www.openssl.org/docs/man3.0/man7/fips_module.html
>> 
>>
>> #include 
>>
>>
>>
>> int main(void)
>>
>> {
>>
>> OSSL_PROVIDER *fips;
>>
>> OSSL_PROVIDER *base;
>>
>>
>>
>> fips = OSSL_PROVIDER_load(NULL, "fips");
>>
>> if (fips == NULL) {
>>
>> printf("Failed to load FIPS provider\n");
>>
>> exit(EXIT_FAILURE);
>>
>> }
>>
>> base = OSSL_PROVIDER_load(NULL, "base");
>>
>> if (base == NULL) {
>>
>> OSSL_PROVIDER_unload(fips);
>>
>> printf("Failed to load base provider\n");
>>
>> exit(EXIT_FAILURE);
>>
>> }
>>
>>
>>
>> /* Rest of application */
>>
>>
>>
>> OSSL_PROVIDER_unload(base);
>>
>> OSSL_PROVIDER_unload(fips);
>>
>> exit(EXIT_SUCCESS);
>>
>> }
>>
>>
>> More info:
>>
>>
>> /usr/bin # openssl version -d
>>
>> OPENSSLDIR: "/usr/lib/ssl-3"
>>
>> /exos/bin # openssl version -a
>>
>> OpenSSL 3.0.9 30 May 2023 (Library: OpenSSL 3.0.9 30 May 2023)
>>
>> built on: Tue May 30 12:31:57 2023 UTC
>>
>> platform: linux-x86_64
>>
>> options:  bn(64,64)
>>
>> compiler: x86_64-poky-linux-gcc  -m64 -fstack-protector-strong  -O2
>> -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security
>> --sysroot=recipe-sysroot -O2 -pipe -g -feliminate-unused-debug-types
>> -fmacro-prefix-map=  -fdebug-prefix-map=
>>-fdebug-prefix-map=  -fdebug-prefix-map=
>>  -DOPENSSL_USE_NODELETE -DL_ENDIAN 

Re: Need help on self test post failure - programmatically load FIPS provider

[Neil Horman]

I assume that, after building the openssl library you ran openssl
fipsinstall?  i.e. you're not just using a previously generated
fipsmodule.cnf file?  The above errors initially seem like self tests
failed on the fips provider load, suggesting that the module-mac or
install-mac is incorrect in your config
'Neil

On Fri, May 24, 2024 at 2:05 AM murugesh pitchaiah <
murugesh.pitcha...@gmail.com> wrote:

> Hi,
>
> Need your help on using openssl fips provider programmatically with
> openssl 3.0.9.
>
> Error seen:
>
> *80D1CD65667F:error:1C8000D4:Provider routines:SELF_TEST_post:invalid
> state:../openssl-3.0.9/providers/fips/self_test.c:262:*
> *80D1CD65667F:error:1C8000D8:Provider
> routines:OSSL_provider_init_int:self test post
> failure:../openssl-3.0.9/providers/fips/fipsprov.c:707:*
> *80D1CD65667F:error:078C0105:common libcrypto
> routines:provider_init:init
> fail:../openssl-3.0.9/crypto/provider_core.c:932:name=fips*
> *Error loading FIPS provider.*
>
>
> Steps:
>
> Followed the steps @
> https://www.openssl.org/docs/man3.0/man7/fips_module.html
> 
>
> #include 
>
>
>
> int main(void)
>
> {
>
> OSSL_PROVIDER *fips;
>
> OSSL_PROVIDER *base;
>
>
>
> fips = OSSL_PROVIDER_load(NULL, "fips");
>
> if (fips == NULL) {
>
> printf("Failed to load FIPS provider\n");
>
> exit(EXIT_FAILURE);
>
> }
>
> base = OSSL_PROVIDER_load(NULL, "base");
>
> if (base == NULL) {
>
> OSSL_PROVIDER_unload(fips);
>
> printf("Failed to load base provider\n");
>
> exit(EXIT_FAILURE);
>
> }
>
>
>
> /* Rest of application */
>
>
>
> OSSL_PROVIDER_unload(base);
>
> OSSL_PROVIDER_unload(fips);
>
> exit(EXIT_SUCCESS);
>
> }
>
>
> More info:
>
>
> /usr/bin # openssl version -d
>
> OPENSSLDIR: "/usr/lib/ssl-3"
>
> /exos/bin # openssl version -a
>
> OpenSSL 3.0.9 30 May 2023 (Library: OpenSSL 3.0.9 30 May 2023)
>
> built on: Tue May 30 12:31:57 2023 UTC
>
> platform: linux-x86_64
>
> options:  bn(64,64)
>
> compiler: x86_64-poky-linux-gcc  -m64 -fstack-protector-strong  -O2
> -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security
> --sysroot=recipe-sysroot -O2 -pipe -g -feliminate-unused-debug-types
> -fmacro-prefix-map=  -fdebug-prefix-map=
>-fdebug-prefix-map=  -fdebug-prefix-map=
>  -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_BUILDING_OPENSSL
> -DNDEBUG
>
> OPENSSLDIR: "/usr/lib/ssl-3"
>
> ENGINESDIR: "/usr/lib/engines-3"
>
> MODULESDIR: "/usr/lib/ossl-modules"
>
> Seeding source: os-specific
>
> CPUINFO: N/A
>
>
> Attached the openssl and fips conf.
>
>
> Could you guys please check and share what is missing here? Any help would
> be appreciated.
>
>
> Thanks,
>
> Murugesh
>
>
>

Re: Blocking on a non-blocking socket?

[Matt Caswell]

On 24/05/2024 02:30, Wiebe Cazemier wrote:


Can you show me in the code where that is?


It's here:

https://github.com/openssl/openssl/blob/b9e084f139c53ce133e66aba2f523c680141c0e6/ssl/record/rec_layer_s3.c#L1038-L1054

The "retry" codepath occurs where we hit the "goto start".


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.


This situation does not occur. The "auto-retry" only occurs in the case 
where we have *successfully* read a non-application data record. If we 
get an EWOULDBLOCK then this is always propagated back to the application.



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


The "retry" here is the normal meaning of the English word, and does not 
refer to a "network" retry, i.e. we tried to read application data but 
actually got something else, so retry that attempt.


Matt

Need help on self test post failure - programmatically load FIPS provider

[murugesh pitchaiah]

Hi,

Need your help on using openssl fips provider programmatically with openssl
3.0.9.

Error seen:

*80D1CD65667F:error:1C8000D4:Provider routines:SELF_TEST_post:invalid
state:../openssl-3.0.9/providers/fips/self_test.c:262:*
*80D1CD65667F:error:1C8000D8:Provider
routines:OSSL_provider_init_int:self test post
failure:../openssl-3.0.9/providers/fips/fipsprov.c:707:*
*80D1CD65667F:error:078C0105:common libcrypto
routines:provider_init:init
fail:../openssl-3.0.9/crypto/provider_core.c:932:name=fips*
*Error loading FIPS provider.*


Steps:

Followed the steps @
https://www.openssl.org/docs/man3.0/man7/fips_module.html


#include 



int main(void)

{

OSSL_PROVIDER *fips;

OSSL_PROVIDER *base;



fips = OSSL_PROVIDER_load(NULL, "fips");

if (fips == NULL) {

printf("Failed to load FIPS provider\n");

exit(EXIT_FAILURE);

}

base = OSSL_PROVIDER_load(NULL, "base");

if (base == NULL) {

OSSL_PROVIDER_unload(fips);

printf("Failed to load base provider\n");

exit(EXIT_FAILURE);

}



/* Rest of application */



OSSL_PROVIDER_unload(base);

OSSL_PROVIDER_unload(fips);

exit(EXIT_SUCCESS);

}


More info:


/usr/bin # openssl version -d

OPENSSLDIR: "/usr/lib/ssl-3"

/exos/bin # openssl version -a

OpenSSL 3.0.9 30 May 2023 (Library: OpenSSL 3.0.9 30 May 2023)

built on: Tue May 30 12:31:57 2023 UTC

platform: linux-x86_64

options:  bn(64,64)

compiler: x86_64-poky-linux-gcc  -m64 -fstack-protector-strong  -O2
-D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security
--sysroot=recipe-sysroot -O2 -pipe -g -feliminate-unused-debug-types
-fmacro-prefix-map=  -fdebug-prefix-map=
   -fdebug-prefix-map=  -fdebug-prefix-map=
 -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_BUILDING_OPENSSL
-DNDEBUG

OPENSSLDIR: "/usr/lib/ssl-3"

ENGINESDIR: "/usr/lib/engines-3"

MODULESDIR: "/usr/lib/ossl-modules"

Seeding source: os-specific

CPUINFO: N/A


Attached the openssl and fips conf.


Could you guys please check and share what is missing here? Any help would
be appreciated.


Thanks,

Murugesh


fipsmodule.cnf
Description: Binary data


openssl.cnf
Description: Binary data

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?

[Detlef Vollmann]

On 5/24/24 03:30, Wiebe Cazemier via openssl-users wrote:

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


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.

Without SSL_MODE_AUTO_RETRY SSL_read would return after handling the
handshake data with 0 and SSL_WANT_READ.
I'm not sure how useful this is, but this is how I understand Matt.

  Detlef

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?

[rsbecker]

On Thursday, May 23, 2024 10:26 AM Matt Caswell wrote:
>On 23/05/2024 15:08, rsbec...@nexbridge.com wrote:
>> On Thursday, May 23, 2024 9:56 AM, Wiebe Cazemier wrote:
 From: "Neil Horman" 
 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.
>>
>> I may be incorrect here, but my interpretation is as follows:
>>
>> SSL_MODE_AUTO_RETRY on - if there is a packet ready to read on the socket, 
>> the
>packet is retrieved. Same for write. If not ready, because EWOULDBLOCK, the
>operation is retried automatically by OpenSSL.
>>
>> SSL_MODE_AUTO_RETRY off - if there is a packet ready to read on the socket, 
>> the
>packet is retrieved. Same for write. If not ready, the OpenSSL operation 
>reports an
>error.
>
>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). If
>SSL_MODE_AUTO_RETRY off it will not attempt to retry and the SSL_read() call 
>will
>fail and indicate SSL_ERROR_WANT_READ.
>
> From an application perspective, if SSL_MODE_AUTO_RETRY is off with a non-
>blocking socket, it is not possible to tell the difference between "no 
>record/only
>partial record is available" and "we tried to read application data but got a 
>non-
>application data record". They both result in SSL_read() failing and indicating
>SSL_ERROR_WANT_READ.
>
>For non-blocking mode it really doesn't make much difference to the 
>application.
>Either way it should not cause it to block.

Thanks Matt. That helps with my own understanding.

Re: Blocking on a non-blocking socket?

[Matt Caswell]

On 23/05/2024 15:08, rsbec...@nexbridge.com wrote:

On Thursday, May 23, 2024 9:56 AM, Wiebe Cazemier wrote:

From: "Neil Horman" 
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.


I may be incorrect here, but my interpretation is as follows:

SSL_MODE_AUTO_RETRY on - if there is a packet ready to read on the socket, the 
packet is retrieved. Same for write. If not ready, because EWOULDBLOCK, the 
operation is retried automatically by OpenSSL.

SSL_MODE_AUTO_RETRY off - if there is a packet ready to read on the socket, the 
packet is retrieved. Same for write. If not ready, the OpenSSL operation 
reports an error.


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). If SSL_MODE_AUTO_RETRY off it will not 
attempt to retry and the SSL_read() call will fail and indicate 
SSL_ERROR_WANT_READ.


From an application perspective, if SSL_MODE_AUTO_RETRY is off with a 
non-blocking socket, it is not possible to tell the difference between 
"no record/only partial record is available" and "we tried to read 
application data but got a non-application data record". They both 
result in SSL_read() failing and indicating SSL_ERROR_WANT_READ.


For non-blocking mode it really doesn't make much difference to the 
application. Either way it should not cause it to block.


Matt

RE: Blocking on a non-blocking socket?

[rsbecker]

On Thursday, May 23, 2024 9:56 AM, Wiebe Cazemier wrote:
>> From: "Neil Horman" 
>> 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.

I may be incorrect here, but my interpretation is as follows:

SSL_MODE_AUTO_RETRY on - if there is a packet ready to read on the socket, the 
packet is retrieved. Same for write. If not ready, because EWOULDBLOCK, the 
operation is retried automatically by OpenSSL.

SSL_MODE_AUTO_RETRY off - if there is a packet ready to read on the socket, the 
packet is retrieved. Same for write. If not ready, the OpenSSL operation 
reports an error.

Randall

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?

[Neil Horman]

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

On Thu, May 23, 2024 at 8:15 AM Wiebe Cazemier  wrote:

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

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

Re: Blocking on a non-blocking socket?

[Neil Horman]

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

Neil

On Wed, May 22, 2024 at 11:12 PM udhayakumar 
wrote:

> hi Wiebe Cazemier,
>
> The flag SSL_MODE_AUTO_RETRY will cause read/write operations to only
> return after the handshake and successful completion. if cable is unplugged
> connection got broken until re-authentication it's holding read/write
> operations i think.
>
>
> / udhay!.
>
> On 5/23/24 7:52 AM, Wiebe Cazemier via openssl-users wrote:
> > e only SSL modes I change from the default is that I
>

Suggestions to add complete record processing in OpenSSL

[Ravichandra]

Hi,
  I observed that openssl(3.2.1) currently doesn't provide a way(this is my
understanding :P) to do complete record processing in one go instead of
doing it in multiple APIs/functions. This record processing feature allows
for HW implementations to do complete SSL record processing without too
much of SW code. When i say complete record processing,

On TX,
Padding addition, MAC and Encrypt operation in one go in the SSL engine

On RX,
Remove padding, MAC verification and decrypt the SSL record

We plan to implement a complete record processing engine which does these
operations along with pipeline support. As per my understanding, the
following process can be used to achieve it.

   1. define a new struct record_functions_st rec_eng_tls_1_funcs as shown
   below.

struct record_functions_st rec_eng_tls_1_funcs = {

tls1_cipher, // This API becomes the core function where plain
text is changed into a SSL record including padding, MAC and
encryption

NULL, // No MAC API as we do both in the above function

/* Rest all function pointers are almost same */

};


   2.

   Introduce a new macro for enabling complete record processing (say
OPENSSL_RECORD_PROCESSING_ENGINE). When this macro is enabled, set
record_layer->funcs to rec_eng_tls_1_funcs, otherwise set it to
tls_1_funcs.
   3.

   The Ciphers will be marked as EVP_CIPH_FLAG_AEAD_CIPHER to allow
both MAC and encryption to be handled in the tls1_cipher() API.

Please suggest if the approach looks ok or if any changes are needed.

Thanks in advance
Ravichandra

Re: Blocking on a non-blocking socket?

[udhayakumar]

hi Wiebe Cazemier,

The flag SSL_MODE_AUTO_RETRY will cause read/write operations to only return 
after the handshake and successful completion. if cable is unplugged connection 
got broken until re-authentication it's holding read/write operations i think.


/ udhay!.

On 5/23/24 7:52 AM, Wiebe Cazemier via openssl-users wrote:

e only SSL modes I change from the default is that I