| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
BIO_get_info_callback(3), and BIO_info_cb(3) have on connect BIOs.
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
ok jsing
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
-mmark-bti-property to indicate those now have BTI support.
ok jsing@, deraadt@
|
| |
|
|
|
|
|
|
|
| |
named constants accidentally dropped an instruction causing detection of
eXtended operations (XOP) on AMD hardware to break.
ok miod@ tb@
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
scaling widths.
ok schwarze
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Should catch more of them and closer (in time) to the WAF. ok tb@
|
|
|
|
|
|
| |
Also use C99 initializers for readability.
discussed with jsing
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
this in ossl_ecdsa_sign() and propagate the return code.
OK jsing@ tb@
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Another set of mechnical replacements for "a,b" with "a, b".
No change in generated assembly.
|
|
|
|
|
|
| |
Mechanically replace "a,b" with "a, b".
No change to generated assembly.
|
|
|
|
|
|
|
| |
Mechanically replace "a,b" with "a, b", followed with some manual
indentation clean up.
No change in generated assembly.
|
|
|
|
| |
No change in generated assembly.
|
|
|
|
|
|
|
|
|
| |
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@
|
|
|
|
|
|
| |
This follows what is done for other SHA implementations.
ok miod@ tb@
|
|
|
|
| |
No intended functional change.
|
|
|
|
| |
ok jsing
|
|
|
|
| |
ok jsing
|
|
|
|
| |
ok jsing
|
|
|
|
| |
ok jsing
|
| |
|
|
|
|
| |
ok tb@
|
|
|
|
| |
ok jsing
|
|
|
|
|
|
|
| |
Like everything else in this file, the use of BN_copy() needs to be ...
special. Simplify using the new bn_copy().
ok jsing
|
|
|
|
| |
ok jsing
|
|
|
|
|
| |
The only reason to use HASH_BLOCK_DATA_ORDER in the implementation is to
make the code harder to read.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
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).
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
No change to generated assembly.
|
| |
|