| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
| |
These are ~200 lines of EVP_MD API that separated two parts of the file
dedicated to EVP_CIPHER thingies.
|
| |
|
|
|
|
|
|
| |
EVP_Cipher() is a dangerous thin wrapper of the do_cipher() method set on
the EVP_CIPHER_CTX's cipher. It implements (part of) the update and final
step of the EVP_Cipher* API. Its behavior is nuts and will be documented
in a comment in a subsequent commit. schwarze has a manpage diff that will
fix the incorrect documentation.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
A recent change in EVP_CIPHER_CTX_iv_length() made it possible in principle
that this function returns -1. This can only happen for an incorrectly set
up EVP_CIPHER. Still it is better form to check for negative lengths before
stuffing it into a memcpy().
It would probably be desirable to cap the iv_length to something large
enough. This can be done another time.
ok beck
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In today's episode of "curly nonsense from EVP land" we deal with a quite
harmless oversight and a not too bad suboptimal fix, relatively speaking.
At some point EVP_CIPHER_{CCM,GCM}_SET_IVLEN was added. It modified some
object hanging off of EVP_CIPHER. However, EVP_CIPHER_CTX_iv_length() wasn't
taught about this and kept returning the hardcoded default value on the
EVP_CIPHER. Once it transpired that a doc fix isn't going to cut it, this
was fixed. And of course it's easy to fix: you only have to dive through
about three layers of EVP, test and set a flag and handle a control in a
couple methods.
The upstream fix was done poorly and we begrudgingly have to match the API:
the caller is expected to pass a raw pointer next to a 0 length along with
EVP_CIPHER_GET_IV_LENGTH and the control handler goes *(int *)ptr = length
in full YOLO mode. That's never going to be an issue because of course the
caller will always pass a properly aligned pointer backing a sufficient
amount of memory. Yes, unlikely to be a real issue, but it could have been
done with proper semantics and checks without complicating the code. But
why do I even bother to complain? We're used to this.
Of note here is that there was some pushback painting other corners of a
bikeshed until the reviewer gave up with a resigned
That kind of changes the semantics and is one extra complexity level,
but [shrug] ok...
Anyway, the reason this matters now after so many years is that rust-openssl
has an assert, notably added in a +758 -84 commit with the awesome message
"Docs" that gets triggered by recent tests added to py-cryptography.
Thanks to Alex Gaynor for reporting this. Let me take the opportunity to
point out that pyca contributed to improve rust-openssl, in particular its
libressl support, quite a bit. That's much appreciated and very noticeable.
Regress coverage to follow in subsequent commits.
Based on OpenSSL PR #9499 and issue #8330.
ok beck jsing
PS: A few macros were kept internal for now to avoid impact on the release
cycle that is about to finish. They will be exposed after release.
|
| |
|
|
|
|
|
|
| |
me aliasing symbols not in the headers I was procesing.
This unbreaks the namespace build so it will pass again
ok tb@
|
| |
|
|
|
|
| |
(part 2 of commit)
ok jsing@
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Libcrypto currently has a mess of *_lcl.h, *_locl.h, and *_local.h names
used for internal headers. Move all these headers we inherited from
OpenSSL to *_local.h, reserving the name *_internal.h for our own code.
Similarly, move dtls_locl.h and ssl_locl.h to dtls_local and ssl_local.h.
constant_time_locl.h is moved to constant_time.h since it's special.
Adjust all .c files in libcrypto, libssl and regress.
The diff is mechanical with the exception of tls13_quic.c, where
#include <ssl_locl.h> was fixed manually.
discussed with jsing,
no objection bcook
|
| |
|
|
|
|
|
|
|
| |
This allows implementations to add their own EVP_MD_METHODs.
Only the setters are provided.
This is used by erlang for the otp_test_engine.
ok inoguchi jsing
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This API with very strange ownership handling is used by Ruby 3.1,
unfortunately.
For unclear reasons, it was decided that the caller retains ownership of
the pctx passed in. EVP_PKEY_CTX aren't refcounted, so a flag was added to
make sure that md_ctx->pctx is not freed in EVP_MD_CTX_{cleanup,reset}().
Since EVP_MD_CTX_copy_ex() duplicates the md_ctx->pctx, the flag also needs
to be unset on the duplicated EVP_MD_CTX.
ok inoguchi jsing
|
| |
|
|
| |
discussed with jsing
|
| |
|
|
|
|
| |
They will be needed by security/py-M2Crypto and telephony/sngrep.
ok inoguchi jsing
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is just a dumb 'return ctx->buf' whose name was chosen to be consistent
with EVP_CIPHER_CTX_iv{,_noconst}() though there is no EVP_CIPHER_CTX_buf()
ok jsing
The backstory is this:
This wonderful API will be needed by MariaDB once EVP is opaque. To be able
to use its own handrolled AES CTR variant, it needs to reach inside the cipher
ctx's buffer and mess with it:
uchar *buf= EVP_CIPHER_CTX_buf_noconst(ctx);
/*
Not much we can do, block ciphers cannot encrypt data that aren't
a multiple of the block length. At least not without padding.
Let's do something CTR-like for the last partial block.
NOTE this assumes that there are only buf_len bytes in the buf.
If OpenSSL will change that, we'll need to change the implementation
of this class too.
*/
Being the dumb return ctx->buf that it is, the EVP_CIPHER_CTX_buf_noconst() API
obviously doesn't provide a means of doing any length checks.
If it is any consolation, it was committed with the vague hope of being a
temporary measure as OpenSSL commit 83b06347 suggests:
Note that the accessors / writers for iv, buf and num may go away, as
those rather belong in the implementation's own structure (cipher_data)
when the implementation would affect them [...]
As is true for many temporary kludges and dumb accessors, these are here
to stay a with us for a while.
While I'm at it, MariaDB has other phantastic things it did to ease its
pain with the OpenSSL 1.1 API transition.
To avoid one of two allocations (we're talking about ~50 and ~170 bytes) per
EVP_{MD,CIPHER}_CTX instantiation, it defines EVP_{MD,CIPHER}_CTX_SIZE and
uses arrays of these sizes that it aligns, casts and passes as ctx to the
EVP API.
Of course, they need to safeguard themselves against the inevitable buffer
overruns that this might cause since the type is opaque and could (and actually
did) change its size between two OpenSSL releases. There is a runtime check in
mysys_ssl/openssl.c that uses CRYPTO_set_mem_functions() to replace malloc()
with "coc_malloc()" to determine the sizes that OpenSSL would allocate
internally when doing EVP_{MD,CIPHER}_CTX_new() and match them to MariaDB's
ideas of the ctx sizes.
Go look, I'm not making this stuff up.
|
| |
|
|
|
|
| |
evp.h will be moved to evp_locl.h in an upcoming bump.
ok inoguchi
|
| |
|
|
| |
ok beck jsing
|
| |
|
|
|
|
| |
RSA_meth_get_finish() RSA_meth_set1_name() EVP_CIPHER_CTX_(get|set)_iv()
feedback and ok jsing@ tb@
|
| |
|
|
|
| |
tested in a bulk by sthen
ok jsing
|
| |
|
|
|
|
| |
as was done earlier in libssl. Thanks inoguchi@ for noticing
libssl had more reacharounds into this.
ok jsing@ inoguchi@
|
| |
|
|
| |
Careful review, feedback & ok doug@ jsing@
|
| |
|
|
|
|
|
|
| |
Remove the openssl public includes from cryptlib.h and add a small number
of includes into the source files that actually need them. While here,
also sort/group/tidy the includes.
ok beck@ miod@
|
| |
|
|
|
|
| |
are needed in the source files that actually require them.
ok beck@ miod@
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
*warning* this bumps shared lib minors for libssl and libcrypto from 2.1 to 2.2
if you are using the ssl26 packages for ssh and other things to work you will
need to get new ones (see ~beck/libsslsnap/<arch>) on cvs or ~beck/src-patent.tar.gz on cvs
|
| | |
|
|
|
functionality for shared libs.
Note that routines such as sslv2_init and friends that use RSA will
not work due to lack of RSA in this library.
Needs documentation and help from ports for easy upgrade to full
functionality where legally possible.
|
