summaryrefslogtreecommitdiff
path: root/src/lib/libcrypto (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Move DH_generate_parameters() from dh_depr.c to dh_gen.ctb2023-04-132-20/+21
| | | | discussed with jsing
* ec_lib.c: fix a few NULL misspellingstb2023-04-131-6/+6
|
* Fix various early return issues spotted by coveritytb2023-04-131-13/+13
| | | | | | | A large mechanical diff led to sloppy review and gave coverity an opportunity to be right for once. First time in a good many weeks. same diff/ok jsing
* remove duplicate linesjsg2023-04-121-3/+2
|
* Remove now unused sha_local.h.jsing2023-04-121-419/+0
|
* Provide and use crypto_ro{l,r}_u{32,64}().jsing2023-04-123-25/+39
| | | | | | | | | | | | | | | Various code in libcrypto needs bitwise rotation - rather than defining different versions across the code base, provide a common set that can be reused. Any sensible compiler optimises these to a single instruction where the architecture supports it, which means we can ditch the inline assembly. On the chance that we need to provide a platform specific versions, this follows the approach used in BN where a MD crypto_arch.h header could be added in the future, which would then provide more specific versions of these functions. ok tb@
* Provide and use crypto_store_htobe64().jsing2023-04-122-23/+43
| | | | | | | | | It is common to need to store data in a specific endianness - rather than handrolling and deduplicating code to do this, provide a crypto_store_htobe64() function that converts from host endian to big endian, before storing the data to a location with unknown alignment. ok tb@
* Handle BN_CTX at the EC API boundary.jsing2023-04-1111-491/+553
| | | | | | | | | | | The EC API allows callers to optionally pass in a BN_CTX, which means that any code needing a BN_CTX has to check if one was provided, allocate one if not, then free it again. Rather than doing this dance throughout the EC code, handle the BN_CTX existance at the EC API boundary. This means that lower level implementation code can simply assume that the BN_CTX is available. ok tb@
* Clean up unused BIGNUM.jsing2023-04-111-4/+1
|
* Document the RETURN VALUES of BIO_method_type(3) and BIO_method_name(3)schwarze2023-04-1113-26/+149
| | | | for the various BIO types.
* Recommit jsing's r1.27 - portable is readytb2023-04-111-23/+4
| | | | | | Use htobe64() instead of testing BYTE_ORDER and then handrolling htobe64(). Thanks to tobhe for providing most of the fix via openiked-portable
* While all the BIO_TYPE_* constants are part of the API, most of theirschwarze2023-04-111-32/+77
| | | | | | | | | | | | | values are only part of the ABI and not of the API, so delete them from the SYNOPSIS: application programmers must not rely on the specific values. Instead of listing the specific values, properly describe the meaning of all these constants. However, the values of BIO_TYPE_NONE and BIO_TYPE_START are hard-coded into the API and application programmers need to be aware of their values, so those remain in the SYNOPSIS.
* Back out r1.27 using htobe64() - apparently some OS don't have it.tb2023-04-111-4/+23
| | | | ok jsing
* Consolidate sha1 into a single file.jsing2023-04-113-91/+23
|
* Simplify handling of big vs little endian.jsing2023-04-111-40/+5
| | | | | | | Rather than sprinkling BYTE_ORDER checks throughout the implementation, always define PULL64 - on big endian platforms it just becomes a no-op. ok tb@
* Use htobe64() instead of testing BYTE_ORDER and then handrolling htobe64().jsing2023-04-111-23/+4
| | | | ok tb@
* Omit sha512_block_data_order() prototype when assembly is not being used.jsing2023-04-111-4/+3
| | | | | | | | | In the case that the pure C implementation of SHA512 is being used, the prototype is unnecessary as the function is declared static and exists in dependency order. Simply omit the prototype rather than using #ifndef to toggle the static prefix. ok tb@
* Remove less than useful implementation notes.jsing2023-04-111-36/+1
| | | | ok tb@
* Add a new implementation of BN_mod_sqrt()tb2023-04-113-411/+728
| | | | | | | | | | | | | | | | | | | This is a reimplementation from scratch of the Tonelli-Shanks algorithm based on Henri Cohen "A Course in Computational Algebraic Number Theory", Springer GTM 138, section 1.5.1. It is API compatible with the previous implementation, so no documentation change is required. Contrary to the old implementation, this does not have any infinite loops and has various additional sanity checks to prevent misbehavior in case the input modulus is not a prime. It contains extensive comments and the individual parts of the algorithm are split into digestible chunks instead of having one huge function. One difference of note is that it BN_mod_sqrt() now always returns the smaller of the two possible answers. In other words, while its core is non-deterministic, its answer is not. ok jsing
* Fix indentation of structs and unions in x509v3.htb2023-04-101-87/+87
| | | | No change according to diff -w
* Make bn_to_string() statictb2023-04-101-3/+3
| | | | | This function is no longer used directly by regress, so it can now be local to this file.
* Move a few functions out of OPENSSL_NO_DEPRECATEDtb2023-04-098-29/+19
| | | | | | | | | | | | | | | | | | | | | | | | Geoff Thorpe added OPENSSL_NO_DEPRECATED nearly two decades ago. The hope was that at some point some functions can be dropped. Most of the functions marked deprecated are actually unused nowadays but unfortunately some of them are still used in the ecosystem. Move them out of OPENSSL_NO_DEPRECATED so we can define it without breaking the consumers in the next bump. ERR_remove_state() is still used by a dozen or so ports. This isn't a big deal since it is just a stupid wrapper for the not quite as deprecated ERR_remove_thread_state(). It's not worth patching these ports. Annoyingly, {DH,DSA}_generate_parameters() and RSA_generate_key() are still used. They "make use" of the old-style BN_GENCB callback, which is therefore more difficult to remove - in case you don't know know: that's the thing responsible for printing pretty '.', '+' and '*' when you generate keys. Most annoyingly, DH_generate_parameters() was added to rust-openssl in 2020 for "advanced DH support". This is very unfortunate since cargo bundles a rust-openssl and updates it only every few years or so. As a consequence we're going to be stuck with this nonsense for a good while. ok beck jsing
* Remove some doubled empty linestb2023-04-091-7/+1
|
* Provide and use sha{224,384}_{update,final} functions.jsing2023-04-091-28/+54
| | | | | | | | | | Improve readability and consistency by providing and using functions named for the specific hash, rather than reusing the sha256/sha512 update and final functions. No functional change. ok tb@
* Rename SHA functions to have sha{1,224,256,384,512}_ prefix.jsing2023-04-091-31/+31
| | | | | | | | Also remove some unnecessary parentheses. No functional change. ok tb@
* fix double wordsjsg2023-04-091-3/+3
|
* bn_mont: fix typo in comment divisable -> divisibletb2023-04-071-2/+2
|
* Mark BIO_CB_return(), BIO_cb_pre(), and BIO_cb_post() as intentionallyschwarze2023-04-071-2/+7
| | | | | undocumented because they are unused according to codesearch.debian.net and would cause nothing but obfuscation if they were used.
* Document the effects that BIO_set_info_callback(3), BIO_callback_ctrl(3),schwarze2023-04-061-3/+54
| | | | BIO_get_info_callback(3), and BIO_info_cb(3) have on connect BIOs.
* Properly document BIO_set_info_callback(3) and BIO_get_info_callback(3)schwarze2023-04-061-8/+96
| | | | | | | | which where mentioned below SYNOPSIS and HISTORY but not described. Also document the command constant BIO_CTRL_SET_CALLBACK and the deprecated function type name bio_info_cb(3). Mention that callbacks installed using BIO_set_callback_ex(3) and BIO_set_callback(3) can tamper with *all* the return values.
* Use RCS tag instead of an incorrect path.tb2023-04-061-1/+1
|
* Add a few missing bracestb2023-04-051-4/+7
| | | | ok jsing
* Set up the RSA's _method_mod_n before the initial blindingtb2023-04-051-11/+13
| | | | | | | | | | | | | | | | As observed by Bernd Edlinger, the main part of the RSA timing leak that was recently made public is that the initial blinding isn't done with Montgomery exponentiation but rather with plain exponentiation. Pull up the initialization of the cached Montgomery context to ensure we use Montgomery exponentiation. Do this for private_{de,en}crypt(). Interestingly, the latter was fixed in OpenSSL a while ago by Andy Polyakov as part of the "smooth CRT-RSA" addition. If this code was anything but completely insane this would never have been an issue in the first place. But it's libcrypto... ok jsing
* Sprinkle a few BTI instructions into the arm64 assembly files and passkettenis2023-04-052-1/+8
| | | | | | -mmark-bti-property to indicate those now have BTI support. ok jsing@, deraadt@
* A refactoring back in 2016 in which magic numbers where extracted intoanton2023-04-041-0/+1
| | | | | | | named constants accidentally dropped an instruction causing detection of eXtended operations (XOP) on AMD hardware to break. ok miod@ tb@
* In preparation for better documenting BIO info callbacks, improve theschwarze2023-04-041-9/+115
| | | | | | | | | description of BIO_ctrl(3) and its three siblings. Given the vast range of effects these functions can have, the text is unavoidably still vague, but at least some information can be provided. While here, fix one wrong parameter type and three inconsistent parameter names in the SYNOPSIS.
* Compress euclid() a littletb2023-04-031-49/+28
| | | | | | | | | | This function is spread out over way too many lines and has too much repetition. Once this is made a little more compact, it becomes clearer that this is a somewhat obfuscated version of binary gcd (it is not constant time therefore cryptographically unsound. It is not used internally). This will likely go away later. ok jsing
* Fix table by using strings of proper lengths instead of bogustb2023-04-021-3/+3
| | | | | | scaling widths. ok schwarze
* Revert r1.9 and reinstate r1.6tb2023-04-021-2/+2
| | | | | | The argument change to x5519_ge_scalarmult_base() was made to match the prototype in the header. More recent compilers warn about such ptr vs array mismatches.
* Pull static const data out of BN_value_one()tb2023-04-011-7/+11
| | | | | | Also use C99 initializers for readability. discussed with jsing
* Indent labelstb2023-04-011-6/+6
|
* Group the non-constant time gcd functions togethertb2023-04-011-45/+45
| | | | | | | | The only consumer of euclid() is BN_gcd(), which, in turn is only used by BN_gcd_nonct(). Group them together rather than having parts of the constant time implementation separate them. This moves two functions to a different place in the file.
* Copy BN_FLG flags in BN_copy()tb2023-03-311-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BN_copy() forgot to copy the flags from the source to the target. Fix this by copying the flags. In fact, only copy BN_FLG_CONSTTIME since propagating BN_FLG_MALLOCED and BN_FLG_STATIC_DATA is wrong. Ignore the BN_FLG_FREE flag "used for debugging" which of course means "unused" like a lot of other debug code that somehow ended up in public headers. Also: make BN_FLG_CONSTTIME sticky on the target, i.e., don't clear the flag when copying from a non-constant time BIGNUM to a constant time one for the following reason: if a is constant time, BN_sqr(a, a, ctx) would use a BIGNUM without the flag internally, then copy the result to a in which process a would lose its constant time flag. Fixing this would be a lot of pointless work since someone had the good sense of not relying on a fragile flag for something this important. Rather, libcrypto always uses the constant time paths instead of the faster, cryptographically inadequate paths. Before this was changed, this was a pretty bad bug. The RSA code uses the horrible BN_with_flags() function to create local versions of the private moduli and set BN_FLG_CONSTTIME on them. If the RSA_FLAG_CACHE_PRIVATE for caching moduli is set on the RSA, which it is by default, it attempts to set these constant time versions on the RSA's internal Montgomery contexts. Since it is called BN_MONT_CTX_set(), the setter doesn't set a BIGNUM on the BN_MONT_CTX, rather it copies it over, losing the BN_FLG_CONSTTIME flag in the process and make all the horrible leaky RSA code leak some more. Good job. This is all harmless and is mostly a cosmetic fix. BN_FLG_CONSTTIME should be removed internally. It will be kept since various language bindings of course picked it up and expose it. ok beck jsing
* Inline only use of TS_VERIFY_CTX_init()tb2023-03-311-2/+2
| | | | | | | | Since TS_VERIFY_CTX is now opaque, the only thing TS_VERIFY_CTX_init() is good for outside the library is memory leaks. Inside the library it's also useless, since as a much more familiar name is memset(). It will soon be able to join all the other nonsense that should never have leaked out of this library.
* i2d_ECDSA_SIG() may return a negative value in case of error. Handlebluhm2023-03-301-5/+14
| | | | | this in ossl_ecdsa_sign() and propagate the return code. OK jsing@ tb@
* Call bn_copy() unconditionally in BN_mul() and BN_sqr()tb2023-03-302-11/+6
| | | | | | | bn_copy() does the right thing if source and target are the same, so there is no need for an additional check. Requested by jsing
* bio_ndef: add an empty line before returntb2023-03-301-1/+2
|
* Rework BN_exp() a bittb2023-03-301-27/+28
| | | | | | | | | This mostly only cleans up the mess that it was - which doesn't stand out because of the horror that lurks in the rest of this file. It avoids copying the partial calculation out on error and does away with some other weirdness. with/ok jsing
* More whitespace fixes.jsing2023-03-291-51/+51
| | | | | | Another set of mechnical replacements for "a,b" with "a, b". No change in generated assembly.
* Whitespace fixes.jsing2023-03-291-133/+133
| | | | | | Mechanically replace "a,b" with "a, b". No change to generated assembly.