Name |
Date |
Size |
#Lines |
LOC |
||
---|---|---|---|---|---|---|
.. | - | - | ||||
Configurations/ | 12-May-2024 | - | 10,149 | 8,665 | ||
VMS/ | 12-May-2024 | - | 452 | 400 | ||
apps/ | 12-May-2024 | - | 57,402 | 48,514 | ||
crypto/ | 12-May-2024 | - | 510,084 | 404,740 | ||
demos/ | 12-May-2024 | - | 8,947 | 5,829 | ||
doc/ | 12-May-2024 | - | 130,103 | 92,455 | ||
engines/ | 12-May-2024 | - | 10,808 | 8,381 | ||
external/perl/ | 12-May-2024 | - | 5,028 | 2,210 | ||
fuzz/ | 12-May-2024 | - | 3,767 | 3,127 | ||
include/ | 12-May-2024 | - | 50,022 | 36,140 | ||
ms/ | 12-May-2024 | - | 598 | 431 | ||
ohos_lite/ | 12-May-2024 | - | 44,973 | 31,570 | ||
open_harmony_openssl_config/ | 12-May-2024 | - | 37 | 26 | ||
os-dep/ | 12-May-2024 | - | 12 | 2 | ||
providers/ | 12-May-2024 | - | 59,551 | 45,268 | ||
ssl/ | 12-May-2024 | - | 59,685 | 44,076 | ||
test/ | 12-May-2024 | - | 386,523 | 327,920 | ||
tools/ | 12-May-2024 | - | 260 | 207 | ||
util/ | 12-May-2024 | - | 28,205 | 22,825 | ||
ACKNOWLEDGEMENTS.md | D | 12-May-2024 | 157 | 7 | 4 | |
AUTHORS.md | D | 12-May-2024 | 990 | 52 | 46 | |
BUILD.gn | D | 12-May-2024 | 64.8 KiB | 1,911 | 1,839 | |
CHANGES.md | D | 12-May-2024 | 728.9 KiB | 19,833 | 13,800 | |
CONTRIBUTING.md | D | 12-May-2024 | 4.3 KiB | 95 | 72 | |
COPYRIGHT.OpenSource | D | 12-May-2024 | 12.2 KiB | 187 | 186 | |
Configure | D | 12-May-2024 | 132.4 KiB | 3,595 | 2,842 | |
FAQ.md | D | 12-May-2024 | 197 | 7 | 4 | |
HACKING.md | D | 12-May-2024 | 1.2 KiB | 34 | 25 | |
INSTALL.md | D | 12-May-2024 | 61.5 KiB | 1,818 | 1,253 | |
LICENSE.txt | D | 12-May-2024 | 9.9 KiB | 178 | 150 | |
NEWS.md | D | 12-May-2024 | 71.8 KiB | 1,604 | 1,295 | |
NOTES-ANDROID.md | D | 12-May-2024 | 4.5 KiB | 91 | 72 | |
NOTES-DJGPP.md | D | 12-May-2024 | 2.1 KiB | 47 | 36 | |
NOTES-NONSTOP.md | D | 12-May-2024 | 10.6 KiB | 260 | 197 | |
NOTES-PERL.md | D | 12-May-2024 | 4.9 KiB | 128 | 95 | |
NOTES-UNIX.md | D | 12-May-2024 | 5.6 KiB | 116 | 93 | |
NOTES-VALGRIND.md | D | 12-May-2024 | 2.7 KiB | 73 | 52 | |
NOTES-VMS.md | D | 12-May-2024 | 4.7 KiB | 133 | 93 | |
NOTES-WINDOWS.md | D | 12-May-2024 | 9 KiB | 266 | 182 | |
OAT.xml | D | 12-May-2024 | 3.1 KiB | 42 | 27 | |
README-ENGINES.md | D | 12-May-2024 | 15.3 KiB | 317 | 264 | |
README-FIPS.md | D | 12-May-2024 | 3.8 KiB | 87 | 63 | |
README-PROVIDERS.md | D | 12-May-2024 | 5.3 KiB | 146 | 111 | |
README.OpenSource | D | 12-May-2024 | 453 | 11 | 11 | |
README.md | D | 12-May-2024 | 6.5 KiB | 225 | 161 | |
SUPPORT.md | D | 12-May-2024 | 3.8 KiB | 94 | 69 | |
VERSION.dat | D | 12-May-2024 | 100 | 8 | 7 | |
appveyor.yml | D | 12-May-2024 | 2 KiB | 83 | 75 | |
build.info | D | 12-May-2024 | 3.7 KiB | 93 | 84 | |
bundle.json | D | 12-May-2024 | 984 | 38 | 37 | |
config | D | 12-May-2024 | 378 | 11 | 2 | |
config.com | D | 12-May-2024 | 2.5 KiB | 94 | 90 | |
configdata.pm.in | D | 12-May-2024 | 16.3 KiB | 488 | 375 | |
e_os.h | D | 12-May-2024 | 12.8 KiB | 433 | 287 | |
empty.py | D | 12-May-2024 | 0 | 1 | 0 | |
make_openssl_build_all_generated.sh | D | 12-May-2024 | 2.5 KiB | 49 | 13 | |
run_command.py | D | 12-May-2024 | 1.1 KiB | 34 | 14 |
README-ENGINES.md
1 Engines 2 ======= 3 4 Deprecation Note 5 ---------------- 6 7 The ENGINE API was introduced in OpenSSL version 0.9.6 as a low level 8 interface for adding alternative implementations of cryptographic 9 primitives, most notably for integrating hardware crypto devices. 10 11 The ENGINE interface has its limitations and it has been superseeded 12 by the [PROVIDER API](README-PROVIDERS.md), it is deprecated in OpenSSL 13 version 3.0. The following documentation is retained as an aid for 14 users who need to maintain or support existing ENGINE implementations. 15 Support for new hardware devices or new algorithms should be added 16 via providers, and existing engines should be converted to providers 17 as soon as possible. 18 19 Built-in ENGINE implementations 20 ------------------------------- 21 22 There are currently built-in ENGINE implementations for the following 23 crypto devices: 24 25 * Microsoft CryptoAPI 26 * VIA Padlock 27 * nCipher CHIL 28 29 In addition, dynamic binding to external ENGINE implementations is now 30 provided by a special ENGINE called "dynamic". See the "DYNAMIC ENGINE" 31 section below for details. 32 33 At this stage, a number of things are still needed and are being worked on: 34 35 1. Integration of EVP support. 36 2. Configuration support. 37 3. Documentation! 38 39 Integration of EVP support 40 -------------------------- 41 42 With respect to EVP, this relates to support for ciphers and digests in 43 the ENGINE model so that alternative implementations of existing 44 algorithms/modes (or previously unimplemented ones) can be provided by 45 ENGINE implementations. 46 47 Configuration support 48 --------------------- 49 50 Configuration support currently exists in the ENGINE API itself, in the 51 form of "control commands". These allow an application to expose to the 52 user/admin the set of commands and parameter types a given ENGINE 53 implementation supports, and for an application to directly feed string 54 based input to those ENGINEs, in the form of name-value pairs. This is an 55 extensible way for ENGINEs to define their own "configuration" mechanisms 56 that are specific to a given ENGINE (eg. for a particular hardware 57 device) but that should be consistent across *all* OpenSSL-based 58 applications when they use that ENGINE. Work is in progress (or at least 59 in planning) for supporting these control commands from the CONF (or 60 NCONF) code so that applications using OpenSSL's existing configuration 61 file format can have ENGINE settings specified in much the same way. 62 Presently however, applications must use the ENGINE API itself to provide 63 such functionality. To see first hand the types of commands available 64 with the various compiled-in ENGINEs (see further down for dynamic 65 ENGINEs), use the "engine" openssl utility with full verbosity, i.e.: 66 67 openssl engine -vvvv 68 69 Documentation 70 ------------- 71 72 Documentation? Volunteers welcome! The source code is reasonably well 73 self-documenting, but some summaries and usage instructions are needed - 74 moreover, they are needed in the same POD format the existing OpenSSL 75 documentation is provided in. Any complete or incomplete contributions 76 would help make this happen. 77 78 STABILITY & BUG-REPORTS 79 ======================= 80 81 What already exists is fairly stable as far as it has been tested, but 82 the test base has been a bit small most of the time. For the most part, 83 the vendors of the devices these ENGINEs support have contributed to the 84 development and/or testing of the implementations, and *usually* (with no 85 guarantees) have experience in using the ENGINE support to drive their 86 devices from common OpenSSL-based applications. Bugs and/or inexplicable 87 behaviour in using a specific ENGINE implementation should be sent to the 88 author of that implementation (if it is mentioned in the corresponding C 89 file), and in the case of implementations for commercial hardware 90 devices, also through whatever vendor support channels are available. If 91 none of this is possible, or the problem seems to be something about the 92 ENGINE API itself (ie. not necessarily specific to a particular ENGINE 93 implementation) then you should mail complete details to the relevant 94 OpenSSL mailing list. For a definition of "complete details", refer to 95 the OpenSSL "README" file. As for which list to send it to: 96 97 * openssl-users: if you are *using* the ENGINE abstraction, either in an 98 pre-compiled application or in your own application code. 99 100 * openssl-dev: if you are discussing problems with OpenSSL source code. 101 102 USAGE 103 ===== 104 105 The default "openssl" ENGINE is always chosen when performing crypto 106 operations unless you specify otherwise. You must actively tell the 107 openssl utility commands to use anything else through a new command line 108 switch called "-engine". Also, if you want to use the ENGINE support in 109 your own code to do something similar, you must likewise explicitly 110 select the ENGINE implementation you want. 111 112 Depending on the type of hardware, system, and configuration, "settings" 113 may need to be applied to an ENGINE for it to function as expected/hoped. 114 The recommended way of doing this is for the application to support 115 ENGINE "control commands" so that each ENGINE implementation can provide 116 whatever configuration primitives it might require and the application 117 can allow the user/admin (and thus the hardware vendor's support desk 118 also) to provide any such input directly to the ENGINE implementation. 119 This way, applications do not need to know anything specific to any 120 device, they only need to provide the means to carry such user/admin 121 input through to the ENGINE in question. Ie. this connects *you* (and 122 your helpdesk) to the specific ENGINE implementation (and device), and 123 allows application authors to not get buried in hassle supporting 124 arbitrary devices they know (and care) nothing about. 125 126 A new "openssl" utility, "openssl engine", has been added in that allows 127 for testing and examination of ENGINE implementations. Basic usage 128 instructions are available by specifying the "-?" command line switch. 129 130 DYNAMIC ENGINES 131 =============== 132 133 The new "dynamic" ENGINE provides a low-overhead way to support ENGINE 134 implementations that aren't pre-compiled and linked into OpenSSL-based 135 applications. This could be because existing compiled-in implementations 136 have known problems and you wish to use a newer version with an existing 137 application. It could equally be because the application (or OpenSSL 138 library) you are using simply doesn't have support for the ENGINE you 139 wish to use, and the ENGINE provider (eg. hardware vendor) is providing 140 you with a self-contained implementation in the form of a shared-library. 141 The other use-case for "dynamic" is with applications that wish to 142 maintain the smallest foot-print possible and so do not link in various 143 ENGINE implementations from OpenSSL, but instead leaves you to provide 144 them, if you want them, in the form of "dynamic"-loadable 145 shared-libraries. It should be possible for hardware vendors to provide 146 their own shared-libraries to support arbitrary hardware to work with 147 applications based on OpenSSL 0.9.7 or later. If you're using an 148 application based on 0.9.7 (or later) and the support you desire is only 149 announced for versions later than the one you need, ask the vendor to 150 backport their ENGINE to the version you need. 151 152 How does "dynamic" work? 153 ------------------------ 154 155 The dynamic ENGINE has a special flag in its implementation such that 156 every time application code asks for the 'dynamic' ENGINE, it in fact 157 gets its own copy of it. As such, multi-threaded code (or code that 158 multiplexes multiple uses of 'dynamic' in a single application in any 159 way at all) does not get confused by 'dynamic' being used to do many 160 independent things. Other ENGINEs typically don't do this so there is 161 only ever 1 ENGINE structure of its type (and reference counts are used 162 to keep order). The dynamic ENGINE itself provides absolutely no 163 cryptographic functionality, and any attempt to "initialise" the ENGINE 164 automatically fails. All it does provide are a few "control commands" 165 that can be used to control how it will load an external ENGINE 166 implementation from a shared-library. To see these control commands, 167 use the command-line; 168 169 openssl engine -vvvv dynamic 170 171 The "SO_PATH" control command should be used to identify the 172 shared-library that contains the ENGINE implementation, and "NO_VCHECK" 173 might possibly be useful if there is a minor version conflict and you 174 (or a vendor helpdesk) is convinced you can safely ignore it. 175 "ID" is probably only needed if a shared-library implements 176 multiple ENGINEs, but if you know the engine id you expect to be using, 177 it doesn't hurt to specify it (and this provides a sanity check if 178 nothing else). "LIST_ADD" is only required if you actually wish the 179 loaded ENGINE to be discoverable by application code later on using the 180 ENGINE's "id". For most applications, this isn't necessary - but some 181 application authors may have nifty reasons for using it. The "LOAD" 182 command is the only one that takes no parameters and is the command 183 that uses the settings from any previous commands to actually *load* 184 the shared-library ENGINE implementation. If this command succeeds, the 185 (copy of the) 'dynamic' ENGINE will magically morph into the ENGINE 186 that has been loaded from the shared-library. As such, any control 187 commands supported by the loaded ENGINE could then be executed as per 188 normal. Eg. if ENGINE "foo" is implemented in the shared-library 189 "libfoo.so" and it supports some special control command "CMD_FOO", the 190 following code would load and use it (NB: obviously this code has no 191 error checking); 192 193 ENGINE *e = ENGINE_by_id("dynamic"); 194 ENGINE_ctrl_cmd_string(e, "SO_PATH", "/lib/libfoo.so", 0); 195 ENGINE_ctrl_cmd_string(e, "ID", "foo", 0); 196 ENGINE_ctrl_cmd_string(e, "LOAD", NULL, 0); 197 ENGINE_ctrl_cmd_string(e, "CMD_FOO", "some input data", 0); 198 199 For testing, the "openssl engine" utility can be useful for this sort 200 of thing. For example the above code excerpt would achieve much the 201 same result as; 202 203 openssl engine dynamic \ 204 -pre SO_PATH:/lib/libfoo.so \ 205 -pre ID:foo \ 206 -pre LOAD \ 207 -pre "CMD_FOO:some input data" 208 209 Or to simply see the list of commands supported by the "foo" ENGINE; 210 211 openssl engine -vvvv dynamic \ 212 -pre SO_PATH:/lib/libfoo.so \ 213 -pre ID:foo \ 214 -pre LOAD 215 216 Applications that support the ENGINE API and more specifically, the 217 "control commands" mechanism, will provide some way for you to pass 218 such commands through to ENGINEs. As such, you would select "dynamic" 219 as the ENGINE to use, and the parameters/commands you pass would 220 control the *actual* ENGINE used. Each command is actually a name-value 221 pair and the value can sometimes be omitted (eg. the "LOAD" command). 222 Whilst the syntax demonstrated in "openssl engine" uses a colon to 223 separate the command name from the value, applications may provide 224 their own syntax for making that separation (eg. a win32 registry 225 key-value pair may be used by some applications). The reason for the 226 "-pre" syntax in the "openssl engine" utility is that some commands 227 might be issued to an ENGINE *after* it has been initialised for use. 228 Eg. if an ENGINE implementation requires a smart-card to be inserted 229 during initialisation (or a PIN to be typed, or whatever), there may be 230 a control command you can issue afterwards to "forget" the smart-card 231 so that additional initialisation is no longer possible. In 232 applications such as web-servers, where potentially volatile code may 233 run on the same host system, this may provide some arguable security 234 value. In such a case, the command would be passed to the ENGINE after 235 it has been initialised for use, and so the "-post" switch would be 236 used instead. Applications may provide a different syntax for 237 supporting this distinction, and some may simply not provide it at all 238 ("-pre" is almost always what you're after, in reality). 239 240 How do I build a "dynamic" ENGINE? 241 ---------------------------------- 242 243 This question is trickier - currently OpenSSL bundles various ENGINE 244 implementations that are statically built in, and any application that 245 calls the "ENGINE_load_builtin_engines()" function will automatically 246 have all such ENGINEs available (and occupying memory). Applications 247 that don't call that function have no ENGINEs available like that and 248 would have to use "dynamic" to load any such ENGINE - but on the other 249 hand such applications would only have the memory footprint of any 250 ENGINEs explicitly loaded using user/admin provided control commands. 251 The main advantage of not statically linking ENGINEs and only using 252 "dynamic" for hardware support is that any installation using no 253 "external" ENGINE suffers no unnecessary memory footprint from unused 254 ENGINEs. Likewise, installations that do require an ENGINE incur the 255 overheads from only *that* ENGINE once it has been loaded. 256 257 Sounds good? Maybe, but currently building an ENGINE implementation as 258 a shared-library that can be loaded by "dynamic" isn't automated in 259 OpenSSL's build process. It can be done manually quite easily however. 260 Such a shared-library can either be built with any OpenSSL code it 261 needs statically linked in, or it can link dynamically against OpenSSL 262 if OpenSSL itself is built as a shared library. The instructions are 263 the same in each case, but in the former (statically linked any 264 dependencies on OpenSSL) you must ensure OpenSSL is built with 265 position-independent code ("PIC"). The default OpenSSL compilation may 266 already specify the relevant flags to do this, but you should consult 267 with your compiler documentation if you are in any doubt. 268 269 This example will show building the "atalla" ENGINE in the 270 crypto/engine/ directory as a shared-library for use via the "dynamic" 271 ENGINE. 272 273 1. "cd" to the crypto/engine/ directory of a pre-compiled OpenSSL 274 source tree. 275 276 2. Recompile at least one source file so you can see all the compiler 277 flags (and syntax) being used to build normally. Eg; 278 279 touch hw_atalla.c ; make 280 281 will rebuild "hw_atalla.o" using all such flags. 282 283 3. Manually enter the same compilation line to compile the 284 "hw_atalla.c" file but with the following two changes; 285 * add "-DENGINE_DYNAMIC_SUPPORT" to the command line switches, 286 * change the output file from "hw_atalla.o" to something new, 287 eg. "tmp_atalla.o" 288 289 4. Link "tmp_atalla.o" into a shared-library using the top-level 290 OpenSSL libraries to resolve any dependencies. The syntax for doing 291 this depends heavily on your system/compiler and is a nightmare 292 known well to anyone who has worked with shared-library portability 293 before. 'gcc' on Linux, for example, would use the following syntax; 294 295 gcc -shared -o dyn_atalla.so tmp_atalla.o -L../.. -lcrypto 296 297 5. Test your shared library using "openssl engine" as explained in the 298 previous section. Eg. from the top-level directory, you might try 299 300 apps/openssl engine -vvvv dynamic \ 301 -pre SO_PATH:./crypto/engine/dyn_atalla.so -pre LOAD 302 303 If the shared-library loads successfully, you will see both "-pre" 304 commands marked as "SUCCESS" and the list of control commands 305 displayed (because of "-vvvv") will be the control commands for the 306 *atalla* ENGINE (ie. *not* the 'dynamic' ENGINE). You can also add 307 the "-t" switch to the utility if you want it to try and initialise 308 the atalla ENGINE for use to test any possible hardware/driver issues. 309 310 PROBLEMS 311 ======== 312 313 It seems like the ENGINE part doesn't work too well with CryptoSwift on Win32. 314 A quick test done right before the release showed that trying "openssl speed 315 -engine cswift" generated errors. If the DSO gets enabled, an attempt is made 316 to write at memory address 0x00000002. 317
README-FIPS.md
1 OpenSSL FIPS support 2 ==================== 3 4 This release of OpenSSL includes a cryptographic module that can be 5 FIPS 140-2 validated. The module is implemented as an OpenSSL provider. 6 A provider is essentially a dynamically loadable module which implements 7 cryptographic algorithms, see the [README-PROVIDERS](README-PROVIDERS.md) file 8 for further details. 9 10 A cryptographic module is only FIPS validated after it has gone through the complex 11 FIPS 140 validation process. As this process takes a very long time, it is not 12 possible to validate every minor release of OpenSSL. 13 If you need a FIPS validated module then you must ONLY generate a FIPS provider 14 using OpenSSL versions that have valid FIPS certificates. A FIPS certificate 15 contains a link to a Security Policy, and you MUST follow the instructions 16 in the Security Policy in order to be FIPS compliant. 17 See <https://www.openssl.org/source/> for information related to OpenSSL 18 FIPS certificates and Security Policies. 19 20 Newer OpenSSL Releases that include security or bug fixes can be used to build 21 all other components (such as the core API's, TLS and the default, base and 22 legacy providers) without any restrictions, but the FIPS provider must be built 23 as specified in the Security Policy (normally with a different version of the 24 source code). 25 26 The OpenSSL FIPS provider is a shared library called `fips.so` (on Unix), or 27 resp. `fips.dll` (on Windows). The FIPS provider does not get built and 28 installed automatically. To enable it, you need to configure OpenSSL using 29 the `enable-fips` option. 30 31 Installing the FIPS module 32 ========================== 33 34 The following is only a guide. 35 Please read the Security Policy for up to date installation instructions. 36 37 If the FIPS provider is enabled, it gets installed automatically during the 38 normal installation process. Simply follow the normal procedure (configure, 39 make, make test, make install) as described in the [INSTALL](INSTALL.md) file. 40 41 For example, on Unix the final command 42 43 $ make install 44 45 effectively executes the following install targets 46 47 $ make install_sw 48 $ make install_ssldirs 49 $ make install_docs 50 $ make install_fips # for `enable-fips` only 51 52 The `install_fips` make target can also be invoked explicitly to install 53 the FIPS provider independently, without installing the rest of OpenSSL. 54 55 The Installation of the FIPS provider consists of two steps. In the first step, 56 the shared library is copied to its installed location, which by default is 57 58 /usr/local/lib/ossl-modules/fips.so on Unix, and 59 C:\Program Files\OpenSSL\lib\ossl-modules\fips.dll on Windows. 60 61 In the second step, the `openssl fipsinstall` command is executed, which completes 62 the installation by doing the following two things: 63 64 - Runs the FIPS module self tests 65 - Generates the so-called FIPS module configuration file containing information 66 about the module such as the self test status, and the module checksum. 67 68 The FIPS module must have the self tests run, and the FIPS module config file 69 output generated on every machine that it is to be used on. You must not copy 70 the FIPS module config file output data from one machine to another. 71 72 On Unix the `openssl fipsinstall` command will be invoked as follows by default: 73 74 $ openssl fipsinstall -out /usr/local/ssl/fipsmodule.cnf -module /usr/local/lib/ossl-modules/fips.so 75 76 If you configured OpenSSL to be installed to a different location, the paths will 77 vary accordingly. In the rare case that you need to install the fipsmodule.cnf 78 to non-standard location, you can execute the `openssl fipsinstall` command manually. 79 80 Using the FIPS Module in applications 81 ===================================== 82 83 Documentation about using the FIPS module is available on the [fips_module(7)] 84 manual page. 85 86 [fips_module(7)]: https://www.openssl.org/docs/man3.0/man7/fips_module.html 87
README-PROVIDERS.md
1 Providers 2 ========= 3 4 - [Standard Providers](#standard-providers) 5 - [The Default Provider](#the-default-provider) 6 - [The Legacy Provider](#the-legacy-provider) 7 - [The FIPS Provider](#the-fips-provider) 8 - [The Base Provider](#the-base-provider) 9 - [The Null Provider](#the-null-provider) 10 - [Loading Providers](#loading-providers) 11 12 Standard Providers 13 ================== 14 15 Providers are containers for algorithm implementations. Whenever a cryptographic 16 algorithm is used via the high level APIs a provider is selected. It is that 17 provider implementation that actually does the required work. There are five 18 providers distributed with OpenSSL. In the future we expect third parties to 19 distribute their own providers which can be added to OpenSSL dynamically. 20 Documentation about writing providers is available on the [provider(7)] 21 manual page. 22 23 [provider(7)]: https://www.openssl.org/docs/man3.0/man7/provider.html 24 25 The Default Provider 26 -------------------- 27 28 The default provider collects together all of the standard built-in OpenSSL 29 algorithm implementations. If an application doesn't specify anything else 30 explicitly (e.g. in the application or via config), then this is the provider 31 that will be used. It is loaded automatically the first time that we try to 32 get an algorithm from a provider if no other provider has been loaded yet. 33 If another provider has already been loaded then it won't be loaded 34 automatically. Therefore if you want to use it in conjunction with other 35 providers then you must load it explicitly. 36 37 This is a "built-in" provider which means that it is compiled and linked 38 into the libcrypto library and does not exist as a separate standalone module. 39 40 The Legacy Provider 41 ------------------- 42 43 The legacy provider is a collection of legacy algorithms that are either no 44 longer in common use or considered insecure and strongly discouraged from use. 45 However, some applications may need to use these algorithms for backwards 46 compatibility reasons. This provider is **not** loaded by default. 47 This may mean that some applications upgrading from earlier versions of OpenSSL 48 may find that some algorithms are no longer available unless they load the 49 legacy provider explicitly. 50 51 Algorithms in the legacy provider include MD2, MD4, MDC2, RMD160, CAST5, 52 BF (Blowfish), IDEA, SEED, RC2, RC4, RC5 and DES (but not 3DES). 53 54 The FIPS Provider 55 ----------------- 56 57 The FIPS provider contains a sub-set of the algorithm implementations available 58 from the default provider, consisting of algorithms conforming to FIPS standards. 59 It is intended that this provider will be FIPS140-2 validated. 60 61 In some cases there may be minor behavioural differences between algorithm 62 implementations in this provider compared to the equivalent algorithm in the 63 default provider. This is typically in order to conform to FIPS standards. 64 65 The Base Provider 66 ----------------- 67 68 The base provider contains a small sub-set of non-cryptographic algorithms 69 available in the default provider. For example, it contains algorithms to 70 serialize and deserialize keys to files. If you do not load the default 71 provider then you should always load this one instead (in particular, if 72 you are using the FIPS provider). 73 74 The Null Provider 75 ----------------- 76 77 The null provider is "built-in" to libcrypto and contains no algorithm 78 implementations. In order to guarantee that the default provider is not 79 automatically loaded, the null provider can be loaded instead. 80 81 This can be useful if you are using non-default library contexts and want 82 to ensure that the default library context is never used unintentionally. 83 84 Loading Providers 85 ================= 86 87 Providers to be loaded can be specified in the OpenSSL config file. 88 See the [config(5)] manual page for information about how to configure 89 providers via the config file, and how to automatically activate them. 90 91 [config(5)]: https://www.openssl.org/docs/man3.0/man5/config.html 92 93 The following is a minimal config file example to load and activate both 94 the legacy and the default provider in the default library context. 95 96 openssl_conf = openssl_init 97 98 [openssl_init] 99 providers = provider_sect 100 101 [provider_sect] 102 default = default_sect 103 legacy = legacy_sect 104 105 [default_sect] 106 activate = 1 107 108 [legacy_sect] 109 activate = 1 110 111 It is also possible to load providers programmatically. For example you can 112 load the legacy provider into the default library context as shown below. 113 Note that once you have explicitly loaded a provider into the library context 114 the default provider will no longer be automatically loaded. Therefore you will 115 often also want to explicitly load the default provider, as is done here: 116 117 #include <stdio.h> 118 #include <stdlib.h> 119 120 #include <openssl/provider.h> 121 122 int main(void) 123 { 124 OSSL_PROVIDER *legacy; 125 OSSL_PROVIDER *deflt; 126 127 /* Load Multiple providers into the default (NULL) library context */ 128 legacy = OSSL_PROVIDER_load(NULL, "legacy"); 129 if (legacy == NULL) { 130 printf("Failed to load Legacy provider\n"); 131 exit(EXIT_FAILURE); 132 } 133 deflt = OSSL_PROVIDER_load(NULL, "default"); 134 if (deflt == NULL) { 135 printf("Failed to load Default provider\n"); 136 OSSL_PROVIDER_unload(legacy); 137 exit(EXIT_FAILURE); 138 } 139 140 /* Rest of application */ 141 142 OSSL_PROVIDER_unload(legacy); 143 OSSL_PROVIDER_unload(deflt); 144 exit(EXIT_SUCCESS); 145 } 146
README.OpenSource
1 [ 2 { 3 "Name": "OpenSSL", 4 "License": "Apache License 2.0", 5 "License File": "LICENSE.txt", 6 "Version Number": "3.0.9", 7 "Owner": "wanghaixiang@huawei.com", 8 "Upstream URL": "https://www.openssl.org/source/openssl-3.0.9.tar.gz", 9 "Description": "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." 10 } 11 ]
README.md
1 Welcome to the OpenSSL Project 2 ============================== 3 4 [![openssl logo]][www.openssl.org] 5 6 [![github actions ci badge]][github actions ci] 7 [![appveyor badge]][appveyor jobs] 8 9 OpenSSL is a robust, commercial-grade, full-featured Open Source Toolkit 10 for the Transport Layer Security (TLS) protocol formerly known as the 11 Secure Sockets Layer (SSL) protocol. The protocol implementation is based 12 on a full-strength general purpose cryptographic library, which can also 13 be used stand-alone. 14 15 OpenSSL is descended from the SSLeay library developed by Eric A. Young 16 and Tim J. Hudson. 17 18 The official Home Page of the OpenSSL Project is [www.openssl.org]. 19 20 Table of Contents 21 ================= 22 23 - [Overview](#overview) 24 - [Download](#download) 25 - [Build and Install](#build-and-install) 26 - [Documentation](#documentation) 27 - [License](#license) 28 - [Support](#support) 29 - [Contributing](#contributing) 30 - [Legalities](#legalities) 31 32 Overview 33 ======== 34 35 The OpenSSL toolkit includes: 36 37 - **libssl** 38 an implementation of all TLS protocol versions up to TLSv1.3 ([RFC 8446]). 39 40 - **libcrypto** 41 a full-strength general purpose cryptographic library. It constitutes the 42 basis of the TLS implementation, but can also be used independently. 43 44 - **openssl** 45 the OpenSSL command line tool, a swiss army knife for cryptographic tasks, 46 testing and analyzing. It can be used for 47 - creation of key parameters 48 - creation of X.509 certificates, CSRs and CRLs 49 - calculation of message digests 50 - encryption and decryption 51 - SSL/TLS client and server tests 52 - handling of S/MIME signed or encrypted mail 53 - and more... 54 55 Download 56 ======== 57 58 For Production Use 59 ------------------ 60 61 Source code tarballs of the official releases can be downloaded from 62 [www.openssl.org/source](https://www.openssl.org/source). 63 The OpenSSL project does not distribute the toolkit in binary form. 64 65 However, for a large variety of operating systems precompiled versions 66 of the OpenSSL toolkit are available. In particular on Linux and other 67 Unix operating systems it is normally recommended to link against the 68 precompiled shared libraries provided by the distributor or vendor. 69 70 For Testing and Development 71 --------------------------- 72 73 Although testing and development could in theory also be done using 74 the source tarballs, having a local copy of the git repository with 75 the entire project history gives you much more insight into the 76 code base. 77 78 The official OpenSSL Git Repository is located at [git.openssl.org]. 79 There is a GitHub mirror of the repository at [github.com/openssl/openssl], 80 which is updated automatically from the former on every commit. 81 82 A local copy of the Git Repository can be obtained by cloning it from 83 the original OpenSSL repository using 84 85 git clone git://git.openssl.org/openssl.git 86 87 or from the GitHub mirror using 88 89 git clone https://github.com/openssl/openssl.git 90 91 If you intend to contribute to OpenSSL, either to fix bugs or contribute 92 new features, you need to fork the OpenSSL repository openssl/openssl on 93 GitHub and clone your public fork instead. 94 95 git clone https://github.com/yourname/openssl.git 96 97 This is necessary, because all development of OpenSSL nowadays is done via 98 GitHub pull requests. For more details, see [Contributing](#contributing). 99 100 Build and Install 101 ================= 102 103 After obtaining the Source, have a look at the [INSTALL](INSTALL.md) file for 104 detailed instructions about building and installing OpenSSL. For some 105 platforms, the installation instructions are amended by a platform specific 106 document. 107 108 * [Notes for UNIX-like platforms](NOTES-UNIX.md) 109 * [Notes for Android platforms](NOTES-ANDROID.md) 110 * [Notes for Windows platforms](NOTES-WINDOWS.md) 111 * [Notes for the DOS platform with DJGPP](NOTES-DJGPP.md) 112 * [Notes for the OpenVMS platform](NOTES-VMS.md) 113 * [Notes on Perl](NOTES-PERL.md) 114 * [Notes on Valgrind](NOTES-VALGRIND.md) 115 116 Specific notes on upgrading to OpenSSL 3.0 from previous versions can be found 117 in the [migration_guide(7ossl)] manual page. 118 119 Documentation 120 ============= 121 122 Manual Pages 123 ------------ 124 125 The manual pages for the master branch and all current stable releases are 126 available online. 127 128 - [OpenSSL master](https://www.openssl.org/docs/manmaster) 129 - [OpenSSL 3.0](https://www.openssl.org/docs/man3.0) 130 - [OpenSSL 1.1.1](https://www.openssl.org/docs/man1.1.1) 131 132 Wiki 133 ---- 134 135 There is a Wiki at [wiki.openssl.org] which is currently not very active. 136 It contains a lot of useful information, not all of which is up to date. 137 138 License 139 ======= 140 141 OpenSSL is licensed under the Apache License 2.0, which means that 142 you are free to get and use it for commercial and non-commercial 143 purposes as long as you fulfill its conditions. 144 145 See the [LICENSE.txt](LICENSE.txt) file for more details. 146 147 Support 148 ======= 149 150 There are various ways to get in touch. The correct channel depends on 151 your requirement. see the [SUPPORT](SUPPORT.md) file for more details. 152 153 Contributing 154 ============ 155 156 If you are interested and willing to contribute to the OpenSSL project, 157 please take a look at the [CONTRIBUTING](CONTRIBUTING.md) file. 158 159 Legalities 160 ========== 161 162 A number of nations restrict the use or export of cryptography. If you are 163 potentially subject to such restrictions you should seek legal advice before 164 attempting to develop or distribute cryptographic code. 165 166 Copyright 167 ========= 168 169 Copyright (c) 1998-2022 The OpenSSL Project 170 171 Copyright (c) 1995-1998 Eric A. Young, Tim J. Hudson 172 173 All rights reserved. 174 175 <!-- Links --> 176 177 [www.openssl.org]: 178 <https://www.openssl.org> 179 "OpenSSL Homepage" 180 181 [git.openssl.org]: 182 <https://git.openssl.org> 183 "OpenSSL Git Repository" 184 185 [git.openssl.org]: 186 <https://git.openssl.org> 187 "OpenSSL Git Repository" 188 189 [github.com/openssl/openssl]: 190 <https://github.com/openssl/openssl> 191 "OpenSSL GitHub Mirror" 192 193 [wiki.openssl.org]: 194 <https://wiki.openssl.org> 195 "OpenSSL Wiki" 196 197 [migration_guide(7ossl)]: 198 <https://www.openssl.org/docs/man3.0/man7/migration_guide.html> 199 "OpenSSL Migration Guide" 200 201 [RFC 8446]: 202 <https://tools.ietf.org/html/rfc8446> 203 204 <!-- Logos and Badges --> 205 206 [openssl logo]: 207 doc/images/openssl.svg 208 "OpenSSL Logo" 209 210 [github actions ci badge]: 211 <https://github.com/openssl/openssl/workflows/GitHub%20CI/badge.svg> 212 "GitHub Actions CI Status" 213 214 [github actions ci]: 215 <https://github.com/openssl/openssl/actions?query=workflow%3A%22GitHub+CI%22> 216 "GitHub Actions CI" 217 218 [appveyor badge]: 219 <https://ci.appveyor.com/api/projects/status/8e10o7xfrg73v98f/branch/master?svg=true> 220 "AppVeyor Build Status" 221 222 [appveyor jobs]: 223 <https://ci.appveyor.com/project/openssl/openssl/branch/master> 224 "AppVeyor Jobs" 225