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 matthias.[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
  • Address coverity issue CID 1517105

    Address coverity issue CID 1517105

    The code path for this resource leak indicates that this is a false positive (if you look at the callers). Rather than ignoring the warning an extra check has been added, in case future callers do the wrong thing.

    • [ ] documentation is added or updated
    • [ ] tests are added or updated

    There are no additional tests as this is a false positive.

    branch: master approval: review pending approval: otc review pending tests: exempted 
    opened by slontis 0
  • PKCS12_parse(): should MAC check be optional?

    PKCS12_parse(): should MAC check be optional? initially frames this in terms "mac-less" files (of which there is some question about the legitimacy), but @t8m raises a question that I don't think was ever really resolved: basically how to reconcile the MAC check with the FIPS universe. Besides this check, PKCS12_parse() works just fine with FIPS provider query set, at least in the case of a NULL password (didn't try otherwise).

    I note that the pkcs12 app man page suggests some awareness of this issue:

    -nomac Do not attempt to provide the MAC integrity. This can be useful with the FIPS provider as the PKCS12 MAC requires PKCS12KDF which is not an approved FIPS algorithm and cannot be supported by the FIPS provider.

    Really I think the question is more general, EVP_default_properties_enable_fips(NULL, 1) is just the most likely scenario. Say the PKCS12KDF isn't available from any providers for some other reason. Should the MAC check still be treated as mandatory, even when the password thrown at PKCS12_parse() is NULL?

    Someone may correct my standards parsing, but given this isn't an over-the-wire protocol thing it seems like the check is a "SHOULD" situation. It also doesn't seem like the PKCS12_parse() man page is providing any kind of assurance that this check is performed.

    issue: bug report 
    opened by jwalch 0
  • Installation fails when calling make install to a Windows system directory (clang, Mingw, Windows 10 Home)

    Installation fails when calling make install to a Windows system directory (clang, Mingw, Windows 10 Home)

    I am attempting to set the installation directory to C:\Windows\System32\OpenSSL The two DLLs are generated successfully in the requested system directory, however the script fails before the EXE is created.

    Here is the error when running make install_sw:

    install ./include/openssl/x509.h -> C:/Windows/System32/OpenSSL/include/openssl/x509.h
    install ./include/openssl/x509_vfy.h -> C:/Windows/System32/OpenSSL/include/openssl/x509_vfy.h
    install ./include/openssl/x509err.h -> C:/Windows/System32/OpenSSL/include/openssl/x509err.h
    install ./include/openssl/x509v3.h -> C:/Windows/System32/OpenSSL/include/openssl/x509v3.h
    install ./include/openssl/x509v3err.h -> C:/Windows/System32/OpenSSL/include/openssl/x509v3err.h
    install libcrypto.a -> C:/Windows/System32/OpenSSL/lib/libcrypto.a
    C:\msys64\mingw32\bin\ranlib.exe: 'C:/Windows/System32/OpenSSL/lib/': No such file
    make: *** [Makefile:2985: install_dev] Error 1

    However, I can see the file in that directory.

    I created a "patched" configure file that allowed me to pass in a full Windows path:

    sed \
       -e 's/die "Directory given with --prefix/print "Directory given with --prefix/g' \
       -e 's/"aria",$/"apps", "aria",/g' \
       < ./Configure > ./Configure-patched
    chmod a+x ./Configure-patched
    $ perl --dump
    Command line (with current working directory = .):
        perl ./Configure mingw -Wno-unused-command-line-argument no-tests no-unit-test -fno-ident -Wa,--noexecstack -Qunused-arguments --target=x86_64-w64-mingw32 --release no-dso no-loadereng no-padlockeng no-ssl-trace no-filenames no-module --prefix=C:/Windows/System32/OpenSSL --openssldir=ssl --libdir=lib
    Perl information:
        5.36.0 for x86_64-msys-thread-multi
    Enabled features:
    Disabled features:
        acvp-tests          [cascade]   OPENSSL_NO_ACVP_TESTS
        afalgeng            [not-linux] OPENSSL_NO_AFALGENG
        asan                [default]   OPENSSL_NO_ASAN
        buildtest-c++       [default]
        crypto-mdebug       [default]   OPENSSL_NO_CRYPTO_MDEBUG
        devcryptoeng        [default]   OPENSSL_NO_DEVCRYPTOENG
        dso                 [option]    OPENSSL_NO_DSO
        dynamic-engine      [cascade]
        ec_nistp_64_gcc_128 [default]   OPENSSL_NO_EC_NISTP_64_GCC_128
        egd                 [default]   OPENSSL_NO_EGD
        external-tests      [default]   OPENSSL_NO_EXTERNAL_TESTS
        filenames           [option]    OPENSSL_NO_FILENAMES
        fips                [default]
        fips-securitychecks [cascade]   OPENSSL_NO_FIPS_SECURITYCHECKS
        fuzz-afl            [default]   OPENSSL_NO_FUZZ_AFL
        fuzz-libfuzzer      [default]   OPENSSL_NO_FUZZ_LIBFUZZER
        ktls                [default]   OPENSSL_NO_KTLS
        loadereng           [option]    OPENSSL_NO_LOADERENG
        md2                 [default]   OPENSSL_NO_MD2 (skip crypto/md2)
        module              [option]
        msan                [default]   OPENSSL_NO_MSAN
        padlockeng          [option]    OPENSSL_NO_PADLOCKENG
        rc5                 [default]   OPENSSL_NO_RC5 (skip crypto/rc5)
        sctp                [default]   OPENSSL_NO_SCTP
        ssl-trace           [option]    OPENSSL_NO_SSL_TRACE
        tests               [option]    OPENSSL_NO_TESTS
        trace               [default]   OPENSSL_NO_TRACE
        ubsan               [default]   OPENSSL_NO_UBSAN
        unit-test           [option]    OPENSSL_NO_UNIT_TEST
        weak-ssl-ciphers    [default]   OPENSSL_NO_WEAK_SSL_CIPHERS
        zlib                [default]
        zlib-dynamic        [default]
        ssl3                [default]   OPENSSL_NO_SSL3
        ssl3-method         [default]   OPENSSL_NO_SSL3_METHOD
    Config target attributes:
        AR => "ar",
        ARFLAGS => "qc",
        CC => "gcc",
        CFLAGS => "-Wall -O3 -fomit-frame-pointer",
        HASHBANGPERL => "/usr/bin/env perl",
        RANLIB => "ranlib",
        RC => "windres",
        asm_arch => "x86",
        bn_ops => "BN_LLONG",
        build_file => "Makefile",
        build_scheme => [ "unified", "unix" ],
        cflags => "-m32",
        cppflags => "-DUNICODE -D_UNICODE -DWIN32_LEAN_AND_MEAN -D_MT",
        defines => [ "OPENSSL_BUILDING_OPENSSL" ],
        disable => [  ],
        dso_scheme => "win32",
        enable => [  ],
        ex_libs => "-lws2_32 -lgdi32 -lcrypt32",
        includes => [  ],
        lflags => "",
        lib_cflags => "",
        lib_cppflags => "-DL_ENDIAN",
        lib_defines => [  ],
        module_cflags => "",
        module_cxxflags => undef,
        module_ldflags => "-static-libgcc -shared -Wl,--enable-auto-image-base",
        multilib => "",
        perl_platform => "mingw",
        perlasm_scheme => "coff",
        shared_argfileflag => "\@",
        shared_cflag => "",
        shared_cppflags => "_WINDLL",
        shared_defflag => "",
        shared_defines => [  ],
        shared_impflag => "-Wl,--out-implib=",
        shared_ldflag => "-static-libgcc -shared -Wl,--enable-auto-image-base",
        shared_rcflag => "--target=pe-i386",
        shared_target => "mingw-shared",
        sys_id => "MINGW32",
        thread_defines => [  ],
        thread_scheme => "winthreads",
        unistd => "<unistd.h>",
        uplink_arch => "x86",
    Recorded environment:
        AR =
        BUILDFILE =
        CC = clang
        CFLAGS =
        CPPFLAGS =
        CXX =
        CXXFLAGS =
        LDFLAGS =
        LDLIBS =
        PERL =
        RANLIB =
        RC =
        RCFLAGS =
        WINDRES =
        __CNF_CFLAGS =
        __CNF_CPPDEFINES =
        __CNF_CPPFLAGS =
        __CNF_CXXFLAGS =
        __CNF_LDFLAGS =
        __CNF_LDLIBS =
        AR              = ar
        ARFLAGS         = qc
        CC              = clang
        CFLAGS          = -Wall -O3 -fomit-frame-pointer -Wno-unused-command-line-argument -fno-ident -Wa,--noexecstack -Qunused-arguments --target=x86_64-w64-mingw32
        CPPDEFINES      =
        CPPFLAGS        =
        CPPINCLUDES     =
        CXXFLAGS        = -Wno-unused-command-line-argument -fno-ident -Wa,--noexecstack -Qunused-arguments --target=x86_64-w64-mingw32
        HASHBANGPERL    = /usr/bin/env perl
        LDFLAGS         =
        LDLIBS          =
        PERL            = perl
        RANLIB          = ranlib
        RC              = windres
        RCFLAGS         =
    NOTE: These variables only represent the configuration view.  The build file
    template may have processed these variables further, please have a look at the
    build file for more exact data:
    build file:
    build file templates:
    make clean; make build_sw
    make install_sw
    issue: bug report 
    opened by FoxyBee 1
  • Improve the QUIC_RSTREAM implementation

    Improve the QUIC_RSTREAM implementation

    Add API calls to avoid copying data when reading These are ossl_quic_rstream_get_record() and ossl_quic_rstream_release_record().

    Add side storage for the stream frame data. When there are too many packets referenced by the receiving stream the function ossl_quic_rstream_move_to_rbuf() can be called to move the data to a ring buffer.

    • [ ] tests are added or updated
    branch: master triaged: feature 
    opened by t8m 1
  • EVP_CIPHER_CTX_rand_key() does not validate that ctx->cipher is set

    EVP_CIPHER_CTX_rand_key() does not validate that ctx->cipher is set

    ctx->cipher is accessed directly without check on line 1350 which is common in other functions:

    1348  int EVP_CIPHER_CTX_rand_key(EVP_CIPHER_CTX *ctx, unsigned char *key)
    1349  {
    1350      if (ctx->cipher->flags & EVP_CIPH_RAND_KEY)
    1351          return EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_RAND_KEY, 0, key);

    See for example:

    1368  int EVP_CIPHER_CTX_copy(EVP_CIPHER_CTX *out, const EVP_CIPHER_CTX *in)
    1369  {
    1370      if ((in == NULL) || (in->cipher == NULL)) {

    Note that NULL checks are not consistent in evp_enc.c and ERR_raise() is missing on any places too.

    triaged: feature 
    opened by Hlipa 1
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 Nov 20, 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 Dec 1, 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

Arm Mbed 3.8k Nov 25, 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

Sanjiv Kawa 80 Nov 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 Nov 29, 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.6k Nov 24, 2022
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 445 Nov 22, 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 187 Nov 16, 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
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žíš 3 Nov 30, 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 9 Nov 11, 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 517 Nov 22, 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.

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

Marc Stevens 1.2k Nov 19, 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.8k Nov 27, 2022
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 86 Nov 28, 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

Topology 489 Nov 29, 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