Autoconf and detecting if bio_st is defined or not

2022-03-25 Thread Philip Prindeville
Hi,

I was wondering if there was some sort of sentinel variable that tells us if 
 is exporting access to the bio_st structure, or not.

Thanks,

-Philip



Re: EVP_KDF-SSHKDF man page error?

2022-03-25 Thread Dr Paul Dale
The UTF8 type is a string and if its length is known, it doesn't need to 
be '\0' terminated.  So passing the address of a char works (it's a char 
* after all).


Thanks for the other fix.

Pauli

On 26/3/22 10:43 am, Kory Hamzeh wrote:
Thanks, Paul. I noticed the type values matched the RFC, but thought 
maybe it should be a string if that was the case.


I did find another issue:

|if (EVP_KDF_derive(kctx, out, &outlen, params) <= 0) |
|
|
The actual value of ‘outlen’ should be passed, not the address.

Kory


On Mar 25, 2022, at 4:01 PM, pa...@openssl.org wrote:

It is correct, the KDF is expecting the characters 'A' through 'F' 
here.  This is what is specified in the RFC: 
https://datatracker.ietf.org/doc/html/rfc4253#section-7.2


That line of code ought to have cast to (char *) or type defined 
simply as char, but it is essentially correct.



Pauli

On 26/3/22 5:11 am, Kory Hamzeh wrote:

Hi All,

If you look at the example SSH KDF code here:

https://www.openssl.org/docs/manmaster/man7/EVP_KDF-SSHKDF.html

Specifically, these lines:

 *p++ = OSSL_PARAM_construct_utf8_string(OSSL_KDF_PARAM_SSHKDF_TYPE,
 &type, sizeof(type));
 The variable ‘type’ is defined as a “const char”, so an 8 bit 
integer. The compiler spits out a warning on that line. Is the 
example code correct?


 I wonder if it should be calling OSSL_PARAM_construct_int() and 
‘type’ changed to ‘int’?


Thanks,
Kory







Re: EVP_KDF-SSHKDF man page error?

2022-03-25 Thread Kory Hamzeh
Thanks, Paul. I noticed the type values matched the RFC, but thought maybe it 
should be a string if that was the case.

I did find another issue:

 if (EVP_KDF_derive(kctx, out, &outlen, params) <= 0)

The actual value of ‘outlen’ should be passed, not the address.

Kory

> On Mar 25, 2022, at 4:01 PM, pa...@openssl.org wrote:
> 
> It is correct, the KDF is expecting the characters 'A' through 'F' here.  
> This is what is specified in the RFC: 
> https://datatracker.ietf.org/doc/html/rfc4253#section-7.2
> 
> That line of code ought to have cast to (char *) or type defined simply as 
> char, but it is essentially correct.
> 
> 
> Pauli
> 
> On 26/3/22 5:11 am, Kory Hamzeh wrote:
>> Hi All,
>> 
>> If you look at the example SSH KDF code here:
>> 
>> https://www.openssl.org/docs/manmaster/man7/EVP_KDF-SSHKDF.html
>> 
>> Specifically, these lines:
>> 
>>  *p++ = OSSL_PARAM_construct_utf8_string(OSSL_KDF_PARAM_SSHKDF_TYPE,
>>  &type, sizeof(type));
>>  The variable ‘type’ is defined as a “const char”, so an 8 bit integer. The 
>> compiler spits out a warning on that line. Is the example code correct?
>> 
>>  I wonder if it should be calling OSSL_PARAM_construct_int() and ‘type’ 
>> changed to ‘int’?
>> 
>> Thanks,
>> Kory
>> 
> 



Re: EVP_KDF-SSHKDF man page error?

2022-03-25 Thread pauli
It is correct, the KDF is expecting the characters 'A' through 'F' 
here.  This is what is specified in the RFC: 
https://datatracker.ietf.org/doc/html/rfc4253#section-7.2


That line of code ought to have cast to (char *) or type defined simply 
as char, but it is essentially correct.



Pauli

On 26/3/22 5:11 am, Kory Hamzeh wrote:

Hi All,

If you look at the example SSH KDF code here:

https://www.openssl.org/docs/manmaster/man7/EVP_KDF-SSHKDF.html

Specifically, these lines:

  *p++ = OSSL_PARAM_construct_utf8_string(OSSL_KDF_PARAM_SSHKDF_TYPE,
  &type, sizeof(type));
  
The variable ‘type’ is defined as a “const char”, so an 8 bit integer. The compiler spits out a warning on that line. Is the example code correct?


  I wonder if it should be calling OSSL_PARAM_construct_int() and ‘type’ 
changed to ‘int’?

Thanks,
Kory





RE: Static OpenSSL 3 library with FIPS

2022-03-25 Thread Paul Spencer

Thanks for the info.

You mean both libssl.a and libcrypto.a static, and then dynamically loaded 
fips.so, correct? Unfortunately that gets away from the 
single-binary-executable model and so is a somewhat major change.


-Original Message-
From: Matt Caswell 
mailto:matt%20caswell%20%3cm...@openssl.org%3e>>
To: openssl-users@openssl.org
Subject: [EXTERNAL] Re: Static OpenSSL 3 library with FIPS
Date: Fri, 25 Mar 2022 20:22:02 +



On 25/03/2022 18:33, Paul Spencer wrote:

Q: Is it possible to have a static (.a) OpenSSL 3 library with FIPS support?


This was possible with OpenSSL 1.0.2 and the FIPS 2.0.x module (and

special linking in the Makefile). However, with SSL3, if I go


Configure no-module enable-fips


then it silently disables FIPS. Is there any way to do this?



You can have a static libcrypto (.a) with a dynamically loaded FIPS

module (i.e. using fips.so).


Configure no-shared enable-fips


You cannot have a statically linked FIPS module. It was a day 1 design

decision that we would no longer support this.


Matt


Re: Static OpenSSL 3 library with FIPS

2022-03-25 Thread Matt Caswell




On 25/03/2022 18:33, Paul Spencer wrote:

Q: Is it possible to have a static (.a) OpenSSL 3 library with FIPS support?

This was possible with OpenSSL 1.0.2 and the FIPS 2.0.x module (and 
special linking in the Makefile). However, with SSL3, if I go


Configure no-module enable-fips

then it silently disables FIPS. Is there any way to do this?



You can have a static libcrypto (.a) with a dynamically loaded FIPS 
module (i.e. using fips.so).


Configure no-shared enable-fips

You cannot have a statically linked FIPS module. It was a day 1 design 
decision that we would no longer support this.


Matt


Static OpenSSL 3 library with FIPS

2022-03-25 Thread Paul Spencer
Q: Is it possible to have a static (.a) OpenSSL 3 library with FIPS support?

This was possible with OpenSSL 1.0.2 and the FIPS 2.0.x module (and special 
linking in the Makefile). However, with SSL3, if I go

Configure no-module enable-fips

then it silently disables FIPS. Is there any way to do this?



EVP_KDF-SSHKDF man page error?

2022-03-25 Thread Kory Hamzeh
Hi All,

If you look at the example SSH KDF code here:

https://www.openssl.org/docs/manmaster/man7/EVP_KDF-SSHKDF.html

Specifically, these lines:

 *p++ = OSSL_PARAM_construct_utf8_string(OSSL_KDF_PARAM_SSHKDF_TYPE,
 &type, sizeof(type));
 
The variable ‘type’ is defined as a “const char”, so an 8 bit integer. The 
compiler spits out a warning on that line. Is the example code correct?

 I wonder if it should be calling OSSL_PARAM_construct_int() and ‘type’ changed 
to ‘int’?

Thanks,
Kory



Re: Openssl 0.9.8 to 1.0.2u - HP-UX- After installation and softlink created -console does not connect

2022-03-25 Thread Tomas Mraz
0.9.8 and 1.0.2 versions are not binary compatible. So if your SSH
server is built against the 0.9.8 version and it expects to be loading
the libcrypto.so from that version it will not work against the
libcrypto.so from 1.0.2. The SSH server has to be built against the
1.0.2 version to work with it.

Tomas Mraz

On Fri, 2022-03-25 at 09:54 +, Gaurav Mittal11 wrote:
> Hi,
>  
> I have build and installed 1.0.2u version but when I have change
> below softlink point to 1.0.2u from 0.9.8, console from putty stopped
> connecting.
> This is something related to openssl.cnf or we need new certs and
> private keys.
> Please help on same or share any documentation on it.
>  
> Note – 3.0.2 openssl version gives lot of compilation error, this
> 1.0.2u openssl version I have got from HP-UX website.
> http://hpux.connect.org.uk/hppd/hpux/Development/Libraries/openssl-1.0.2u/
>  
> Server details -
> HP-UX hvdnd73a B.11.31 U ia64 1869095592 unlimited-user license
>  
> dr-xr-xr-x   2 bin    bin   8192 Apr 30  2008 certs
> dr-xr-xr-x   2 bin    bin 96 Apr 30  2008 private
> dr-xr-xr-x   4 bin    bin 96 Jan 11  2012 fips
> dr-xr-xr-x   9 bin    bin   8192 Mar 15 05:08 0.9.8
> lrwxr-xr-x   1 root   sys  9 Mar 15 06:14 man ->
> 0.9.8/man
> lrwxr-xr-x   1 root   sys  9 Mar 15 06:14 src ->
> 0.9.8/src
> lrwxr-xr-x   1 root   sys 17 Mar 15 06:14 openssl.cnf
> -> 0.9.8/openssl.cnf
> lrwxr-xr-x   1 root   sys 12 Mar 15 06:14 README ->
> 0.9.8/README
> lrwxr-xr-x   1 root   sys  9 Mar 15 06:14 doc ->
> 0.9.8/doc
> lrwxr-xr-x   1 root   sys 13 Mar 15 06:14 include ->
> 0.9.8/include
> lrwxr-xr-x   1 root   sys  9 Mar 15 06:14 bin ->
> 0.9.8/bin
> lrwxr-xr-x   1 root       sys 10 Mar 15 06:14 misc ->
> 0.9.8/misc
> lrwxr-xr-x   1 root   sys  9 Mar 15 06:14 lib ->
> 0.9.8/lib
> drwxr-xr-x   7 root   sys   8192 Mar 15 06:42 1.0.2u
>  
>  
> Following Configuration used for configuration, complication/build
> and install –
>  
> export CC=/opt/aCC/bin/aCC
> export CFLAGS="+DD64 -mt"
> export CPPFLAGS="+DD64 -mt"
> export LDFLAGS="-L/usr/lib/hpux64/"
> export PATH=/usr/local/bin:/usr/contrib/imake/bin:$PATH
> ./Configure --prefix=/opt/openssl-1.0.2u --
> openssldir=/opt/openssl/1.0.2u --shared hpux64-ia64-cc
> gmake depend
> gmake
> gmake install
>  
>  
>  
> --
> Gaurav Mittal
>  

-- 
Tomáš Mráz, OpenSSL




Openssl 0.9.8 to 1.0.2u - HP-UX- After installation and softlink created -console does not connect

2022-03-25 Thread Gaurav Mittal11
Hi,

I have build and installed 1.0.2u version but when I have change below softlink 
point to 1.0.2u from 0.9.8, console from putty stopped connecting.
This is something related to openssl.cnf or we need new certs and private keys.
Please help on same or share any documentation on it.

Note - 3.0.2 openssl version gives lot of compilation error, this 1.0.2u 
openssl version I have got from HP-UX website.
http://hpux.connect.org.uk/hppd/hpux/Development/Libraries/openssl-1.0.2u/

Server details -
HP-UX hvdnd73a B.11.31 U ia64 1869095592 unlimited-user license

dr-xr-xr-x   2 binbin   8192 Apr 30  2008 certs
dr-xr-xr-x   2 binbin 96 Apr 30  2008 private
dr-xr-xr-x   4 binbin 96 Jan 11  2012 fips
dr-xr-xr-x   9 binbin   8192 Mar 15 05:08 0.9.8
lrwxr-xr-x   1 root   sys  9 Mar 15 06:14 man -> 0.9.8/man
lrwxr-xr-x   1 root   sys  9 Mar 15 06:14 src -> 0.9.8/src
lrwxr-xr-x   1 root   sys 17 Mar 15 06:14 openssl.cnf -> 
0.9.8/openssl.cnf
lrwxr-xr-x   1 root   sys 12 Mar 15 06:14 README -> 0.9.8/README
lrwxr-xr-x   1 root   sys  9 Mar 15 06:14 doc -> 0.9.8/doc
lrwxr-xr-x   1 root   sys 13 Mar 15 06:14 include -> 
0.9.8/include
lrwxr-xr-x   1 root   sys  9 Mar 15 06:14 bin -> 0.9.8/bin
lrwxr-xr-x   1 root   sys 10 Mar 15 06:14 misc -> 0.9.8/misc
lrwxr-xr-x   1 root   sys  9 Mar 15 06:14 lib -> 0.9.8/lib
drwxr-xr-x   7 root   sys   8192 Mar 15 06:42 1.0.2u


Following Configuration used for configuration, complication/build and install -

export CC=/opt/aCC/bin/aCC
export CFLAGS="+DD64 -mt"
export CPPFLAGS="+DD64 -mt"
export LDFLAGS="-L/usr/lib/hpux64/"
export PATH=/usr/local/bin:/usr/contrib/imake/bin:$PATH
./Configure --prefix=/opt/openssl-1.0.2u --openssldir=/opt/openssl/1.0.2u 
--shared hpux64-ia64-cc
gmake depend
gmake
gmake install



--
Gaurav Mittal



Re: Porting asterisk to Openssl-3.0

2022-03-25 Thread Tomas Mraz
On Thu, 2022-03-24 at 22:19 -0600, Philip Prindeville wrote:
> Hi,
> 
> I'm incrementally trying to port asterisk to Openssl 3.0.
> 
> First thing I'm trying to do is wean the code off of the RSA_*
> functions, and use generic EVP_PKEY_* functions instead.
> 
> Most of it is fairly straightforward (it seems), but I've been
> looking for examples of reading PEM public and private keys into
> EVP_PKEY's.
> 
> Currently asterisk uses 1.1.0 or later, so I'm trying to figure make
> the code build first under 1.1.0 dropping the functions that get
> deprecated in 3.0, and then rewriting (in a separate PR) whatever the
> delta is between 1.1.0 and 3.0.
> 
> In 3.0, I can find examples of reading PEM into a public RSA key such
> as:
> 
> https://www.openssl.org/docs/manmaster/man3/OSSL_DECODER_from_bio.html
> 
> Though I didn't understand why selection is
> OSSL_KEYMGMT_SELECT_KEYPAIR and not OSSL_KEYMGMT_SELECT_PUBLIC or
> _PRIVATE.
> 
> What is the way to read a PEM file (as a FILE * or BIO *) into a
> EVP_PKEY canonically in 1.1.0?
> 

It's PEM_read_bio_PrivateKey and PEM_read_PrivateKey - these functions
aren't deprecated in 3.0 so you can use them there as well. It's
actually a better idea to use these than the decoder API directly as
they can support legacy functionality (engine based keys).

-- 
Tomáš Mráz, OpenSSL