summaryrefslogtreecommitdiff
path: root/src/lib/libcrypto (follow)
Commit message (Collapse)AuthorAgeFilesLines
* 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.
* Whitespace fixes.jsing2023-03-291-68/+68
| | | | | | | Mechanically replace "a,b" with "a, b", followed with some manual indentation clean up. No change in generated assembly.
* Use multiple statements instead of a statement with multiple expressions.jsing2023-03-291-4/+5
| | | | No change in generated assembly.
* Mop up MD32_XARRAY from SHA1.jsing2023-03-291-162/+135
| | | | | | | | | MD32_XARRAY (formerly SHA_XARRAY) was added as a workaround for a broken HP C compiler (circa 1999). Clean it up to simplify the code. No change in generated assembly. ok miod@ tb@
* Inline initial hash data values for SHA1.jsing2023-03-291-13/+9
| | | | | | This follows what is done for other SHA implementations. ok miod@ tb@
* Reorder functions/code.jsing2023-03-271-238/+238
| | | | No intended functional change.
* Replace the remaining BN_copy() with bn_copy()tb2023-03-2719-116/+116
| | | | ok jsing
* Convert BN_copy() with missing error checks to bn_copy()tb2023-03-274-11/+18
| | | | ok jsing
* Convert BN_copy() with explicit comparison against NULL to bn_copy()tb2023-03-277-25/+25
| | | | ok jsing
* Use bn_copy() rather than inlining ittb2023-03-271-2/+2
| | | | ok jsing
* Tidy includes.jsing2023-03-271-5/+4
|
* Avoid errno is EINVAL after OpenSSL initializationjan2023-03-271-1/+5
| | | | ok tb@
* Drop unnecessary parentheses.tb2023-03-271-3/+3
| | | | ok jsing
* Convert bn_nist.c to BN_copy()tb2023-03-271-6/+6
| | | | | | | Like everything else in this file, the use of BN_copy() needs to be ... special. Simplify using the new bn_copy(). ok jsing
* Add bn_copy(), a sane wrapper of BN_copy() for internal usetb2023-03-272-2/+10
| | | | ok jsing
* Replace HASH_BLOCK_DATA_ORDER with sha1_block_data_order.jsing2023-03-261-4/+4
| | | | | The only reason to use HASH_BLOCK_DATA_ORDER in the implementation is to make the code harder to read.
* Remove unnecessary HIDDEN_DECLS.jsing2023-03-261-6/+1
|
* Removes some unwanted spaces.jsing2023-03-261-7/+7
|
* Whack sha1dgst.c with the style(9) stick again.jsing2023-03-261-193/+246
|
* Minor whitespace tidyingtb2023-03-262-6/+7
|
* Tidy up includes.jsing2023-03-261-9/+5
|
* Inline sha_local.h in sha1dgst.c.jsing2023-03-261-3/+360
| | | | | Nothing other than sha1dst.c uses this header - pull it in to sha1dgst.c directly (sha_local.h will be removed at a later date).
* Make several calls to BN_nnmod() unconditionaltb2023-03-261-19/+10
| | | | | | | | This removes a potential branch in a sensitive function and makes the code a lot simpler. It is a really bad idea optimize here for what davidben aptly calls "calculator" purposes. ok jsing
* Correctly reduce negative inpot to BN_mod_exp2_mont()tb2023-03-261-3/+3
| | | | | | | | | | Negative bases could result in a negative modulus being returned. This is not strictly speaking incorrect but slightly surprising. This is all a consequence of the shortcut of defining BN_mod() as a macro using BN_div(). Fixes ossfuzz #55997 ok jsing
* Add license to sha256.c/sha512.c.jsing2023-03-262-6/+100
|
* Use multiple statements instead of comma separated expressions.jsing2023-03-261-24/+33
| | | | No change to generated assembly.
* Add blank lines for readability.jsing2023-03-261-1/+4
|
* Add some blank lines for readability, along with some more style(9) tweaks.jsing2023-03-262-7/+24
|
* Whack sha with a style(9) stick.jsing2023-03-264-505/+706
| | | | No change in generated assembly.
* bn_prime.pl: fix shebang and a couple more whitespace tweakstb2023-03-261-3/+4
|
* Use strict and warningstb2023-03-251-1/+6
|
* Make an attempt at reducing the eyebleed in bn_prime.pltb2023-03-251-24/+18
| | | | | Use a style more resembling KNF and drop lots of parentheses. Simplify a few things. No change in generated output on success.
* Use Eric Young's usual license in the proper place rather than a weirdtb2023-03-251-12/+57
| | | | commented-out license stub in a HERE document.
* Add RCSIDtb2023-03-251-1/+1
|
* Add checks to ensure the uint16_t array isn't overflowed when thistb2023-03-251-0/+4
| | | | | script is run. This is more of an issue with uint16_t now than it was with prime_t aka BN_ULONG before r1.6.
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-08-04 11:19:33 +0000