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

Table of Contents


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


For Production Use

Source code tarballs of the official releases can be downloaded from 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 There is a GitHub mirror of the repository at, 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://

or from the GitHub mirror using

git clone

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

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.


Manual Pages

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


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


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.


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


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


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 (c) 1998-2021 The OpenSSL Project

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

All rights reserved.

  • mingw after refactor-build: misc issues

    mingw after refactor-build: misc issues

    Testing mingw after build refactor (, using configuration that worked for 1.1.0-pre1/2 and 1.0.2, an early abort is the result:

    Can't locate Text/ 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/ line 20.
    BEGIN failed--compilation aborted at util/ line 45.


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

    /cc @levitte

    opened by vszakats 362
  • HPKE pr

    HPKE pr

    Hi, this PR proposes an implementation of HPKE, as discussed in #14748 which is now RFC9180.

    Something doing this is required for supporting ECH (see also #7482) and other draft IETF specifications. (I have a fork that implements ECH draft-13 that uses this and hope to follow up with a PR for that once the ECH specification is ready, hopefully in a few months.)

    I'd be happy to adjust the API defined here if (as I expect) that's needed for consistency with other APIs.

    Since this is my first PR, I fully expect to have to re-do stuff, so apologies for whatever I've gotten wrong already:-)

    • [x] documentation is added or updated
    • [x] tests are added or updated
    branch: master approval: ready to merge triaged: feature severity: fips change tests: present 
    opened by sftcd 216
  • 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.
    issue: feature request 
    opened by rsbecker 182
  • 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/ ../../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 reports 139.

    triaged: bug 
    opened by rsbeckerca 128
  • 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
    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
    branch: master approval: ready to merge triaged: OTC evaluated 
    opened by mspncp 124
  • Fix reseeding issues introduced by new RAND_OpenSSL() method

    Fix reseeding issues introduced by new RAND_OpenSSL() method


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


    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] = {
    			/* 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.


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


    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/ 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/ gdb --args ./apps/openssl s_client -host -port 443
    # global DRBG, RAND_add()         (break at drbg_add)
    echo 'This is a random number' > /tmp/randfile
    ./util/ gdb --args ./apps/openssl rand -hex -rand /tmp/randfile  12
    # test
    ./util/ gdb --args ./test/drbgtest
    branch: master 
    opened by mspncp 122
  • 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/ ../../../../apps/openssl cmp -server '' -config ../Mock/test.cnf -section 'Mock enrollment' -certout ../../../../test-runs/test_cmp_http/test.cert.pem -proxy '' -no_proxy -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
    branch: master triaged: bug 
    opened by rsbeckerca 121
  • Reorganize the header files

    Reorganize the header files


    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, I intend to define the legacy include guard in addition to the new ones:

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

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


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


    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.


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

    approval: done branch: master 
    opened by mspncp 114


    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
    approval: done branch: master 
    opened by davidmakepeace 111
  • 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: 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
    • [x] documentation is added or updated
    • [x] tests are added or updated
    approval: done 
    opened by InfoHunter 97
  • 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

    branch: master branch: 1.1.1 
    opened by levitte 96
  • Add support for mandating use of EMS in TLS 1.2

    Add support for mandating use of EMS in TLS 1.2

    FIPS 140-3 Implementation Guidance requires that only EMS KDF in TLS 1.2 can be used with modules validated after May 16, 2023 (see "D.Q Transition of the TLS 1.2 KDF to Support the Extended Master Secret").

    Please add a setting that would enable and require negotiation of EMS extension for TLS 1.2 connections. That setting then could default to enabled when operating in FIPS mode.

    issue: feature request hold: need otc decision 
    opened by tomato42 0
  • 20:unable to get local issuer certificate

    20:unable to get local issuer certificate

    I use the current OpenSSL 1.1.1.s I have generated the required SSL files for FHEM. [email protected]:~ $ sudo su

    openssl req -x509 -out localhost.crt -keyout localhost.key
    -newkey rsa:2048 -nodes -sha256
    -subj '/CN=localhost' -extensions EXT -config <(
    printf "[dn]\nCN=localhost\n[req]\ndistinguished_name = dn\n[EXT]\nsubjectAltName=DNS:localhost\nkeyUsage=digitalSignature\nextendedKeyUsage=serverAuth")

    openssl req -new -x509 -newkey rsa:2048 -keyout ca-key.pem -out ca-cert.pem -days 10950 openssl genrsa -out server-key.pem -aes256 2048 openssl rsa -in server-key.pem -out server-key.pem openssl req -new -key server-key.pem -out req.pem -nodes

    nano /etc/ssl/openssl.cnf dir = . # Where everything is kept

    new_certs_dir = $dir # default place for new certs

    certificate = $dir/ca-cert.pem # The CA certificate

    private_key = $dir/ca-key.pem # The private key RANDFILE = $dir/.rand # private random number file

    default_days = 10950 # how long to certify for

    [ policy_match ]: stateOrProvinceName = optional

    echo 01 > serial touch index.txt

    openssl ca -in req.pem -notext -out server-cert.pem

    The ca-cert.pem, server-cert.pem and server-key.pem files are stored in the /opt/fhem/certs directory. FHEM also works with these files so far.

    Now I get error messages during the tests on the console that I could not correct. However, the approaches found on the Internet did not get me any further. openssl s_client -connect -showcerts respectively. openssl s_client -connect -showcerts

    verify error:num=20:unable to get local issuer certificate verify error:num=21:unable to verify the first certificate

    As far as I found out, it must be a configuration error in the openssl.cnf. But with the best will in the world I can't find a solution.

    Maybe someone has a tip for me.

    triaged: question 
    opened by Burny4600 0
  • OpenSSL failed to verify cms document

    OpenSSL failed to verify cms document

    Hello, OpenSSL community,

    I faced the problem and can't find any solution or explanation for this problem. I have built CMS file with Botan library tools, and my CMS document looks exactly the same as the document generated with openssl cms -sign command except for a signing time and the signature.

    I have separately verified the signature with openssl command: openssl dgst -sha256 -verify pub_key.pem -signature signature.txt signer_attributes.txt And the output was: Verified OK

    But I can't verify the CMS document itself with the command: openssl cms -verify -CAfile ca_test.crt -inform der -signer cert.crt -in cms.p7b

    I am getting error:

    70288:error:04091068:rsa routines:int_rsa_verify:bad signature:../openssl-1.1.1l/crypto/rsa/rsa_sign.c:220:
    70288:error:2E09809E:CMS routines:CMS_SignerInfo_verify:verification failure:../openssl-1.1.1l/crypto/cms/cms_sd.c:767:

    ssl version is 1.1.1

    Thank you in advance for any help!

    branch: 1.1.1 triaged: question 
    opened by BrooklynBoy21 0
  • about the new PSS saltlen parameter in 3.1

    about the new PSS saltlen parameter in 3.1

    Following the 3.1 docs for RSA signature here, the saltlen parameter has acquired a new posisble value: "auto-digestmax". Does it mean existing signature providers should be updated to handle this value?

    Ours is a built-in provider used only to sign during TLS handshake when private key is external. And, it seems to always get called with saltlen set to "digest" even in OpenSSL 3.1.0-beta1 --- as seen in OSSL_PARAMS passed to provider's digest_sign_init() or sign_init(). Is there a way to force TLS handshake to use different saltlen parameters for testing?

    triaged: question resolved: answered 
    opened by selvanair 1
  • s390x: Fix keccak xofs via CPACF

    s390x: Fix keccak xofs via CPACF

    CPACF does not directly support xofs. Emulate this by using single block operations on an empty input block.

    Fixes: affc070aabc9 ("s390x: Optimize kmac")

    Signed-off-by: Juergen Christ [email protected]

    branch: master approval: review pending triaged: bug severity: fips change branch: 3.1 
    opened by juergenchrist 2
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

phuslu 50 Dec 14, 2022
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

Amazon Web Services 4.2k Jan 4, 2023
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

Arm Mbed 3.9k Jan 7, 2023
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

Sanjiv Kawa 81 Dec 19, 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

null 25 Dec 23, 2022
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

Frank Denis 10.7k Jan 4, 2023
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

Frank Denis 457 Dec 21, 2022
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

Saturn&Eric 203 Jan 7, 2023
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/

Jan Mojžíš 2 Dec 22, 2022
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.

Alexander Töpfer 28 Jul 21, 2022
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,

Voltic 8 Dec 22, 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

MIRACL 524 Jan 2, 2023
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.

Michael Forney 10 Sep 5, 2022
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,

Telepati 6 Dec 22, 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

Marc Stevens 1.2k Dec 29, 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

Google 12.9k Jan 9, 2023
PTHash is a C++ library implementing fast and compact minimal perfect hash functions

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

Giulio Ermanno Pibiri 90 Jan 3, 2023
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

Topology 491 Dec 28, 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

amir zamani 38 Nov 22, 2022