| Age | Commit message (Collapse) | Author |
|---|
|
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
|
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(cherry picked from commit 3f6c7691870d1cd2ad0e0c83638cef3f35a0b548)
|
|
Reviewed-by: Matt Caswell <matt@openssl.org>
|
|
Reviewed-by: Matt Caswell <matt@openssl.org>
(cherry picked from commit 2d540402aac7a05af9c99b58864d53c0201a0b42)
|
|
Recent HMAC changes broke ABI compatibility due to a new field in HMAC_CTX.
This backs that change out, and does it a different way.
Thanks to Timo Teras for the concept.
Conflicts:
crypto/hmac/hmac.c
Reviewed-by: Richard Levitte <levitte@openssl.org>
|
|
In the event of an error in the HMAC function, leaks can occur because the
HMAC_CTX does not get cleaned up.
Thanks to the BoringSSL project for reporting this issue.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(cherry picked from commit e43a13c807e42688c72c4f3d001112bf0a110464)
|
|
We had updates of certain header files in both Makefile.org and the
Makefile in the directory the header file lived in. This is error
prone and also sometimes generates slightly different results (usually
just a comment that differs) depending on which way the update was
done.
This removes the file update targets from the top level Makefile, adds
an update: target in all Makefiles and has it depend on the depend: or
local_depend: targets, whichever is appropriate, so we don't get a
double run through the whole file tree.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit 0f539dc1a2f45580435c39dada44dd276e79cb88)
Conflicts:
Makefile.org
apps/Makefile
test/Makefile
|
|
Reviewed-by: Matt Caswell <gitlab@openssl.org>
|
|
Reviewed-by: Richard Levitte <levitte@openssl.org>
|
|
Reviewed-by: Richard Levitte <levitte@openssl.org>
|
|
create an HMAC
Inspired by BoringSSL commit 2fe7f2d0d9a6fcc75b4e594eeec306cc55acd594
Reviewed-by: Richard Levitte <levitte@openssl.org>
Conflicts:
crypto/hmac/hmac.c
|
|
Reviewed-by: Richard Levitte <levitte@openssl.org>
|
|
Reviewed-by: Tim Hudson <tjh@openssl.org>
|
|
Conflicts:
crypto/hmac/hmac.h
Reviewed-by: Tim Hudson <tjh@openssl.org>
|
|
This is a more comprehensive fix. It changes all
keygen apps to use 2K keys. It also changes the
default to use SHA256 not SHA1. This is from
Kurt's upstream Debian changes.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Kurt Roeckx <kurt@openssl.org>
(cherry picked from commit 44e0c2bae4bfd87d770480902618dbccde84fd81)
|
|
When in FIPS mode the approved implementations are used as normal,
when not in FIPS mode the internal unapproved versions are used instead.
This means that the FIPS capable OpenSSL isn't forced to use the
(often lower perfomance) FIPS implementations outside FIPS mode.
|
|
|
|
|
|
of assuming they will always suceed.
|
|
|
|
|
|
later.
|
|
test for them!
|
|
knock-on work than expected - they've been extracted into a patch
series that can be completed elsewhere, or in a different branch,
before merging back to HEAD.
|
|
|
|
|
|
|
|
|
|
of handshake failure
2. Changes to x509_certificate_type function (crypto/x509/x509type.c) to
make it recognize GOST certificates as EVP_PKT_SIGN|EVP_PKT_EXCH
(required for s3_srvr to accept GOST client certificates).
3. Changes to EVP
- adding of function EVP_PKEY_CTX_get0_peerkey
- Make function EVP_PKEY_derive_set_peerkey work for context with
ENCRYPT operation, because we use peerkey field in the context to
pass non-ephemeral secret key to GOST encrypt operation.
- added EVP_PKEY_CTRL_SET_IV control command. It is really
GOST-specific, but it is used in SSL code, so it has to go
in some header file, available during libssl compilation
4. Fix to HMAC to avoid call of OPENSSL_cleanse on undefined data
5. Include des.h if KSSL_DEBUG is defined into some libssl files, to
make debugging output which depends on constants defined there, work
and other KSSL_DEBUG output fixes
6. Declaration of real GOST ciphersuites, two authentication methods
SSL_aGOST94 and SSL_aGOST2001 and one key exchange method SSL_kGOST
7. Implementation of these methods.
8. Support for sending unsolicited serverhello extension if GOST
ciphersuite is selected. It is require for interoperability with
CryptoPro CSP 3.0 and 3.6 and controlled by
SSL_OP_CRYPTOPRO_TLSEXT_BUG constant.
This constant is added to SSL_OP_ALL, because it does nothing, if
non-GOST ciphersuite is selected, and all implementation of GOST
include compatibility with CryptoPro.
9. Support for CertificateVerify message without length field. It is
another CryptoPro bug, but support is made unconditional, because it
does no harm for draft-conforming implementation.
10. In tls1_mac extra copy of stream mac context is no more done.
When I've written currently commited code I haven't read
EVP_DigestSignFinal manual carefully enough and haven't noticed that
it does an internal digest ctx copying.
This implementation was tested against
1. CryptoPro CSP 3.6 client and server
2. Cryptopro CSP 3.0 server
|
|
Initialize context properly for HMAC pkey method.
|
|
|
|
PR: 1503
Submitted by: KISA
Reviewed by: Bodo Moeller
|
|
Remove unnecessary reference to EVP_MD_CTX in HMAC pkey method.
|
|
|
|
|
|
first everywhere in crypto and skip stdio.h and string.h [because it
includes them].
|
|
[most importantly] put back dependencies accidentaly eliminated in
check-in #13342.
|
|
|
|
|
|
|
|
|
|
if $(EXHEADER) is empty.
Notified by many, solution suggested by Carson Gaspar <carson@taltos.org>
|
|
|
|
|
|
|
|
the Makefiles. NB: this commit is probably going to generate a huge posting
and it is highly uninteresting to read.
|
|
|
|
This is part of a large change submitted by Markus Friedl <markus@openbsd.org>
|
|
I have tried to convert 'len' type variable declarations to unsigned as a
means to address these warnings when appropriate, but when in doubt I have
used casts in the comparisons instead. The better solution (that would get
us all lynched by API users) would be to go through and convert all the
function prototypes and structure definitions to use unsigned variables
except when signed is necessary. The proliferation of (signed) "int" for
strictly non-negative uses is unfortunate.
|
|
|
