Makefile.shared was designed to figure out static library names,
shared library names, library version compatibility, import library
names and the like on its own. This was a design for pre-1.1.0
OpenSSL because the main Makefile didn't have all that knowledge.
With 1.1.0, the situation isn't the same, a lot more knowledge is
included in the main Makefile, and while Makefile.shared did things
right most of the time (there are some corner cases, such as the
choice of .sl or .so as DSO extension on some HPUX versions), there's
still an inherent fragility when one has to keep an eye on
Makefile.shared to make sure it produces what the main Makefile
produces.
This change simplifies Makefile.shared by removing all its
"intelligence" and have it depend entirely on the input from the main
Makefile instead. That way, all the naming is driven from
configuration data.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3983)
Using Zeller's congruence to fill the day of week field,
Also populate the day of year field.
Add unit test to cover a number of cases.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3999)
Based on discussion in PR #3566. Reduce duplicated code in original
asn1_utctime_to_tm and asn1_generalizedtime_to_tm, and introduce a new
internal function asn1_time_to_tm. This function also checks if the days
in the input time string is valid or not for the corresponding month.
Test cases are also added.
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/3905)
`args_verify()` and `opt_reset()` are declared in `apps/apps.h`, but they are
not referenced anywhere. So can we remove them from `apps.h`?
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3995)
Changes the EC_KEY_METHOD_get_* family to not need a EC_KEY_METHOD* as
its first parameter, but a const EC_KEY_METHOD*, which is entirely
sufficient.
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
GH: #3985
Add a new config param to specify how the CSPRNG should be seeded.
Illegal values or nonsensical combinations (e.g., anything other
than "os" on VMS or HP VOS etc) result in build failures.
Add RDSEED support.
Add RDTSC but leave it disabled for now pending more investigation.
Refactor and reorganization all seeding files (rand_unix/win/vms) so
that they are simpler.
Only require 128 bits of seeding material.
Many document improvements, including why to not use RAND_add() and the
limitations around using load_file/write_file.
Document RAND_poll().
Cleanup Windows RAND_poll and return correct status
More completely initialize the default DRBG.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/3965)
Hardware used for benchmarking courtesy of Atos, experiments run by
Romain Dolbeau <romain.dolbeau@atos.net>. Kudos!
Reviewed-by: Rich Salz <rsalz@openssl.org>
"Optimize" is in quotes because it's rather a "salvage operation"
for now. Idea is to identify processor capability flags that
drive Knights Landing to suboptimial code paths and mask them.
Two flags were identified, XSAVE and ADCX/ADOX. Former affects
choice of AES-NI code path specific for Silvermont (Knights Landing
is of Silvermont "ancestry"). And 64-bit ADCX/ADOX instructions are
effectively mishandled at decode time. In both cases we are looking
at ~2x improvement.
AVX-512 results cover even Skylake-X :-)
Hardware used for benchmarking courtesy of Atos, experiments run by
Romain Dolbeau <romain.dolbeau@atos.net>. Kudos!
Reviewed-by: Rich Salz <rsalz@openssl.org>
Fixes: issue #3747
make SSL_CIPHER_standard_name globally available and introduce a new
function OPENSSL_cipher_name.
A new option '-convert' is also added to 'openssl ciphers' app.
Documentation and test cases are added.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/3859)
Looking at
http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf
we see that in the CTR_DRBG_Update() algorithm (internal page number 51),
the provided input data is (after truncation to seedlen) xor-d with the
key and V vector (of length keylen and blocklen respectively). The comment
in ctr_XOR notes that xor-ing with 0 is the identity function, so we can
just ignore the case when the provided input is shorter than seedlen.
The code in ctr_XOR() then proceeds to xor the key with the input, up
to the amount of input present, and computes the remaining input that
could be used to xor with the V vector, before accessing a full 16-byte
stretch of the input vector and ignoring the calculated length. The correct
behavior is to respect the supplied input length and only xor the
indicated number of bytes.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3971)
The intention of the removed code was to check if the previous operation
carried. However this does not work. The "mask" value always ends up being
a constant and is all ones - thus it has no effect. This check is no longer
required because of the previous commit.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3832)
In TLS mode of operation the padding value "pad" is obtained along with the
maximum possible padding value "maxpad". If pad > maxpad then the data is
invalid. However we must continue anyway because this is constant time code.
We calculate the payload length like this:
inp_len = len - (SHA_DIGEST_LENGTH + pad + 1);
However if pad is invalid then inp_len ends up -ve (actually large +ve
because it is a size_t).
Later we do this:
/* verify HMAC */
out += inp_len;
len -= inp_len;
This ends up with "out" pointing before the buffer which is undefined
behaviour. Next we calculate "p" like this:
unsigned char *p =
out + len - 1 - maxpad - SHA256_DIGEST_LENGTH;
Because of the "out + len" term the -ve inp_len value is cancelled out
so "p" points to valid memory (although technically the pointer arithmetic
is undefined behaviour again).
We only ever then dereference "p" and never "out" directly so there is
never an invalid read based on the bad pointer - so there is no security
issue.
This commit fixes the undefined behaviour by ensuring we use maxpad in
place of pad, if the supplied pad is invalid.
With thanks to Brian Carpenter for reporting this issue.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3832)
Ported from the last FIPS release, with DUAL_EC and SHA1 and the
self-tests removed. Since only AES-CTR is supported, other code
simplifications were done. Removed the "entropy blocklen" concept.
Moved internal functions to new include/internal/rand.h.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/3789)
We now allow a different protocol version when reusing a session so we can
unconditionally reset the SSL_METHOD if it has changed.
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/3954)
SSL_clear() does not reset the SSL_METHOD if a session already exists in
the SSL object. However, TLSv1.3 does not have an externally visible
version fixed method (only an internal one). The state machine assumes
that we are always starting from a version flexible method for TLSv1.3.
The simplest solution is to just fix SSL_clear() to always reset the method
if it is using the internal TLSv1.3 version fixed method.
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/3954)
TLSv1.3 draft-21 requires the ticket nonce to be at least 1 byte in length.
However NSS sends a zero length nonce. This is actually ok because the next
draft will allow zero length nonces anyway, so we should tolerate this.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3957)
This is an inherent weakness of the padding mode. We can't make the
implementation constant time (see the comments in rsa_pk1.c), so add a
warning to the docs.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Standardized the -rand flag and added a new one:
-rand file...
Always reads the specified files
-writerand file
Always writes to the file on exit
For apps that use a config file, the RANDFILE config parameter reads
the file at startup (to seed the RNG) and write to it on exit if
the -writerand flag isn't used.
Ensured that every app that took -rand also took -writerand, and
made sure all of that agreed with all the documentation.
Fix error reporting in write_file and -rand
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/3862)
This patch addresses the use of uninitialised data raised in Coverity
issues 1414881 and 1414882.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3929)
New register usage pattern allows to achieve sligtly better
performance. Not as much as I hoped for. Performance is believed
to be limited by irreconcilable write-back conflicts, rather than
lack of computational resources or data dependencies.
Reviewed-by: Rich Salz <rsalz@openssl.org>
This gives much more freedom to rearrange instructions. This is
unoptimized version, provided for reference. Basically you need
to compare it to initial 29724d0e15
to figure out the key difference.
Reviewed-by: Rich Salz <rsalz@openssl.org>
If we have a local file with a name starting with 'file:', we don't
want to check if the part after 'file:' is absolute. Instead, mark
each possibility for absolute check if needed, and perform the
absolute check later on, when checking each actual path.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3907)
These cases are performed on Linux only. They check that files with
names starting with 'file:' can be processed as well.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3907)
To handle paths that contain devices (for example, C:/foo/bar.pem on
Windows), try to "open" the URI using the file scheme loader first,
and failing that, check if the device is really a scheme we know.
The "file" scheme does the same kind of thing to pick out the path
part of the URI.
An exception to this special treatment is if the URI has an authority
part (something that starts with "//" directly after what looks like a
scheme). Such URIs will never be treated as plain file paths.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3907)
to_rel_file_uri really treated all files appropriately, absolute and
relative alike, and really just constructs a URI, so gets renamed to
to_file_uri
to_file_uri, on the other hand, forces the path into an absolute one,
so gets renamed to to_abs_file_uri
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3907)
