Age | Commit message (Collapse) | Author |
|
Just as was done recently for i2d_ASN1_OBJECT, we also make
i2d_ASN1_BOOLEAN comply with the documentation.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6943)
|
|
Since 0.9.7, all i2d_ functions were documented to allocate an output
buffer if the user didn't provide one, under these conditions (from
the 1.0.2 documentation):
For OpenSSL 0.9.7 and later if B<*out> is B<NULL> memory will be
allocated for a buffer and the encoded data written to it. In this
case B<*out> is not incremented and it points to the start of the
data just written.
i2d_ASN1_OBJECT was found not to do this, and would crash if a NULL
output buffer was provided.
Fixes #6914
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/6918)
(cherry picked from commit 6114041540d8d1fecaf23a861788c3c742d3b467)
|
|
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6889)
(cherry picked from commit 582ad5d4d9b7703eb089016935133e3a18ea8205)
Resolved conflicts:
crypto/rsa/rsa_ossl.c
crypto/rsa/rsa_pk1.c
|
|
It was false positive, but one can as well view it as readability issue.
Switch even to unsigned indices because % BN_BYTES takes 4-6 instructions
with signed dividend vs. 1 (one) with unsigned.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6889)
(cherry picked from commit 83e034379fa3f6f0d308ec75fbcb137e26154aec)
|
|
"Computationally constant-time" means that it might still leak
information about input's length, but only in cases when input
is missing complete BN_ULONG limbs. But even then leak is possible
only if attacker can observe memory access pattern with limb
granularity.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6889)
(cherry picked from commit 89d8aade5f4011ddeea7827f08ec544c914f275a)
Resolved conflicts:
crypto/bn/bn_lib.c
|
|
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6881)
|
|
(back-ported from commit 37132c9702328940a99b1307f742ab094ef754a7)
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6810)
|
|
Those even order that do not play nicely with Montgomery arithmetic
(back-ported from commit 3a6a4a93518fbb3d96632bfdcb538d340f29c56b)
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6810)
|
|
New implementation failed to correctly reset r->neg flag. Spotted by
OSSFuzz.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6810)
(cherry picked from commit 70a579ae2f37437a1e02331eeaa84e1b68ba021e)
|
|
Originally suggested solution for "Return Of the Hidden Number Problem"
is arguably too expensive. While it has marginal impact on slower
curves, none to ~6%, optimized implementations suffer real penalties.
Most notably sign with P-256 went more than 2 times[!] slower. Instead,
just implement constant-time BN_mod_add_quick.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6810)
(cherry picked from commit 3fc7a9b96cbed0c3da6f53c08e34d8d0c982745f)
Resolved onflicts:
crypto/ec/ecdsa_ossl.c
crypto/include/internal/bn_int.h
|
|
Note that exported functions maintain original behaviour, so that
external callers won't observe difference. While internally we can
now perform Montogomery multiplication on fixed-length vectors, fixed
at modulus size. The new functions, bn_to_mont_fixed_top and
bn_mul_mont_fixed_top, are declared in bn_int.h, because one can use
them even outside bn, e.g. in RSA, DSA, ECDSA...
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6810)
(cherry picked from commit 71883868ea5b33416ae8283bcc38dd2d97e5006b)
Resolved conflicts:
crypto/bn/bn_exp.c
crypto/bn/bn_lcl.h
crypto/bn/bn_mont.c
crypto/include/internal/bn_int.h
|
|
The new flag marks vectors that were not treated with bn_correct_top,
in other words such vectors are permitted to be zero padded. For now
it's BN_DEBUG-only flag, as initial use case for zero-padded vectors
would be controlled Montgomery multiplication/exponentiation, not
general purpose. For general purpose use another type might be more
appropriate. Advantage of this suggestion is that it's possible to
back-port it...
bn/bn_div.c: fix memory sanitizer problem.
bn/bn_sqr.c: harmonize with BN_mul.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6810)
(cherry picked from commit 305b68f1a2b6d4d0aa07a6ab47ac372f067a40bb)
Resolved conflicts:
crypto/bn/bn_lcl.h
crypto/bn/bn_lib.c
|
|
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6810)
(cherry picked from commit 6c90182a5f87af1a1e462536e7123ad2afb84c43)
|
|
Trouble is that addition is postponing expansion till carry is
calculated, and if addition carries, top word can be zero, which
triggers assertion in bn_check_top.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6810)
(cherry picked from commit e42395e637c3507b80b25c7ed63236898822d2f1)
Resolved conflicts:
crypto/bn/bn_lib.c
|
|
level of the prime
The old numbers where all generated for an 80 bit security level. But
the number should depend on security level you want to reach. For bigger
primes we want a higher security level and so need to do more tests.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
GH: #6075
Fixes: #6012
(cherry picked from commit feac7a1c8be49fbcb76fcb721ec9f02fdd91030e)
|
|
This changes the security level from 100 to 128 bit.
We only have 1 define, this sets it to the highest level supported for
DSA, and needed for keys larger than 3072 bit.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
GH: #6075
(cherry picked from commit 74ee379651fb2bb12c6f7eb9fa10e70be89ac7c8)
|
|
Thanks to Jiecheng Wu, Zuxing Gu for the report.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6791)
(cherry picked from commit 037241bf046be8cfc7e9216959393dd20b06fc21)
(Only the EC part)
|
|
ecp_nistz256_set_from_affine is called when application attempts to use
custom generator, i.e. rarely. Even though it was wrong, it didn't
affect point operations, they were just not as fast as expected.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6761)
|
|
As per RFC 7292.
Fixes #6665
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
(Merged from https://github.com/openssl/openssl/pull/6708)
(cherry picked from commit b709babbca0498cd2b05f543b09f57f4a670298e)
|
|
Fixes uninitialized memory read reported by Nick Mathewson
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6603)
(cherry picked from commit 10c3c1c1ec41ce16e51b92bb18fab92d1a42b49c)
|
|
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6581)
(cherry picked from commit dc6c374bdb4872f6d5d727e73a2ed834e972842c)
|
|
This extends the recently added ECDSA signature blinding to blind DSA too.
This is based on side channel attacks demonstrated by Keegan Ryan (NCC
Group) for ECDSA which are likely to be able to be applied to DSA.
Normally, as in ECDSA, during signing the signer calculates:
s:= k^-1 * (m + r * priv_key) mod order
In ECDSA, the addition operation above provides a sufficient signal for a
flush+reload attack to derive the private key given sufficient signature
operations.
As a mitigation (based on a suggestion from Keegan) we add blinding to
the operation so that:
s := k^-1 * blind^-1 (blind * m + blind * r * priv_key) mod order
Since this attack is a localhost side channel only no CVE is assigned.
This commit also tweaks the previous ECDSA blinding so that blinding is
only removed at the last possible step.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6524)
|
|
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6499)
(cherry picked from commit b55e21b357902959ae8ec0255952402f5ccaa515)
|
|
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6499)
(cherry picked from commit 9e97f61dec312084abe03226e5c962d818c9fc2b)
|
|
Keegan Ryan (NCC Group) has demonstrated a side channel attack on an
ECDSA signature operation. During signing the signer calculates:
s:= k^-1 * (m + r * priv_key) mod order
The addition operation above provides a sufficient signal for a
flush+reload attack to derive the private key given sufficient signature
operations.
As a mitigation (based on a suggestion from Keegan) we add blinding to
the operation so that:
s := k^-1 * blind^-1 (blind * m + blind * r * priv_key) mod order
Since this attack is a localhost side channel only no CVE is assigned.
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
|
CVE-2018-0732
Signed-off-by: Guido Vranken <guidovranken@gmail.com>
(cherry picked from commit 91f7361f47b082ae61ffe1a7b17bb2adf213c7fe)
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6457)
|
|
This module is used only with odd input lengths, i.e. not used in normal
PKI cases, on contemporary processors. The problem was "illuminated" by
fuzzing tests.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6440)
(cherry picked from commit f55ef97b5c0f8559f393b72ebd4b2de32ad6d231)
|
|
Just because an engine implements algorithm methods, that doesn't mean
it also implements the ASN1 method. Therefore, be careful when looking
for an ASN1 method among all engines, don't try to use one that doesn't
exist.
Fixes #6381
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6383)
|
|
Thanks to Guido Vranken and OSSFuzz for finding this issue.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6355)
(cherry picked from commit 4aa5b725d549b3ebc3a4f2f1c44e44a11f68752b)
|
|
The variable in question can never be used uninitialised, but we silence
the compiler anyway.
Fixes #6301
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6329)
|
|
If the lengths of both names is 0 then don't attempt to do a memcmp.
Issue reported by Simon Friedberger, Robert Merget and Juraj Somorovsky.
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/6291)
(cherry picked from commit 511190b691183a1fb160e7e05e2974dc73cab0c6)
|
|
Experiments have shown that the lookup table used by BN_GF2m_mod_arr
introduces sufficient timing signal to recover the private key for an
attacker with access to cache timing information on the victim's host.
This only affects binary curves (which are less frequently used).
No CVE is considered necessary for this issue.
The fix is to replace the lookup table with an on-the-fly calculation of
the value from the table instead, which can be performed in constant time.
Thanks to Youngjoo Shin for reporting this issue.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6270)
(cherry picked from commit b336ce57f2d5cca803a920d2a9e622b588cead3c)
|
|
The Console UI method always set echo on after prompting without
echo. However, echo might not have been on originally, so just
restore the original TTY settings.
Fixes #2373
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6158)
|
|
(cherry picked from commit aebd0e5ca12d1ba0b229a4121a54afa5ea2d8aa1)
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6238)
|
|
Fixes #4716
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6173)
(cherry picked from commit c82c3462267afdbbaa53e11da0508ce4e03c02b3)
|
|
- Reject fractional seconds
- Reject offsets
- Check that the date/time digits are in valid range.
- Add documentation for X509_cmp_time
GH issue 2620
Backported from 80770da39e
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/6182)
|
|
When the input length is zero, just return zero early. Otherwise,
there's a small chance that memory allocation is engaged, fails and
returns -1, which is a bit confusing when nothing should be written.
Fixes #4782 #4827
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/6175)
(cherry picked from commit 0d94212a046e87fafea6e83e8ea2b2a58db49979)
|
|
Montgomery multiplication post-conditions in some of code paths were
formally non-constant time. Cache access pattern was result-neutral,
but a little bit asymmetric, which might have produced a signal [if
processor reordered load and stores at run-time].
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6163)
(cherry picked from commit 774ff8fed67e19d4f5f0df2f59050f2737abab2a)
Resolved conflicts in ppc-mont.pl and x86_64-mont.pl.
(cherry picked from commit d067ba3bcc4944140578bdbf857affa6faf9e8c1)
|
|
Fixes #6121
Thanks to Mingtao Yang for reporting this bug.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6164)
|
|
which is used for ASN1_STRING_print_ex*() and X509_NAME_print_ex*().
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6118)
|
|
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6102)
|
|
Add a bit more commentary to explain what's going on.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6080)
(cherry picked from commit d6d94d339756332bbabe2a1032ac511ae31b3fdc)
|
|
That error is already caught by EVP_read_pw_string_min, and causes
this function to return -1, so the code detecting too short passwords
in this function is practically dead.
Fixes #5465
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6080)
(cherry picked from commit 4977b4e9281c981efcf6a8b31378b8bbd6a8a96f)
|
|
The X509_STORE_CTX_init() docs explicitly allow a NULL parameter for the
X509_STORE. Therefore we shouldn't crash if we subsequently call
X509_verify_cert() and no X509_STORE has been set.
Fixes #2462
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6003)
|
|
If we have a non-matching kdf_type then pkey_dh_derive silently succeeds.
It should fail. This is a "should not happen" condition anyway so the
impact is negligible.
Fixes #2440
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6000)
|
|
The behaviour of X509_cmp_time used to be undocumented.
The new behaviour, documented in master, is to return only 0, 1, or -1.
Make the code in the other branches to adhere to this behaviour too,
to reduce confusion. There is nothing to be gained from returning
other values.
Fixes GH#4954
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4955)
(cherry picked from commit 48345917747a34feea3da2936994a265c7f2ca11)
|
|
The wrong flags were being tested. It is the rsa->meth flags not the rsa
flags that should be tested.
wpa_supplicant has a bit of code that
1. Allocates and defines a RSA_METHOD structure.
2. calls RSA_new();
3. calls RSA_set_method().
In current versions of that code the rsa_sign and rsa_verify members of
the RSA_METHOD structure are not defined, thus making it compatible
with the really old versions of OpenSSL.
But should one change it use the rsa_sign method one must set the
RSA_FLAG_SIGN_VER bit of the RSA_METHOD structure to indicate that
one or both of those new methods are required. In doing so, OpenSSL
will not call the new methods, not without this change.
CLA: trivial
Change-Id: I6e65a80f21399f25e966466ff676e3b21f85f360
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5971)
|
|
called with BN_FLG_CONSTTIME flag set.
CVE-2018-0737
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(cherry picked from commit 6939eab03a6e23d2bd2c3f5e34fe1d48e542e787)
|
|
There are two undocumented DSA parameter generation options available in
the genpkey command line app:
dsa_paramgen_md and dsa_paramgen_q_bits.
These can also be accessed via the EVP API but only by using
EVP_PKEY_CTX_ctrl() or EVP_PKEY_CTX_ctrl_str() directly. There are no
helper macros for these options.
dsa_paramgen_q_bits sets the length of q in bits (default 160 bits).
dsa_paramgen_md sets the digest that is used during the parameter
generation (default SHA1). In particular the output length of the digest
used must be equal to or greater than the number of bits in q because of
this code:
if (!EVP_Digest(seed, qsize, md, NULL, evpmd, NULL))
goto err;
if (!EVP_Digest(buf, qsize, buf2, NULL, evpmd, NULL))
goto err;
for (i = 0; i < qsize; i++)
md[i] ^= buf2[i];
/* step 3 */
md[0] |= 0x80;
md[qsize - 1] |= 0x01;
if (!BN_bin2bn(md, qsize, q))
goto err;
qsize here is the number of bits in q and evpmd is the digest set via
dsa_paramgen_md. md and buf2 are buffers of length SHA256_DIGEST_LENGTH.
buf2 has been filled with qsize bits of random seed data, and md is
uninitialised.
If the output size of evpmd is less than qsize then the line "md[i] ^=
buf2[i]" will be xoring an uninitialised value and the random seed data
together to form the least significant bits of q (and not using the
output of the digest at all for those bits) - which is probably not what
was intended. The same seed is then used as an input to generating p. If
the uninitialised data is actually all zeros (as seems quite likely)
then the least significant bits of q will exactly match the least
significant bits of the seed.
This problem only occurs if you use these undocumented and difficult to
find options and you set the size of q to be greater than the message
digest output size. This is for parameter generation only not key
generation. This scenario is considered highly unlikely and
therefore the security risk of this is considered negligible.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5884)
|
|
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5884)
|