Using OpenSSL "ec" tool to encrypt the just-generated EC keys with ciphers stronger than 3DES

It is considered prudent to store the EC keys securely, to prevent OpenSSL library and tools from writing the keys unencrypted to the local file system. While it is possible to encrypt the generated key afterwards, it is considered important to prevent the key from appearing in its unencrypted form in any file. Such disclosure of the key will definitely occur if openssl ecparam -genkey is used with -out (that implies storing the unencrypted key in a file). The root cause of the issue is due to the inability to enable password protection when openssl ecparam -genkey is invoked to generate EC keys. That inability is what makes necessary the subsequent use of the "ec" tool to encrypt the generated EC keys. On the other side, the OpenSSL man pages that come with the OpenSSL installation on Red Hat Enterprise Linux 8/9 (and its derivatives), do not mention the use of a cipher other than 3DES with "ec". This ambiguity causes considerable confusion. This short post explains how to use strong AES encryption to protect the just-generated EC key with a password.

Generate an EC key, but instead of storing the result in a file, send it to the "ec" tool. Even if both the help information and man page of "ec" do not provide any information on how to request AES encryption, specify the corresponding AES cipher in the command line:

openssl ecparam -genkey -name secp384r1 | openssl ec -aes-256-cbc -out my.key

But can we employ a cipher different than 3DES and aes-256-cbc? You can answer that question by checking what is supported by your OpenSSL installation. To do that just type:

openssl --help

and analyze the output. For example, the following ciphers are supported on Red Hat Enterprise Linux 9:

aes-128-cbc       aes-128-ecb       aes-192-cbc       aes-192-ecb       
aes-256-cbc       aes-256-ecb       aria-128-cbc      aria-128-cfb      
aria-128-cfb1     aria-128-cfb8     aria-128-ctr      aria-128-ecb      
aria-128-ofb      aria-192-cbc      aria-192-cfb      aria-192-cfb1     
aria-192-cfb8     aria-192-ctr      aria-192-ecb      aria-192-ofb      
aria-256-cbc      aria-256-cfb      aria-256-cfb1     aria-256-cfb8     
aria-256-ctr      aria-256-ecb      aria-256-ofb      base64            
bf                bf-cbc            bf-cfb            bf-ecb            
bf-ofb            camellia-128-cbc  camellia-128-ecb  camellia-192-cbc  
camellia-192-ecb  camellia-256-cbc  camellia-256-ecb  cast              
cast-cbc          cast5-cbc         cast5-cfb         cast5-ecb         
cast5-ofb         des               des-cbc           des-cfb           
des-ecb           des-ede           des-ede-cbc       des-ede-cfb       
des-ede-ofb       des-ede3          des-ede3-cbc      des-ede3-cfb      
des-ede3-ofb      des-ofb           des3              desx              
idea              idea-cbc          idea-cfb          idea-ecb          
idea-ofb          rc2               rc2-40-cbc        rc2-64-cbc        
rc2-cbc           rc2-cfb           rc2-ecb           rc2-ofb           
rc4               rc4-40            rc5               rc5-cbc           
rc5-cfb           rc5-ecb           rc5-ofb           seed              
seed-cbc          seed-cfb          seed-ecb          seed-ofb          
zlib  

If you're moving a file with an encrypted EC key from one system to another, make sure that the OpenSSL installation there supports the cipher you used. Otherwise, the EC key won't be decrypted.


How to enable the screen/window sharing (screen casting) on Rocky Linux 9 (GNOME)

By default (fresh installation of the distribution and the apps) the desktop applications available on Rocky Linux 9 (GNOME desktop) cannot share the entire screen, a window, or a browser tab.

That problem appears due to a combination of a missing package (xdg-desktop-portal-gnome), which might not be installed by default, and systemd services (xdg-desktop-portal and/or pipewire), which are either missing or not enabled.

To solve the issue you need to install xdg-desktop-portal-gnome

sudo dnf -y install xdg-desktop-portal-gnome

and enable/start/restart the required services (as user):

systemctl --user enable --now pipewire
systemctl --user restart xdg-desktop-portal.service

Opening a collection of build recipes for compiling software for simulations and data analysis (HPC-related)

Those build recipe prototypes are siple bash scripts but they could be easily converted into Jenkins jobs:

https://gitlab.discoverer.bg/vkolev/recipes

Working on new HPC farm and its documentation project

Busy during the last 12 months. Designing and supporting yet another HPC farm, and writing documentation:

https://docs.discoverer.bg

Creating SHA256/SHA384/SHA512 based S/MIME digital signatures and using AES-256 for encryption in Outlook

Content:

  1. Why does Outlook sticks to SHA-1 and 3DES when creating S/MIME signatures and encrypting the content
  2. How to set the use modern and secure hash functions and encryption algorithms for S/MIME in Outlook
  3. How to sign your outgoing e-mail messages
  4. How to check the algorithm used for creating the S/MIME signature

1. Why does Outlook sticks to SHA-1 and 3DES when creating S/MIME signatures and encrypting the content

That is not clear at the moment. If one tries to select different hash function for S/MIME signature (SHA256, SHA384, SHA512) and an encryption algorithm different than 3DES (AES-256, for instance), those changes cannot be saved under the default S/MIME settings profile. Outook keeps using SHA-1 and 3DES. The most strange thing is that even the support of the Microsoft products cannot provide a solution:

https://answers.microsoft.com/en-us/msoffice/forum/all/cant-change-smime-hashing-algorithm-in-outlook/3d2a5cae-e4d2-4533-b29e-c341254b6ceb

2. How to set the use modern and secure hash functions and encryption algorithms for S/MIME in Outlook

Important: You cannot use a hash function that is of a higher order than the one used by your Certificate Authority to sing your X.509 certificate. For instance, if the CA signature on your certificate is SHA256, you cannot use SHA384 and SHA512 when creating the S/MIME signatures. Obviously, if the CA signature on your X.509 certificate is one based on SHA-1, you cannot use even SHA-256 for signing in Outlook. Therefore, check your case before starting with the instructions bellow.

Before starting, you need to have your certificate installed - either in Windows Certificate Store of the current user, via PKCS#12 file, or by connecting the smart card reader to the system. Once the certificate is accessible, start Outlook and in the main window go to "File":

Click there on "Options":

Next, go to "Trust Center" (1) and from there open "Trust Center Settings" (2):

Finally, click on "Email Security" (1) and "Settings"(2) to start modifying the S/MIME profile:

And here comes the big problem. You cannot change the hash function and the encryption algorithm in the default profile (that profile is created automatically). Therefore, you have to create manually a new default profile, by naming it differently and select there the desired combination of hash and encryption algorithms. This is what is done bellow.

First, select the certificate for signing (if it is not already selected):

And here comes the trick. Select the desired encryption algorithm (1), then the desired hash function (2), and CHANGE THE NAME OF THE PROFILE WITH SETTINGS - THIS MAKES THE MAGIC (3):

Press "OK" to exit (4) and in the previous window be sure the new profile is selected:

You may close the corresponding windows in the configuration menu and start signing your outgoing e-mail messages.

3. How to sign your outgoing e-mail messages using the new S/MIME settings

Nothing new here. Compose a new short e-mail message, addressed to yourself, do not send it yet, and open the tab "Options":

Click on "Sign", then press the button "Send" to send the message:

A new window will pop up. There you should either enter your password for protecting the private key in the Windows Certificate Store of the current user, or the PIN for unlocking the access to the smart card processor for signing:

4. How to check the algorithm used for creating the S/MIME signature

Once the signed email is received in the Inbox, click on the seal icon:

In the new window, check if the S/MIME signature is valid:

and them click on "Details":

If you click on "Signer" you will see the algorithm used for creating the S/MIME signature:


Compiling GROMACS 2019.5 with Intel Compilers and CUDA on CentOS 7 and 8

All tests reported bellow are performed by using Intel Parallel Studio XE 2019 Update 4. I presume you may achieve the same positive results using older versions of the Intel Compilers package.

Notes on CentOS 7: You have to install the SCL repository and EPEL (that are MANDATORY requirements you cannot skip):

$ sudo yum install centos-release-scl centos-release-scl-rh epel-release

Then, using the new repositories, install dvetoolset-8 and cmake3:

$ sudo yum install devtoolset-8 cmake3

In the bash session, where the compilation process will take place, execute:

$ scl enable devtoolset-8 bash

To install the CUDA latest compiler and libraries, you might use the procedure described in my previous posts. The latest version of CUDA is 10.2. Once all the pre-requisites are satisfied, download the GROMACS 2019.5 source code tarball, unpack it, create a folder named "build" inside the source tree, enter it, load the Intel Compilers variables, then the SCL environment and run the compilation and installation process:

$ mkdir ~/build
$ cd build
$ wget ftp://ftp.gromacs.org/pub/gromacs/gromacs-2019.5.tar.gz
$ tar xvf gromacs-2019.5.tar.gz
$ cd gromacs-2019.5
$ mkdir build
$ cd build
$ source /opt/intel/compilers_and_libraries/linux/bin/compilervars.sh intel64
$ CC=icc CXX=icpc CFLAGS="-xHost" CXXFLAGS="-xHost" cmake3 .. -DCMAKE_INSTALL_PREFIX=/usr/local/appstack/gromacs-2019.5-icc -DGMX_MPI=OFF -DGMX_BUILD_OWN_FFTW=OFF -DGMX_GPU=ON -DCUDA_TOOLKIT_ROOT_DIR=/usr/local/cuda -DGMX_FFT_LIBRARY=mkl
$ make -j6 install

The product of the compilation will be installed in /usr/local/appstack/gromacs-2019.5-icc. You might change that destination by set another value to -DCMAKE_INSTALL_PREFIX.


Getting ssllabs.com class "A+" by matching at 100% Key Exchange and Cipher Strength criteria

In most cases, getting "A+" rate by the TLS ssllabs.com server checker, does not necessary mean the examined server matches fully (at 100%) all criteria. For instance, "A+" might be given if your server matches partially (at 90% level) the requirements for key exchange protocols and cipher strength:

In my case, I got "A+" status for my Apache/mod_ssl 2.4.6 server (on CentOS 7) by using limited and very conservative list of ciphers (it is a long story about why I do avoid using "CBC"-based ciphers):

ECDHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES128-GCM-SHA256

So far (8 months since I implemented the new TLS configuration), I haven't received any complaints from my clients, related to TLS issues. Seems like they keep their mobile and desktop browsers very much up to date.

Recently, for another project (PKI-based one) I decided to go further and try to get "A+" by matching all criteria at 100% (using the same Apache/mod_ssl 2.4.6 setup on CenOS 7):

What I have done? I just removed from the list above the 128-bit ciphers:

ECDHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES256-GCM-SHA384

How does this change affect the clients? I got only 1 complaint from a person who is used to use Firefox on CentOS 6 (rather old distribution for a desktop, I dare say). On the other side, even mobile clients with Android 6.0, using Samsung Internet Browser, do not have any problem with the new TLS cipher set.

What was surprising is that replacing RSA server certificate with ECDSA-based one, does not create any significant TLS issues. Again, the first set of ciphers I tested (where "A+" is matched only partially), was based on both 256 and 128-bit ciphers:

ECDHE-ECDSA-AES256-GCM-SHA384
ECDH-ECDSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES128-GCM-SHA256
ECDH-ECDSA-AES128-GCM-SHA256

and the second one included only 256-bit based ciphers:

ECDHE-ECDSA-AES256-GCM-SHA384
ECDH-ECDSA-AES256-GCM-SHA384

It seems like most of the browser and OS vendors take a lot of measures to secure the TLS protocol implementation in their software products.


Creative Commons - Attribution 2.5 Generic. Powered by Blogger.

Implementing LUKS Encryption on Software RAID Arrays with LVM2 Management

A comprehensive guide to partition-level encryption for maximum security ...

Search This Blog

Translate