Rework EVP_CIPHER support, enhance existing functions #9328
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
A lot of the different numbers associated with ciphers are really algorithm parameters. Key length, block size, IV length, that sort of thing.
The cipher context IV was a bit interesting. EVP_CIPHER_CTX_iv() returns a pointer to the live IV, while EVP_CIPHER_CTX_ctrl() with the type EVP_CTRL_GET_IV gets a copy of the live IV. To support both, we support getting it with both the OSSL_PARAM_OCTET_STRING and OSSL_PARAM_OCTET_PTR datatypes.
richsalz
reviewed
Jul 9, 2019
slontis
reviewed
Jul 10, 2019
paulidale
requested changes
Jul 10, 2019
slontis
reviewed
Jul 10, 2019
paulidale
reviewed
Jul 10, 2019
|
Ok, I've reworked the ugly macros with a function and a set of callbacks. Thanks for pushing me |
|
|
|
D'oh. You're entirely correct |
paulidale
reviewed
Jul 10, 2019
|
CIs are now happy |
|
Just finish tests - proposed correction resolves issue #8895. |
slontis
reviewed
Jul 10, 2019
slontis
reviewed
Jul 10, 2019
|
LGTM |
levitte
added a commit
that referenced
this pull request
Jul 11, 2019
Reviewed-by: Paul Dale <paul.dale@oracle.com> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from #9328)
levitte
added a commit
that referenced
this pull request
Jul 11, 2019
A lot of the different numbers associated with ciphers are really algorithm parameters. Key length, block size, IV length, that sort of thing. Reviewed-by: Paul Dale <paul.dale@oracle.com> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from #9328)
levitte
added a commit
that referenced
this pull request
Jul 11, 2019
…nterfaces Reviewed-by: Paul Dale <paul.dale@oracle.com> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from #9328)
levitte
added a commit
that referenced
this pull request
Jul 11, 2019
The cipher context IV was a bit interesting. EVP_CIPHER_CTX_iv() returns a pointer to the live IV, while EVP_CIPHER_CTX_ctrl() with the type EVP_CTRL_GET_IV gets a copy of the live IV. To support both, we support getting it with both the OSSL_PARAM_OCTET_STRING and OSSL_PARAM_OCTET_PTR datatypes. Reviewed-by: Paul Dale <paul.dale@oracle.com> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from #9328)
2 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This adds missing support for providers in diverse EVP_CIPHER and EVP_CIPHER_CTX functions. A few helper macros found in
crypto/evp/evp_locl.hminimize the code duplication.One bit may be controversial: I've change the proliferation of small functions return small bits of information, such as key length, iv length, that sort of things, into parameters fetchable and settable with get_params and set_params type functions. My main reasoning is that it makes for a more consistent transfer of information data. Others may disagree and I'm open for other points of view.
The cipher context IV was a bit interesting. EVP_CIPHER_CTX_iv() returns a pointer to the live IV, while EVP_CIPHER_CTX_ctrl() with the type EVP_CTRL_GET_IV gets a copy of the live IV. To support both, we support getting it with both the OSSL_PARAM_OCTET_STRING and OSSL_PARAM_OCTET_PTR datatypes.
This is a first, and a bit unexpected... I hadn't foreseen this kind of use for OSSL_PARAM_OCTET_PTR, and this type of use may not always be very well supported, by providers who do not want to share their internals like this (I expect the FIPS provider to refuse this, since that constitutes an intermediate value that probably shouldn't get out).
NOTE: this PR includes the test change from #9324.
NOTE: this PR overlaps #9301 a bit. I left all the AEAD, GCM and CCM stuff alone 'cause I knew it was there already. But @slontis, we may have to discuss coding strategies, they differ a bit 😉