Re: no suitable signature algorithm during handshake failure

2021-01-08 Thread Quanah Gibson-Mount 




--On Friday, January 8, 2021 4:44 PM -0500 Viktor Dukhovni 
 wrote:


Hi Viktor,


On Fri, Jan 08, 2021 at 12:05:26PM -0800, Quanah Gibson-Mount wrote:


> https://www.spinics.net/lists/openssl-users/msg05623.html

Thanks Viktor.  Mainly, I wasn't sure what specific information would be
necessary.  Here's what wireshark shows (IP addresses obfuscated):


It would be really helpful (also to you) if you install a more
up-to-date version of tshark, or copy the pcap file to a machine
that already has one.  The version used below fails to understand
many relevant modern TLS extensions/features.


I've relayed this to our client. ;)


! --->  Extension: Unknown 43 -- i.e. supported_versions!
Type: Unknown (0x002b)-- Almost certainly w/ TLS 1.3
Length: 9
Data (9 bytes)
! --->  Extension: Unknown 45 -- psk_key_exchange_modes
Type: Unknown (0x002d)-- a TLS 1.3 feature
Length: 2
Data (2 bytes)
! --->  Extension: Unknown 51 -- key_share
Type: Unknown (0x0033)-- a TLS 1.3 feature



I ran their pcap through my own updated version of tshark, and indeed:

   Extension: status_request_v2 (len=9)
   Type: status_request_v2 (17)
   Length: 9
   Certificate Status List Length: 7
   Certificate Status Type: OCSP Multi (2)
   Certificate Status Length: 4
   Responder ID list Length: 0
   Request Extensions Length: 0
   Extension: extended_master_secret (len=0)
   Type: extended_master_secret (23)
   Length: 0
   Extension: supported_versions (len=9)
   Type: supported_versions (43)
   Length: 9
   Supported Versions length: 8
   Supported Version: TLS 1.3 (0x0304)
   Supported Version: TLS 1.2 (0x0303)
   Supported Version: TLS 1.1 (0x0302)
   Supported Version: TLS 1.0 (0x0301)
   Extension: psk_key_exchange_modes (len=2)
   Type: psk_key_exchange_modes (45)
   Length: 2
   PSK Key Exchange Modes Length: 1
   PSK Key Exchange Mode: PSK with (EC)DHE key establishment 
(psk_dhe_ke) (1)

   Extension: key_share (len=71)
   Type: key_share (51)
   Length: 71
   Key Share extension
   Client Key Share Length: 69
   Key Share Entry: Group: secp256r1, Key Exchange length: 
65

   Group: secp256r1 (23)
   Key Exchange Length: 65
   Key Exchange: 
04524e56171cf3e75903228cf4cc02687df2698bd43d167f…




None were PSS, and RFC 8446 says:

   In addition, the signature algorithm MUST be compatible with the key
   in the sender's end-entity certificate.  RSA signatures MUST use an
   RSASSA-PSS algorithm, regardless of whether RSASSA-PKCS1-v1_5
   algorithms appear in "signature_algorithms".  The SHA-1 algorithm
   MUST NOT be used in any signatures of CertificateVerify messages.


> What sort of certificate does the server have.  Are there any ssl
> module settings in its openssl.cnf file?



The certificate does not require PSS, but TLS 1.3 does.


Great, thanks so much for the help! I learned some along the way, which is 
always a good thing. :)


Regards,
Quanah


--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:

RE: private key not available for client_cert_cb

2021-01-08 Thread Michael Wojcik 
> From: openssl-users  On Behalf Of George
> Sent: Friday, 8 January, 2021 14:35

> The comment indicates that the flag RSA_METHOD_FLAG_NO_CHECK should be set
> for smart cards[...]

> However, it is not actually set when I use a debugger to inspect the flag.
> Does it need to be set? If so, how is this done?

If memory serves, the PKCS#11 implementation invoked by the pkcs11 engine is 
supposed to set it.

See for example this patch to OpenSC's pkcs11-helper library:

https://github.com/OpenSC/pkcs11-helper/commit/5198bb1e557dfd4109bea41c086825bf6ebdd9f3

(That patch actually is to set a different flag, but it shows the code in 
question.)

I know, that's probably not terribly helpful.

If you do a web search for something like

pkcs11 "RSA_METHOD_FLAG_NO_CHECK"

you'll probably find a number of hits where other people ran into similar 
problems.

Isn't PKCS#11 grand? If you're bored with all the interoperability problems of 
X.509, PKIX, and TLS, we have good news!

--
Michael Wojcik

Re: no suitable signature algorithm during handshake failure

2021-01-08 Thread Viktor Dukhovni 
On Fri, Jan 08, 2021 at 12:05:26PM -0800, Quanah Gibson-Mount wrote:

> > https://www.spinics.net/lists/openssl-users/msg05623.html
> 
> Thanks Viktor.  Mainly, I wasn't sure what specific information would be 
> necessary.  Here's what wireshark shows (IP addresses obfuscated):

It would be really helpful (also to you) if you install a more
up-to-date version of tshark, or copy the pcap file to a machine
that already has one.  The version used below fails to understand
many relevant modern TLS extensions/features.

See annotations added:

> Secure Sockets Layer
> TLSv1.2 Record Layer: Handshake Protocol: Client Hello
> Content Type: Handshake (22)
> Version: TLS 1.2 (0x0303)
> Length: 423
> Handshake Protocol: Client Hello
> Handshake Type: Client Hello (1)
> Length: 419
> Version: TLS 1.2 (0x0303)
> Random
> GMT Unix Time: Oct  2, 2014 19:22:16.0 MDT
> Random Bytes: 
> 3226c3627d2ba7c967ce2cf097e616d9cbe45d1bb1cc21f4...
> Session ID Length: 32
> Session ID: bde8c16349a08e56a121b6e7aa1f317acf42186ba79b134d...
> Cipher Suites Length: 88
> Cipher Suites (44 suites)
> --> Cipher Suite: Unknown (0x1301)-- i.e. 
> TLS_AES_128_GCM_SHA256
> --> Cipher Suite: Unknown (0x1302)-- i.e. 
> TLS_AES_256_GCM_SHA384
> Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
> Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
> Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
> Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)
> Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02e)
> Cipher Suite: TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 (0xc032)
> Cipher Suite: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x009f)
> Cipher Suite: TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 (0x00a3)
> Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
> Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
> Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02d)
> Cipher Suite: TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 (0xc031)
> Cipher Suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x009e)
> Cipher Suite: TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 (0x00a2)
> Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024)
> Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
> Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)
> Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 (0xc026)
> Cipher Suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 (0xc02a)
> Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x006b)
> Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 (0x006a)
> Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
> Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
> Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
> Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA (0xc005)
> Cipher Suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA (0xc00f)
> Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
> Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)
> Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)
> Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
> Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c)
> Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 (0xc025)
> Cipher Suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 (0xc029)
> Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x0067)
> Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 (0x0040)
> Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
> Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
> Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
> Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA (0xc004)
> Cipher Suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA (0xc00e)
> Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
> Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
> Compression Methods Length: 1
> Compression Methods (1 method)
> Extensions Length: 258
> Extension: server_name
> Type: server_name (0x)
> Length: 35
> Server Name Indication extension
> Server Name list

Re: private key not available for client_cert_cb

2021-01-08 Thread George 

Hi,

   I have been trying to setup mutual authentication using a smart card 
but I can't seem to get the OpenSSL Engine to send a response back to 
the server containing client's certificate from the smart card.


I'm using the following to configure the certificate and private key:

    ENGINE_ctrl_cmd(engine, "LOAD_CERT_CTRL", 0, _info, NULL, 0);
    SSL_CTX_use_certificate(sslContext, cert_info.cert);

    EVP_PKEY* privateKey = ENGINE_load_private_key(engine, 
"2b2586c684d69b670c0a805edf514e720f2b757d8e2faa0b3a7ff23d1ccfc7ba", 
transfer_pin, _data);

    SSL_CTX_use_PrivateKey(sslContext, privateKey);

(I have been using the code in 
https://github.com/jjkeijser/ppp/blob/eap-tls/pppd/eap-tls.c  as a guide.)


This seems be successful. However, when I start the mutual 
authentication with

SSL_connect(ssl)
, the mutual authentications handshake fails. I can see the server 
requesting the certificate from the client and the client sends back an 
ACK for this message. However, the client does not send the certificate 
to the server.


I was looking through the OpenSSL code openssl-1.0.2u\ssl\ssl_rsa.c and 
noticed something interesting. The comment indicates that the flag 
*RSA_METHOD_FLAG_NO_CHECK* should be set for smart cards:


static int ssl_set_pkey(CERT *c, EVP_PKEY *pkey)
{
 . . .
#ifndef OPENSSL_NO_RSA
*   /***
** * Don't check the public/private key, this is mostly for smart**
** * cards.**
** */*
    if ((pkey->type == EVP_PKEY_RSA) &&
    (RSA_flags(pkey->pkey.rsa) & RSA_METHOD_FLAG_NO_CHECK)) ;
    else
#endif
. . .
}

However, it is not actually set when I use a debugger to inspect the 
flag. Does it need to be set? If so, how is this done? I could not find 
anything related to this in

https://github.com/jjkeijser/ppp/blob/eap-tls/pppd/eap-tls.c




Thanks,
George


On 2021-01-05 11:51 a.m., Jan Just Keijser wrote:

Hi,

On 05/01/21 07:39, George wrote:

Hi,

    I was looking at the  code in 
https://github.com/jjkeijser/ppp/blob/eap-tls/pppd/eap-tls.c and 
realized I forgot to call ENGINE_ctrl_cmd(...) to setup 
"LOAD_CERT_CTRL". However, when I do this, the callback function is 
no longer being called during the mutual authentication handshake. 
I'm wondering if I have the parameter "cert_info.s_slot_cert_id" 
incorrectly configured. Here is what my code looks like:


struct
{
   const char* s_slot_cert_id;
   X509* cert;
} cert_info;
*cert_info.s_slot_cert_id =
"a9bee4d72100c52f77c3fc288d2be01a34b5d44f91b3b7ea3d349b8a25752c45";*
cert_info.cert = NULL;

*ENGINE_ctrl_cmd(engine, "LOAD_CERT_CTRL", 0, _info, NULL, 0);*
*SSL_CTX_use_certificate(sslContext, cert_info.cert);*


I tried manually using LOAD_CERT_CTRL in the openssl shell but I 
cannot seem to get it to work and cannot find any examples of how to 
use it.  Is the syntax for *LOAD_CERT_CTRL* correct? I am 
using***"LOAD_CERT_CTRL:".*


OpenSSL> engine - -t dynamic -pre
"SO_PATH:C:\\Users\\whipp\\junk4\\libp11-libp11-0.4.11\\src\\pkcs11.dll"
-pre ID:pkcs11 -pre LIST_ADD:1 -pre LOAD -pre
"MODULE_PATH:C:\Program Files (x86)\HID
Global\ActivClient\\acpkcs211.dll" -pre PIN:123456 -pre
FORCE_LOGIN *-pre

"LOAD_CERT_CTRL:a9bee4d72100c52f77c3fc288d2be01a34b5d44f91b3b7ea3d349b8a25752c45"

*(dynamic) Dynamic engine loading support
[Success]:
SO_PATH:C:\\Users\\whipp\\junk4\\libp11-libp11-0.4.11\\src\\pkcs11.dll
[Success]: ID:pkcs11
[Success]: LIST_ADD:1
[Success]: LOAD
[Success]: MODULE_PATH:C:\Program Files (x86)\HID
Global\ActivClient\\acpkcs211.dll
[Success]: PIN:123456
[Success]: FORCE_LOGIN
*[Failure]:

LOAD_CERT_CTRL:a9bee4d72100c52f77c3fc288d2be01a34b5d44f91b3b7ea3d349b8a25752c45**
**4196:error:260AB086:engine routines:ENGINE_ctrl_cmd_string:cmd
not executable:.\crypto\engine\eng_ctrl.c:316:*
Loaded: (pkcs11) pkcs11 engine
 [ available ]
 SO_PATH: Specifies the path to the 'pkcs11' engine shared
library
  (input flags): STRING
 MODULE_PATH: Specifies the path to the PKCS#11 module shared
library
  (input flags): STRING
 PIN: Specifies the pin code
  (input flags): STRING
 VERBOSE: Print additional details
  (input flags): NO_INPUT
 QUIET: Remove additional details
  (input flags): NO_INPUT
*LOAD_CERT_CTRL: Get the certificate from card**
**  (input flags): [Internal]*
 INIT_ARGS: Specifies additional initialization arguments to
the PKCS#11 module
  (input flags): STRING
 SET_USER_INTERFACE: Set the global user interface (internal)
  (input flags): [Internal]
 SET_CALLBACK_DATA: Set the global user interface extra data
(internal)
  (input flags): [Internal]
 FORCE_LOGIN: Force login to the PKCS#11 module
  (input flags): NO_INPUT
OpenSSL>

Re: no suitable signature algorithm during handshake failure

2021-01-08 Thread Quanah Gibson-Mount 




--On Thursday, January 7, 2021 8:56 PM -0500 Viktor Dukhovni 
 wrote:



You're leaving out too much detail.  Post the full client hello decoded
by "tshark":

https://www.spinics.net/lists/openssl-users/msg05623.html


Thanks Viktor.  Mainly, I wasn't sure what specific information would be 
necessary.  Here's what wireshark shows (IP addresses obfuscated):


No. Time   UTC   Source 
Length Destination   Protocol Info
 1 0.00   2021-01-07 21:19:53.417328255.255.255.223 
68 255.255.255.198   TCP  51466→636 [SYN, ECN, CWR] Seq=0 
Win=8192 Len=0 MSS=1380 WS=256 SACK_PERM=1


Frame 1: 68 bytes on wire (544 bits), 68 bytes captured (544 bits)
Linux cooked capture
Internet Protocol Version 4, Src: 255.255.255.223, Dst: 255.255.255.198
Transmission Control Protocol, Src Port: 51466, Dst Port: 636, Seq: 0, Len: 
0


No. Time   UTC   Source 
Length Destination   Protocol Info
 2 0.81   2021-01-07 21:19:53.417409255.255.255.198 
68 255.255.255.223TCP  636→51466 [SYN, ACK] Seq=0 Ack=1 
Win=64240 Len=0 MSS=1460 SACK_PERM=1 WS=128


Frame 2: 68 bytes on wire (544 bits), 68 bytes captured (544 bits)
Linux cooked capture
Internet Protocol Version 4, Src: 255.255.255.198, Dst: 255.255.255.223
Transmission Control Protocol, Src Port: 636, Dst Port: 51466, Seq: 0, Ack: 
1, Len: 0


No. Time   UTC   Source 
Length Destination   Protocol Info
 3 0.000462   2021-01-07 21:19:53.417790255.255.255.223 
62 255.255.255.198   TCP  51466→636 [ACK] Seq=1 Ack=1 
Win=2097408 Len=0


Frame 3: 62 bytes on wire (496 bits), 62 bytes captured (496 bits)
Linux cooked capture
Internet Protocol Version 4, Src: 255.255.255.223, Dst: 255.255.255.198
Transmission Control Protocol, Src Port: 51466, Dst Port: 636, Seq: 1, Ack: 
1, Len: 0

VSS-Monitoring ethernet trailer, Source Port: 0

No. Time   UTC   Source 
Length Destination   Protocol Info
 4 0.004053   2021-01-07 21:19:53.421381255.255.255.223 
484255.255.255.198   TLSv1.2  Client Hello


Frame 4: 484 bytes on wire (3872 bits), 484 bytes captured (3872 bits)
Linux cooked capture
Internet Protocol Version 4, Src: 255.255.255.223, Dst: 255.255.255.198
Transmission Control Protocol, Src Port: 51466, Dst Port: 636, Seq: 1, Ack: 
1, Len: 428

Secure Sockets Layer
   TLSv1.2 Record Layer: Handshake Protocol: Client Hello
   Content Type: Handshake (22)
   Version: TLS 1.2 (0x0303)
   Length: 423
   Handshake Protocol: Client Hello
   Handshake Type: Client Hello (1)
   Length: 419
   Version: TLS 1.2 (0x0303)
   Random
   GMT Unix Time: Oct  2, 2014 19:22:16.0 MDT
   Random Bytes: 
3226c3627d2ba7c967ce2cf097e616d9cbe45d1bb1cc21f4...

   Session ID Length: 32
   Session ID: bde8c16349a08e56a121b6e7aa1f317acf42186ba79b134d...
   Cipher Suites Length: 88
   Cipher Suites (44 suites)
   Cipher Suite: Unknown (0x1301)
   Cipher Suite: Unknown (0x1302)
   Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 
(0xc02c)
   Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 
(0xc02b)

   Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
   Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)
   Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 
(0xc02e)

   Cipher Suite: TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 (0xc032)
   Cipher Suite: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x009f)
   Cipher Suite: TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 (0x00a3)
   Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
   Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
   Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 
(0xc02d)

   Cipher Suite: TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 (0xc031)
   Cipher Suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x009e)
   Cipher Suite: TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 (0x00a2)
   Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 
(0xc024)

   Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
   Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)
   Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 
(0xc026)

   Cipher Suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 (0xc02a)
   Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x006b)
   Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 (0x006a)
   Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
   Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
   Cipher Suite:

Re: Random and rare Seg faults at openssl library level

2021-01-08 Thread Jakob Bohm via openssl-users 

On 2021-01-07 18:05, Ken Goldman wrote:

On 1/7/2021 10:11 AM, Michael Wojcik wrote:


$ cat /etc/redhat-release && openssl version
CentOS Linux release 7.9.2009 (Core)
OpenSSL 1.0.2k-fips  26 Jan 2017


Ugh. Well, OP should have made that clear in the original message.

And this is one of the problems with using an OpenSSL supplied by the 
OS vendor.


In defense of "the OS vendor", meaning the distro, it's a big task to
upgrade to a new openssl major release.  Because there is often not ABI
compatibility, every package has to be ported, built, and tested.
A distro release that is in long term support doesn't do that often.




In defense of long term support distros, until a few years ago, no one 
suspected that OpenSSL would come under a new leadership that actively 
did everything to make it near-impossible to maintain backported 
security patches for a typical 5+ year distro lifecycle (with 
OpenSSL-independent start date).


Until 1.0.2, all OpenSSL releases were incremental patch-steps from the 
old 0.9.x series, allowing distro maintainers to manually cherry pick 
changes for doing ABI-compatible patches for whichever 1.0.x or 0.9.x 
was current at the start of their lifecycle.  Then the new leadership 
started to restructure the code even in supposedly patch-level releases.


A lot of long term support distros are now firmly stuck with unsupported 
OpenSSL 1.0.2 and/or short life cycle 1.1.1.


Not all long term distros are run by rich companies like IBM/RedHat that 
can purchase support plans, resulting in further popularity of OpenSSL 
forks.


Enjoy

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

RE: Random and rare Seg faults at openssl library level

2021-01-08 Thread Kenneth Goldman 





From:   Gimhani Uthpala 
To: Ken Goldman 
Cc: openssl-users@openssl.org
Date:   01/07/2021 05:53 PM
Subject:[EXTERNAL] Re: Random and rare Seg faults at openssl library
level



I only have this 1.0.2.k-fips one version installed in both compiling and
running machines. However, I am compiling the application in RH7.4 and
running in RH7.8 linking to openssl library dynamically. I assume no issue
with that as I am using the same version of openssl in both.

You are having a problem, and that is a typical cause.  Try compiling and
running on the exact same OS.

If you installed openssl yourself, not using the RHEL yum installer, I
would expect random and rare issues.

Re: How to set amount of salt for PBKDF2/PKCS8 keys?

2021-01-08 Thread Matt Caswell 



On 08/01/2021 00:59, Mathias Ricken wrote:
> How do I sell openssl to use more salt when generating the private key?

Unfortunately the pkcs8 tool does not support setting a custom salt
length and always uses the default length of 64 bits.

The best I can offer you is a hack of the tool to change the default to
128 bits (16 bytes):

diff --git a/apps/pkcs8.c b/apps/pkcs8.c
index 205536560a..14700e5d12 100644
--- a/apps/pkcs8.c
+++ b/apps/pkcs8.c
@@ -229,7 +229,7 @@ int pkcs8_main(int argc, char **argv)
 scrypt_N, scrypt_r,
scrypt_p);
 else
 #endif
-pbe = PKCS5_pbe2_set_iv(cipher, iter, NULL, 0, NULL,
+pbe = PKCS5_pbe2_set_iv(cipher, iter, NULL, 16, NULL,
 pbe_nid);
 } else {
 pbe = PKCS5_pbe_set(pbe_nid, iter, NULL, 0);



Matt