TLS/SSL and crypto library

Welcome to the OpenSSL Project

openssl logo

github actions ci badge appveyor badge

OpenSSL is a robust, commercial-grade, full-featured Open Source Toolkit for the Transport Layer Security (TLS) protocol formerly known as the Secure Sockets Layer (SSL) protocol. The protocol implementation is based on a full-strength general purpose cryptographic library, which can also be used stand-alone.

OpenSSL is descended from the SSLeay library developed by Eric A. Young and Tim J. Hudson.

The official Home Page of the OpenSSL Project is www.openssl.org.

Table of Contents

Overview

The OpenSSL toolkit includes:

  • libssl an implementation of all TLS protocol versions up to TLSv1.3 (RFC 8446).

  • libcrypto a full-strength general purpose cryptographic library. It constitutes the basis of the TLS implementation, but can also be used independently.

  • openssl the OpenSSL command line tool, a swiss army knife for cryptographic tasks, testing and analyzing. It can be used for

    • creation of key parameters
    • creation of X.509 certificates, CSRs and CRLs
    • calculation of message digests
    • encryption and decryption
    • SSL/TLS client and server tests
    • handling of S/MIME signed or encrypted mail
    • and more...

Download

For Production Use

Source code tarballs of the official releases can be downloaded from www.openssl.org/source. The OpenSSL project does not distribute the toolkit in binary form.

However, for a large variety of operating systems precompiled versions of the OpenSSL toolkit are available. In particular on Linux and other Unix operating systems it is normally recommended to link against the precompiled shared libraries provided by the distributor or vendor.

For Testing and Development

Although testing and development could in theory also be done using the source tarballs, having a local copy of the git repository with the entire project history gives you much more insight into the code base.

The official OpenSSL Git Repository is located at git.openssl.org. There is a GitHub mirror of the repository at github.com/openssl/openssl, which is updated automatically from the former on every commit.

A local copy of the Git Repository can be obtained by cloning it from the original OpenSSL repository using

git clone git://git.openssl.org/openssl.git

or from the GitHub mirror using

git clone https://github.com/openssl/openssl.git

If you intend to contribute to OpenSSL, either to fix bugs or contribute new features, you need to fork the OpenSSL repository openssl/openssl on GitHub and clone your public fork instead.

git clone https://github.com/yourname/openssl.git

This is necessary, because all development of OpenSSL nowadays is done via GitHub pull requests. For more details, see Contributing.

Build and Install

After obtaining the Source, have a look at the INSTALL file for detailed instructions about building and installing OpenSSL. For some platforms, the installation instructions are amended by a platform specific document.

Specific notes on upgrading to OpenSSL 3.0 from previous versions, as well as known issues are available on the OpenSSL 3.0 Wiki page.

Documentation

Manual Pages

The manual pages for the master branch and all current stable releases are available online.

Wiki

There is a Wiki at wiki.openssl.org which is currently not very active. It contains a lot of useful information, not all of which is up to date.

License

OpenSSL is licensed under the Apache License 2.0, which means that you are free to get and use it for commercial and non-commercial purposes as long as you fulfill its conditions.

See the LICENSE.txt file for more details.

Support

There are various ways to get in touch. The correct channel depends on your requirement. see the SUPPORT file for more details.

Contributing

If you are interested and willing to contribute to the OpenSSL project, please take a look at the CONTRIBUTING file.

Legalities

A number of nations restrict the use or export of cryptography. If you are potentially subject to such restrictions you should seek legal advice before attempting to develop or distribute cryptographic code.

Copyright

Copyright (c) 1998-2021 The OpenSSL Project

Copyright (c) 1995-1998 Eric A. Young, Tim J. Hudson

All rights reserved.

Comments
  • mingw after refactor-build: misc issues

    mingw after refactor-build: misc issues

    Testing mingw after build refactor (https://github.com/levitte/openssl/tree/refactor-build), using configuration that worked for 1.1.0-pre1/2 and 1.0.2, an early abort is the result:

    Can't locate Text/Template.pm in @INC (you may need to install the Text::Template module) (@INC contains: util util/../external/perl . /usr/lib/perl5/site_perl /usr/share/perl5/site_perl /usr/lib/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib/perl5/core_perl /usr/share/perl5/core_perl) at /usr/share/perl5/core_perl/parent.pm line 20.
    BEGIN failed--compilation aborted at util/dofile.pl line 45.
    

    Ref: https://ci.appveyor.com/project/vsz/harbour-deps/build/1.0.380#L797

    What needs to be done with Perl to get the required extra packages, under an AppVeyor environment?

    /cc @levitte

  • Assistance request: setting up for NonStop platform support

    Assistance request: setting up for NonStop platform support

    Greetings! I'm about to submit a PR for the NonStop NSX and NSE platform ports for OpenSSL and need assistance in setting up required pieces (Configurations/x-nonstop.conf) as well as documenting the port. The overall port has two basic aspects that deviate from standard code:

    • Inclusion of platform FLOSS method redirects to emulate Linux behaviour, and
    • Changes to root id - root on NonStop is 65535 rather than 0, and
    • Compiles under c99 rather than gcc.
  • Test 04-test_encoder_decoder.t fails on NonStop x86

    Test 04-test_encoder_decoder.t fails on NonStop x86

    This particular test works fine on 3.0.0 as released and with updates along the 3.0.0 branch. Where it fails is in master:

    04-test_encoder_decoder.t .......... 1/?
    ../../util/wrap.pl ../../test/endecode_test -rsa ../../test/certs/ee-key.pem -pss ../../test/certs/ca-pss-key.pem -context -config ../../test/default.cnf -provider default => 139
    

    This is a reopen of what was #16950 focusing on the real issue rather than the red-herring subject of that issue. I'm trying to figure out what changed between the two branches in a significant way and would like help tracking this down. Running directly and debugging using endecode_test appears to report a 0 completion code when the wrap.pl reports 139.

  • Configure/Makefile: fix some FIPS installation issues

    Configure/Makefile: fix some FIPS installation issues

    This pull request fixes some FIPS installation issues (notably #13679 and #13680), but it is marked as a DRAFT, because

    • I need some help from @levitte for the analoge changes to the VMS template (descrip.mms.tmpl) and
    • there are still some open questions, ~which need to be written down and resolved first~ see followup post.

    For more details, see the commit messages.

    Commits (bottom up)

    Author: Dr. Matthias St. Pierre [email protected] Date: Tue Dec 15 22:44:32 2020 +0100

    Configure/Makefile: correct the FIPS module configuration file path
    
    According to the OpenSSL 3.0 Wiki, the file should be located at
    
        $(OPENSSLDIR)/fipsmodule.cnf
    
    next to the openssl.cnf file.
    

    Author: Dr. Matthias St. Pierre [email protected] Date: Tue Dec 15 22:34:41 2020 +0100

    Configure/Makefile: use the correct openssl app for FIPS installation
    
    The `openssl` app was previously called without a path, which
    would generally invoke the system's copy of the openssl application.
    Currently, that's most likely an openssl version 1.1.1 application,
    which does not recognize the `fipsinstall` command and terminates
    with an error message.
    

    Author: Dr. Matthias St. Pierre [email protected] Date: Tue Dec 15 19:41:58 2020 +0100

    Configure/Makefile: fix the `-macopt` argument of the fipsinstall command
    
    The FIPS hmac key is provided as a hexadezimal string, which needs to
    be be prefixed with `hexkey:`, not `key:`.
    

    Author: Dr. Matthias St. Pierre [email protected] Date: Tue Dec 15 19:41:37 2020 +0100

    Configure/Makefile fix target dependency for the FIPS provider installation
    
    Don't uninstall entire software just because FIPS provider module configuration
    file is removed.
    
    In more technical terms: since the `install_fips` target depends on `install_sw`,
    the `uninstall_sw` target should depend on `uninstall_fips`, not vice versa.
    

    Author: Dr. Matthias St. Pierre [email protected] Date: Tue Dec 15 19:27:41 2020 +0100

    Configure/Makefile: fix Perl error in FIPSMODULENAME declaration
    
    Fixes #13679
    
  • Fix reseeding issues introduced by new RAND_OpenSSL() method

    Fix reseeding issues introduced by new RAND_OpenSSL() method

    Checklist

    • [x] documentation is added or updated (RAND_add() needs to be updated)

    Introduction

    The broken 'RAND_add()/RAND_bytes()' pattern

    In the thread [openssl-dev] Plea for a new public OpenSSL RNG API I explained in detail that the different reseeding concepts of the classic OpenSSL RNG and the new RAND_DRBG API (pushing entropy via RAND_add() vs. pulling entropy via get_entropy() callback) make it so difficult to get both APIs work together in harmony, at least as far as reseeding is concerned. The following is a brief excerpt from that thread:

    In OpenSSL, the classical way for the RNG consumer to add his own randomness is to call RAND_add() before calling RAND_bytes(). If the new RAND_OpenSSL() method (the "compatibility layer" hiding the public RAND_DRBG instance) is the default, then this does not work as expected anymore:

    The reason is that a call to RAND_add() adds the provided randomness only to a global buffer (rand_bytes), from which it will be pulled during the next reseed. But no reseed is triggered. So the next RAND_bytes() call will be unaffected from the RAND_add(), which is not what the consumer expected. (The same holds for RAND_seed(), since drbg_seed() only calls into drbg_add())

    Reseeding of DRBGs occurs only at the following occasions:

    • immediately after a fork() (new)
    • if the reseed_counter exceeds the reseed_interval
    • if RAND_DRBG_generate() is called requesting prediction_resistance
    • RAND_DRBG_reseed() is called explicitely

    Note: Currently it looks like the situation is even worse: if RAND_add() is called multiple times before a reseed occurs, then the result of the previous call is overwritten.

    In this pull request I propose a solution to this problem for general discussion.

    Some background information on seeding the DRBG

    NIST SP 800-90Ar1 has the concept of security_strength. Currently there are three different security strengths for the CTR_DRBG, specified by the NIDs NID_aes_128_ctr, NID_aes_192_ctr, NID_aes_256_ctr. Their parameter values are hardcoded (in ctr_init()) and taken from 'Table 3: Definitions for the CTR_DRBG' on page 49 of NIST SP 800-90Ar1. In particular, there is no need to have an extra RANDOMNESS_NEEDED constant.

    The role of the derivation function for seeding

    The internal state of the CTR_DRBG consists of two vectors

        unsigned char K[<keylen>];
        unsigned char V[<blocklen>];
    

    so the total number of seed bytes (seedlen in Table 3) equals seedlen = keylen + blocklen. (As mentioned earlier: in the NIST document, everything is in bits, whereas in OpenSSL, entropy is in bits, buffer lengths are in bytes).

    Seeding without derivation function

    If no derivation function is used, the unmodified input is used to seed (K,V). This means, one has to provide exactly seedlen=keylen+blocken bytes, which in the case of a high quality entropy source contains much more entropy than needed: 8 * seedlen > security_strength.

    Seeding with derivation function

    If a derivation function is used (which we always do), then the input can be of variable length between drbg->min_entropylen and drbg->max_entropylen. The DF takes a variable length input and produces a pseudorandom output from which (K,V) is seeded. This is done using AES-CTR. In some sense, the DF acts as a meat grinder, compressing the entropy of the input.

    Using the derivation has two advantages: 1) min_entropylen = keylen < seedlen , so you need less input if your input has full entropy and 2) The input can be of variable size min_entropylen < inputsize < max_entropylen , which is good if your input has low entropy (say, only 2 bits per byte).

    All values can be found in Table 3 and are hardcoded in ctr_init():

    	int ctr_init(RAND_DRBG *drbg)
    	{
    		...
    
    		ctr->keylen = keylen;
    		drbg->strength = keylen * 8;
    		drbg->seedlen = keylen + 16;
    
    		if (drbg->flags & RAND_DRBG_FLAG_CTR_USE_DF) {
    			/* df initialisation */
    			static unsigned char df_key[32] = {
    				0x00,0x01,0x02,0x03,0x04,0x05,0x06,0x07,
    				0x08,0x09,0x0a,0x0b,0x0c,0x0d,0x0e,0x0f,
    				0x10,0x11,0x12,0x13,0x14,0x15,0x16,0x17,
    				0x18,0x19,0x1a,0x1b,0x1c,0x1d,0x1e,0x1f
    			};
    			/* Set key schedule for df_key */
    			AES_set_encrypt_key(df_key, drbg->strength, &ctr->df_ks);
    
    			drbg->min_entropylen = ctr->keylen;
    			drbg->max_entropylen = DRBG_MAX_LENGTH;
    			drbg->min_noncelen = drbg->min_entropylen / 2;
    			drbg->max_noncelen = DRBG_MAX_LENGTH;
    			drbg->max_perslen = DRBG_MAX_LENGTH;
    			drbg->max_adinlen = DRBG_MAX_LENGTH;
    		} else {
    			drbg->min_entropylen = drbg->seedlen;
    			drbg->max_entropylen = drbg->seedlen;
    			/* Nonce not used */
    			drbg->min_noncelen = 0;
    			drbg->max_noncelen = 0;
    			drbg->max_perslen = drbg->seedlen;
    			drbg->max_adinlen = drbg->seedlen;
    		}
    
    		...
    	}
    

    The easiest way would be if get_entropy() would allocate a buffer of length max_entropylen and fill it with bytes until the entropy threshold has been reached. However, max_entropylen = DRBG_MAX_LENGTH is an astronomically high value. But this value is only a theoretical upper limit from the NIST document. I changed this members value to a more realistic value:

    	drbg->max_entropylen = 32 * drbg_min_entropylen    /* similar for adinlen, etc. */
    

    This corresponds to the very pessimistic estimate that the entropy of the input lies between 1/4 bits-per-byte and 8 bits-per-byte. That should be enough.

    Now in the callback, the buffer is filled until the required entropy threshold is reached. If the buffer overflows (which should never happen), get_entropy() fails. To facilitate this, I added a new "class" RAND_POOL which acts as container for this variable sized random input.

    This is my vision of how get_entropy() should be used. Even if get_entropy() pulls from /dev/urandom or other full-entropy sources, the implementers should have the freedom to return more than the requested entropy from alternative entropy sources and/or be allowed to return cumulate low entropy input.

    Summary of the pull request

    The solution is split in two parts:

    • Commit 1 fixes the entropy pushing part, i.e. drbg_add()
    • Commit 2 fixes the entropy pulling part, i.e. drbg_get_entropy(), and restores the original semantics of RAND_poll()

    This splitting is only for the moment to keep the changes overseeable and facilitate reviewing. Also, to keep things simple as long this is still WIP, I will avoid force pushing and address comments by adding new commits. I will squash the commits with a proper commit message when this goes out of WIP.

    Commit 1: Make drbg_add() reseed the RAND_DRBG immediately

    The obvious solution to use RAND_DRBG_reseed() creates a circular dependency, because now RAND_add() is involved both in pushing and pulling randomness:

    RAND_add() -> drbg_add() -> RAND_DRBG_reseed() -> get_entropy()
                           -> get_entropy_from_system() -> RAND_poll_ex() -> RAND_add()
    

    Using RAND_DRBG_generate() with additional input (generating and discarding some dummy output) instead of RAND_DRBG_reseed() does not solve the problem, because RAND_DRBG_generatE() can autoreseed occcasionally.

    Instead, we add a new function rand_drbg_add() which is identical to RAND_DRBG_reseed(), except that it does not pull fresh entropy (and consequently does not reset the reseed_counter). This function is used only by the RAND_METHOD drbg_add().

    Now the left hand side becomes:

    RAND_add() -> drbg_add() -> rand_drbg_add()
    

    The first commit breaks RAND_poll_ex(), but this function is rewritten and replaced by RAND_pool_fill() the second commit.

    Commit 2: Cutting the Gordian knot: Decouple the reseeding code from the two RNG APIs

    We do this by adding a new API for collecting entropy: The static fixed size RAND_BYTES_BUFFER is replaced by a more elaborate RAND_POOL "class" which acts as a container for collecting variable length randomness input for the derivation function.

    The functions RAND_poll() and drbg_get_entropy() manage their own instances of such a RAND_POOL object, which they allocate and pass down the stack to the function RAND_POOL_fill() (formerly: RAND_poll_ex(). Since the lifetime and scope of these RAND_POOL objects is limited to the stack frame of RAND_poll() and drbg_get_entropy(), respectively, there is no need for locking.

    Note also, that the RAND_POOL is completely decoupled from the RNG, the RAND_POOL_fill() callback has no notion which kind of RNG is reseeded from the data fed into the pool. Instead, the RAND_POOL class provides a rich API (@richsalz: no pun intended ;-) ) which appears a little oversized if one adheres to the principle that the operating system's RNG is the optimal entropy source with "full entropy" (8 bits per byte) and that it is not necessary to consider additional entropy sources or sources with lower entropy rates.

    However, if one seeks for a flexible way of mixing in various entropy resources, as requested by multiple contributers, then such an API may come in handy. Currently, its just a blueprint and proof-of-concept. It provides a set of accessors providing information to the callbacks on which they could base there decisions on how much entropy should be added from the availabe resources.

    I don't have a concept yet, how such a variable reseeding scheme could be managed and configured. But that's not part of this PR anyway. Input welcome, here or on openssl-dev.

    Remarks

    Randomness vs. Entropy

    Many occurrances of the term "entropy" have been replaced by the more vague term "randomness" only recently. Although being mathematician, I have no problems using "entropy" synonymously to "randomness" in colloquial language. So originally I considered that discussion vain.

    However, now this recent change change turns out to be really handy, because it enables me to consistently distinguish between a double randomness argument and a int entropy argument. The former is a floating point value measured in bytes, whereas the other is an integer value measured in bits and has a strict meaning in the sense of NIST SP800-90Ar1.

    int RAND_POOL_add(RAND_POOL *pool, const void *buffer, int num, double randomness)
    {
        size_t len  = (size_t)num;
        int entropy = (int)(randomness * 8.0);
        ...
    }
    

    TODO(DRBG)

    Some places where I seek particular feedback or closer review have been marked with TODO(DRBG). These TODO's need to be resolved and removed before the PR can go out of WIP.

    In particular, please have a closer look a the TODO(DRBG) comment preceding rand_drbg_add().

    Reviewing and Testing

    Since the RNG is a critical part of OpenSSL, any change to the code is like an open heart surgery. I'm not a seasoned committer and don't have the resources to test it on all platforms and under all circumstances. So I am grateful for any independent testing, in particular the DRBG chaining and forking stuff, since I a am only familiar with libcrypto and not such with libssl.

    What I tested: I successfully ran the standard tests and did a little debugging with gdb to check the main code paths:

    # global DRBG, fetching entropy from os for instantiation     (break at rbg_get_entropy)
    ./util/shlib_wrap.sh gdb --args ./apps/openssl rand -hex 32
    
    # chained DRBG, fetching entropy from parent DRBGfor instantiation   (break at drbg_get_entropy, then add breakpoint inside 'if (drbg->parent)'-clause)
    ./util/shlib_wrap.sh gdb --args ./apps/openssl s_client -host www.openssl.org -port 443
    
    # global DRBG, RAND_add()         (break at drbg_add)
    echo 'This is a random number' > /tmp/randfile
    ./util/shlib_wrap.sh gdb --args ./apps/openssl rand -hex -rand /tmp/randfile  12
    
    # test
    ./util/shlib_wrap.sh gdb --args ./test/drbgtest
    
  • Test 80-test_cmp_http fails at alpha17 on NonStop x86/ia64

    Test 80-test_cmp_http fails at alpha17 on NonStop x86/ia64

    This is a net-new failure compared with alpha16. Virtually every sub-test fails in this test. What information is needed to further investigate? An example:

    # ------------------------------------------------------------------------------
        #   Failed test 'p10cr csr non-existing file'
        #   at test/recipes/80-test_cmp_http.t line 147.
    Warning: certificate from 'trusted.crt' with subject '/O=openssl_cmp' is not a CA cert
    Unable to load PKCS#10 CSR
    error: unable to load PKCS#10 CSR from file 'empty.txt'
    cmp_main:/home/ituglib/randall/openssl-3.0/apps/cmp.c:2778:CMP error: cannot set up CMP context
    # cmp_main:/home/ituglib/randall/openssl-3.0/apps/cmp.c:2602:CMP info: using section(s) 'Mock enrollment' of OpenSSL configuration file '../Mock/test.cnf'
    # opt_str:/home/ituglib/randall/openssl-3.0/apps/cmp.c:2203:CMP warning: -proxy option argument is empty string, resetting option
    # setup_request_ctx:/home/ituglib/randall/openssl-3.0/apps/cmp.c:1488:CMP warning: -subject option is ignored for commands other than 'ir', 'cr', and 'kur' since -ref or -cert is given
    # setup_request_ctx:/home/ituglib/randall/openssl-3.0/apps/cmp.c:1500:CMP warning: -policies option is ignored for commands other than 'ir', 'cr', and 'kur'
    # setup_request_ctx:/home/ituglib/randall/openssl-3.0/apps/cmp.c:1536:CMP warning: -newkeytype option is ignored for 'p10cr' and 'rr' commands
    # setup_request_ctx:/home/ituglib/randall/openssl-3.0/apps/cmp.c:1538:CMP warning: -newkey option is ignored for 'p10cr' and 'rr' commands
    ../../../../util/wrap.pl ../../../../apps/openssl cmp -server '127.0.0.1:61432' -config ../Mock/test.cnf -section 'Mock enrollment' -certout ../../../../test-runs/test_cmp_http/test.cert.pem -proxy '' -no_proxy 127.0.0.1 -cmd p10cr -newkey new.key -newkeypass 'pass:' -certout ../../../../test-runs/test_cmp_http/test.certout_p10cr4.pem -out_trusted root.crt -csr empty.txt => 255
    
  • Reorganize the header files

    Reorganize the header files

    Introduction

    Pull request #9274 started out as a task to clean up inconsistencies in the naming of the include guards. It got stuck when it turned out that not only the #include guards were named inconsistently, but also the header files themselves. Sometimes even the location of the header files in the source tree was inconsistent. After thinking about the problem for a while (see thread on openssl-project), this pull request is my attempt to tackle it properly by first reorganizing the header files consistently before adjusting the names of the include guards.

    Given the fact that OpenSSL 1.1.1 is an LTS version, it is desirable that the reorganization occurs both on master and OpenSSL_1_1_1-stable in order not to hinder future cherry-picking. However, it is impossible to cherry-pick the reorganization of the internal header files without conflicts. For that reason, a different approach will be followed (similar to #9274): The major part of the reorganization will be automated by a script, which has the advantage that the transformation steps are not only well documented, but also reproducible on the OpenSSL_1_1_1-stable branch.

    New include directory structure

    Shared internal header files

    Extending a suggestion by @levitte on openssl-project to move the directory crypto/include/internal => include/internal/crypto, I propose the following organization of the internally shared header files:

       Location      |     Include Directive      |       Include Guard
    =================+============================+=================================
    include          |                            |
      + openssl      | #include <openssl/file.h>  |  #ifndef OPENSSL_FILE_H
      |              |                            |
      + internal     |        = no files =        |
          |          |                            |
          + crypto   | #include "crypto/file.h"   |  #ifndef OPENSSL_CRYPTO_FILE_H
          |          |                            |
          + ssl      | #include "ssl/file.h"      |  #ifndef OPENSSL_SSL_FILE_H
          |          |                            |
          + provider | #include "provider/file.h" |  #ifndef OPENSSL_PROVIDER_FILE_H
          |          |                            |
          + ..etc..  |                            |
    

    (The complete layout still needs to be specified, this is only a draft.)

    Contrary to current practice, which has some disadvantages, the location of a header file doesn't depend on whether it is shared with other sub-systems or only within the same sub-system.

    Local internal header files

    In addition to the shared ones, there are also local header files, which reside along with the source files in the same directory. In order to avoid name collisions, their filenames have one of the suffixes *_locl.h, *_lcl.h, and *_local.h. The suffix should be unified and currently I'm favoring *_lcl.h, because it is most unix-like. But if another suffix is preferred, I'm open for change requests.

    Public header files

    Backporting the internal reorganization is possible without creating compatibility problems, only the public headers need to be treated with special care. Following a suggestion by @paulidale https://github.com/openssl/openssl/pull/9274#issuecomment-507069720, I intend to define the legacy include guard in addition to the new ones:

    include/openssl/file.h:
    
        #ifndef OPENSSL_FILE_H
        # define OPENSSL_FILE_H
        # define HEADER_FILE_H /* obsolete, will be removed in 3.0 */
        # endif
    

    This is going to ensure that applications which use the old include guards externally like this

        #ifndef HEADER_FILE_H
        # include <openssl/file.h>
        #endif
    

    won't fail to compile after the next 1.1.1 bugfix release.

    Implementation

    This pull request contains the fully functional (although not complete) script as a proof-of-concept. You can try it out yourself and do your own experiments. The script produces a lot of diagnostic output, which it saves and commits in the logfiles subdirectory, see d1b3b5b46b.

    How to use it

    If you look at the commits below, you will notice that all automated commits are labelled with [automated] and that a special reference (start-reorganize-header-files) marks the begin of the automated commits:

    d1b3b5b46b (HEAD -> pr-reorganize-header-files) Script succeeded. See 'logfiles' directory for details. [automated] cf8269b745 Add compatibility defines for public header include guards [automated; 1.1.1 only] 76f23ca923 Fix header file include guards [automated] 4fa2ba8fad Reorganize include files [automated] 4a6e4bbbcc Reorganize include files [automated] d7dba04ac7 Reorganize include files [automated] 053b2dcc6d Reorganize include files [automated] b46c754862 (start-reorganize-header-files) Add 'reorganize-header-files' script [automated] 350c9f0753 Remove OPENSSL_X509V3_H guards from cms code 6b684b9ae2 remove HEADER_BSS_FILE_C #include guard 74a6ecd2de util/mkerr.pl: use 'OPENSSL_' as include guard prefix of *err.h files 7a228c391e (origin/master, github/master, master) Replace long dash characters with normal ascii minus

    Prepare the start branch

    All you need to do before running the script yourself for the first time is to set the start-reorganize-header-files branch to the first commit marked [automated]:

    git branch start-reorganize-header-files b46c754862
    

    Run the script

    After that, all you need to do is to execute it from the root of the source tree.

    ./reorganize-header-files
    

    Prepare the start branch [1.1.1]

    The start-reorganize-header-files reference was chosen to be a branch (not a tag) on purpose. It as the advantage, that the commits master...start-reorganize-header-files can easily be rebased on master. They can even be rebased onto OpenSSL_1_1_1-stable without conflicts.

    So to try out the script on the OpenSSL_1_1_1-stable branch, rebase the starting branch start-reorganize-header-files as start-reorganize-header-files-111 onto OpenSSL_1_1_1-stable as follows:

    git checkout -b start-reorganize-header-files-111 start-reorganize-header-files
    git rebase master --onto OpenSSL_1_1_1-stable 
    

    Prepare the start branch [1.1.1]

    As soon as the start branch on 1.1.1 exists, you can apply the script there using the 111 option

    ./reorganize-header-files 111
    

    The script works regardless of which branch you are on, so from now on you can jump around freely between versions 1.1.1 and 3.0.

    Notes

    • The script will even run if you do not create the start branch. If it does not exist, it will create one on-the-fly off the master (resp. OpenSSL_1_1_1-stable) branch.
    • If you want to try out something, go ahead, make your changes and safe the script. Then run the script again (no need to commit your changes, the script will commit itself). See commit message of b46c754862 (or the script itself) for more details about the script.

    How it operates

    Step 0: Some preparations

    The script resets the pull request branch to a certain starting point. As first action, it commits itself to the branch. After that, it carries out steps 1 and 2. Having the script committed in the branch has two advantages, namely

    • The automated commits are implicitly documented by having the script available
    • the script supports being edited and reapplied to regenerate the automated commits

    All changes commited by the script are currently indicated by the [autogenerated] tag in the commit message title. This tag is for clarity and will be removed before the pull request goes out of WIP.

    Step 1: Reorganize the header files

    • Move crypto/include/internal => crypto/include/crypto (and rename the *_int.h suffixes to *.h)
    • Create additional directores include/internal/ssl, ... for other sub-systems and spread out the header files currently lying under include/internal into the appropriate sub-directory.
    • Unify the suffixes of the *_locl.h, *_lcl.h, and *_local.h

    Step 2: Adjust the header file include guards

    The includes are fixed automatically using fixed naming rules. For details, see the source code of the reorganize-header-files script and the logfiles directory.

  • Add EVP/KDF API

    Add EVP/KDF API

    This PR adds a new EVP/KDF API that collects all KDFs and PRFs under the one API.

    #include <openssl/kdf.h>

    Currently some KDFs are available directly (PBKDF2 and scrypt) while others are available through the PKEY API (scrypt, TLS1 PRF and HKDF) even though the PKEY API was originally intended for Public Key algorithms. Note that the low level KDF functions (PKCS5_PBKDF2_HMAC and EVP_PBE_scrypt) are defined in openssl/evp.h even though EVP is the high level interface.

    The new API is modeled after the current KDF support under the PKEY API in order to minimize the work required to update applications to use the new API. Support is included for PBKDF2, scrypt, TLS1 PRF and HKDF. PBKDF1 and PKCS12 KDF are not implemented.

    The low level KDF functions and PKEY KDF support have been changed to wrap the new API. Other parts of OpenSSL have not yet been updated to call the new API.

    Documentation to follow.

    • [x] documentation is added or updated
    • [x] tests are added or updated
  • Support multi-prime RSA (RFC 8017)

    Support multi-prime RSA (RFC 8017)

    This feature is very useful if someone wants to reduce the cost of hardware accelerators and can ~be~ tolerate with a less security key. [This implementation is based on RFC 8017]

    Some performance data by using openssl speed: 2-prime: 7979 3-prime: 9908 5-prime: 18617 8-prime: 24878 15-prime: 31811 (quantity of RSA 2048-bit private key operations in 10s)

    Also, the generation time of 4096-bit key: 2-prime: 1.237 3-prime: 0.467 5-prime: 0.237 8-prime: 0.098 15-prime: 0.080 (in seconds)

    To be simplified, the maximum number of primes is limited to 16.

    After I finished this patch, I just found this previous work accidentally: https://rt.openssl.org/Ticket/Display.html?id=3477&user=guest&pass=guest. This is a 3 years old patch and was closed in the 'bug bankruptcy ' movement last year.

    Note: This patch might be buggy, consider it as an experimental feature. Let's focus on discussing if the feature is worth being included into master...

    Patent Caution: If I understand correctly, all related patents are expired on Jan 2017. (US5848159 and US7231040)

    • Introduce RSA_generate_multi_prime_key to generate multi-prime RSA private key. As well as the following functions: RSA_generate_multi_prime_key RSA_get_multi_prime_num RSA_get0_multi_prime_factors RSA_get0_multi_prime_crt_params RSA_set0_multi_prime_params RSA_set_version RSA_get_version
    • Support EVP operations for multi-prime RSA
    • Support ASN.1 operations for multi-prime RSA
    • Support multi-prime check in RSA_check_key_ex
    • Support multi-prime RSA in apps/genrsa and apps/speed
    • Support multi-prime RSA manipulation functions
    • Test cases and documentation are added
    Checklist
    • [x] documentation is added or updated
    • [x] tests are added or updated
  • OSSL_STORE 'file' loader: Try several pass phrase variants for PKCS#12

    OSSL_STORE 'file' loader: Try several pass phrase variants for PKCS#12

    Pass phrases for PKCS#12 objects are problematic, as our conversion to BMPString was very naïve in OpenSSL <1.1.0, and while being less so in OpenSSL >=1.1.0, it still doesn't account for the application locale.

    OSSL_STORE, on the other hand, is supposed to be fairly agnostic to the types of objects it loads, and thereby all internal intricaties concerning pass phrases. Therefore, we need to create a few variants of the given pass phrase when trying to open a PKCS#12 object, with the hope that this will work on PKCS#12 objects generated by OpenSSL <1.1.0 as well as OpenSSL >=1.1.0 as well as other software.

    While doing this, we need to make sure the locale is set correctly. Fortunately, that's a simple setlocale(LC_ALL, "").

    Ideas largely inspired by @dwmw2

  • OpenSSL 3.0.0-alpha6 6 Aug 2020 breaks perl Net::DNS::SEC ECDSA signature generation

    OpenSSL 3.0.0-alpha6 6 Aug 2020 breaks perl Net::DNS::SEC ECDSA signature generation

    The problem does not occur in the signing process itself. This statement fails with an exception raised in checkerr():

    	checkerr( EVP_DigestSignInit( ctx, NULL, md, NULL, pkey ) );
    
    

    Returned value is 0, not 1 as expected. Code works ok with alpha5 and all earlier releases. I have not been following the daily snapshots, so unable to be more precise.

    Problem occurs for both ECDSAP256SHA256 and ECDSAP384SHA384 signature generation. Signature verification is not affected which should rule out problems with md.

  • TLS 1.3: add 'integrity-only' cipher suites

    TLS 1.3: add 'integrity-only' cipher suites

    In comparison to earlier versions, regular TLS 1.3 does no more offer cipher suites without encryption. On the other hand, as motivated for instance in RFC 9150 section 3, there are various use cases for cipher suites in TLS that only provide authentication and integrity protection, in particular in industrial automation and IoT. So far, such use cases cannot be implemented with TLS 1.3 and thus are stuck with TLS 1.2, at least when based on OpenSSL.

    This feature request is for optionally supporting the cipher suites TLS_SHA256_SHA256 and TLS_SHA384_SHA384 as defined in RFC 9150 section 4 to 8.

    There is already a PoC implementation of 2019/20 by Yiannis Stavrou of Nozomi Networks: https://github.com/NozomiNetworks/openssl/commits/enull-tls13-openssl111 based on OpenSSL 1.1.1. I just had a look at it and rebased it locally to the current master. I did not spend effort on figuring out whether it is correct and fully functional, but just found that the general TLS tests have not been adapted/extended to it, and so far a number of them fail. Is there anyone who has already taken this development further or has done an independent implementation based on OpenSSL?

  • Documentation of X509_INFO missing?

    Documentation of X509_INFO missing?

    I'm compiling openssl 1.1.1 and use that and curl in C-code.

    I have looked at this curl example and try to understand the callback function which adds certificates using openssl library. Searching the online documentation for library functions https://www.openssl.org/docs/man1.1.1/man3/ I can't find any reference of functions including X509_INFO.

    But checking in my local openssl 1.1.1 source code I can find functions like PEM_X509_INFO_read and PEM_X509_INFO_read_bio in include/openssl/pem.h. The same file on GitHub master include/openssl/pem.h has these functions too.

    Searching the 3.0 pages https://www.openssl.org/docs/man3.0/man3/ for X509_INFO I can find two functions, one of them is PEM_X509_INFO_read_ex which according to the 3.0 migrating instructions https://www.openssl.org/docs/man3.0/man7/migration_guide.html is the replacement function for PEM_X509_INFO_read(3) when using a library context, but this is a dead link to man3.0 pages. Changing the URL to 1.1.1 also gives a dead link, see these below:

    • https://www.openssl.org/docs/man3.0/man3/PEM_X509_INFO_read.html
    • https://www.openssl.org/docs/man1.1.1/man3/PEM_X509_INFO_read.html

    Questions

    • Is there documentation missing for X509_INFO functions like PEM_X509_INFO_read in both 1.1.1 and 3.0?
    • Are the X509_INFO structs and functions not public/recommended to use?
  • Expected behavior when comparing UTF8STRING and PRINTABLESTRING during DN matching?

    Expected behavior when comparing UTF8STRING and PRINTABLESTRING during DN matching?

    Consider this scenario:

    image

    The two strings are obviously identical so the error message is somewhat misleading.

    So where is the difference then?

    This is the CA certificate: image

    And this is the CSR: image

    I think some clarification is needed on this.

    1. Is this string comparison expected to fail even when PRINTABLESTRING and UTF8STRING representations are byte-identical?
    2. If it is supposed to fail, why the error message does not reflect that by saying that field ASN.1 encodings do not match instead of saying that the fields don't match?

    I am aware that I can just ignore this mismatch by setting stateOrProvinceName to be optional in the OpenSSL config policy section, but I would like to know whether this is an error or expected behavior. If it is expected I think it should have a better error message.

  • Deprecate long

    Deprecate long

    I think we should deprecate use of long and unsigned long in the OpenSSL codebase.

    long is used a lot in the codebase in contexts where size_t or ossl_ssize_t would be more appropriate, for example to specify buffer lengths. There seems to be an assumption that unsigned long is the same as size_t but this is not the case on 64-bit Windows, where long is still 32-bit. We probably have a lot of subtle bugs on Windows because of this.

    In general, I can't think of any circumstance where using long is a good idea.

  • MacOS fips library has unexpected external symbols.

    MacOS fips library has unexpected external symbols.

    Running with a config such as

    > ./config -Werror enable-fips --strict-warnings
    

    Using Linux I get the expected result:

    > nm -g --defined-only providers/fips.so
    000000000001a0b9 T OSSL_provider_init
    

    On Mac however it appears all the extern decls are visible:

    > nm -gU providers/fips.dylib
    0000000000002fe0 T _AES_cbc_encrypt
    0000000000002a30 T _AES_decrypt
    00000000000024a0 T _AES_encrypt
    0000000000002db0 T _AES_set_decrypt_key
    0000000000002af0 T _AES_set_encrypt_key
    000000000019b850 T _BIO_snprintf
    0000000000016a70 T _BN_BLINDING_convert
    ...
    ...
    

    Could the -fvisibility=hidden option be used somehow?

    Reported by @davidmakepeace

A stable nginx module for SSL/TLS ja3 fingerprint, with high performance.

nginx-ssl-fingerprint A stable nginx module for SSL/TLS ja3 fingerprint, with high performance. Description This module adds new nginx variables for t

May 18, 2022
s2n : an implementation of the TLS/SSL protocols
s2n : an implementation of the TLS/SSL protocols

s2n-tls is a C99 implementation of the TLS/SSL protocols that is designed to be simple, small, fast, and with security as a priority. It is released a

May 9, 2022
An open source, portable, easy to use, readable and flexible SSL library

README for Mbed TLS Mbed TLS is a C library that implements cryptographic primitives, X.509 certificate manipulation and the SSL/TLS and DTLS protocol

May 18, 2022
Obtain and parse SSL certificates

CheckCert A small utility to request the SSL certificate from a public or private web application. CheckCert helps operators in the following ways: It

Apr 5, 2022
The UAPKI is crypto library for using in PKI with support of Ukrainian and internationlal cryptographic standards.

UAPKI The UAPKI is crypto library for using in PKI with support of Ukrainian and internationlal cryptographic standards. Fork from Cryptonite. Expert

Apr 26, 2022
A modern, portable, easy to use crypto library.
A modern, portable, easy to use crypto library.

Sodium is a new, easy-to-use software library for encryption, decryption, signatures, password hashing and more. It is a portable, cross-compilable, i

May 15, 2022
A lightweight, secure, easy-to-use crypto library suitable for constrained environments.
A lightweight, secure, easy-to-use crypto library suitable for constrained environments.

The Hydrogen library is a small, easy-to-use, hard-to-misuse cryptographic library. Features: Consistent high-level API, inspired by libsodium. Instea

May 19, 2022
inetd-style TLS encryption wrapper

Description The tlswrapper is an TLS encryption wrapper between remote client and local program prog. Is executed from systemd.socket/inetd/tcpserver/

Feb 23, 2022
A Powerful, Easy-to-Use, Compact, Cross-Platform and Installation-Free Crypto Tool. 一个强大,易用,小巧,跨平台且免安装的加密解密签名工具。
A Powerful, Easy-to-Use, Compact, Cross-Platform and Installation-Free Crypto Tool. 一个强大,易用,小巧,跨平台且免安装的加密解密签名工具。

GpgFrontend GpgFrontend is a Powerful, Easy-to-Use, Compact, Cross-Platform, and Installation-Free OpenPGP Crypto Tool. By using GpgFrontend, you can

May 9, 2022
DARKCAT Project - A Strong Prototype Crypto-Locker
DARKCAT Project - A Strong Prototype Crypto-Locker

Darkcat is an Open Source Crypto-locker directed at an audience with an interest in the field of Cyber Security. The locker is similar to how very obnoxious Ransomwares operate using 2-Layer Key Encryption with the intent of making it almost impossible to recover any key from memory even during the event of Encryption.

Apr 17, 2022
Malware that replaces copied crypto addresses with yours.
Malware that replaces copied crypto addresses with yours.

Crypto-Clipper Malware which replaces copied crypto addresses with yours. ?? Features Multiple cryptos supported (BTC, LTC, ETH, DOGE, DASH, NEO, BCH,

Apr 25, 2022
MIRACL Cryptographic SDK: Multiprecision Integer and Rational Arithmetic Cryptographic Library is a C software library that is widely regarded by developers as the gold standard open source SDK for elliptic curve cryptography (ECC).

MIRACL What is MIRACL? Multiprecision Integer and Rational Arithmetic Cryptographic Library – the MIRACL Crypto SDK – is a C software library that is

May 4, 2022
x509cert is a tool and library for generating X.509 certificates and certificate requests.

x509cert is a tool and library for generating X.509 certificates and certificate requests. It is written in C99 and uses BearSSL to decode keys and compute signatures.

Nov 25, 2021
HashLibPlus is a recommended C++11 hashing library that provides a fluent interface for computing hashes and checksums of strings, files, streams, bytearrays and untyped data to mention but a few.

HashLibPlus HashLibPlus is a recommended C++11 hashing library that provides a fluent interface for computing hashes and checksums of strings, files,

Apr 11, 2022
Library and command line tool to detect SHA-1 collision in a file

sha1collisiondetection Library and command line tool to detect SHA-1 collisions in files Copyright 2017 Marc Stevens [email protected] Distributed

May 10, 2022
Tink is a multi-language, cross-platform, open source library that provides cryptographic APIs that are secure, easy to use correctly, and hard(er) to misuse.

Tink A multi-language, cross-platform library that provides cryptographic APIs that are secure, easy to use correctly, and hard(er) to misuse. Ubuntu

May 12, 2022
PTHash is a C++ library implementing fast and compact minimal perfect hash functions

Fast and compact minimal perfect hash functions in C++.

May 11, 2022
Header-only C++11 library to encode/decode base64, base64url, base32, base32hex and hex (a.k.a. base16) as specified in RFC 4648, plus Crockford's base32. MIT licensed with consistent, flexible API.

cppcodec Header-only C++11 library to encode/decode base64, base64url, base32, base32hex and hex (a.k.a. base16) as specified in RFC 4648, plus Crockf

May 19, 2022
Mbedcrypto - a portable, small, easy to use and fast c++14 library for cryptography.

mbedcrypto mbedcrypto is a portable, small, easy to use, feature rich and fast c++14 library for cryptography based on fantastic and clean mbedtlsnote

Mar 24, 2022