Make PrivateKey loading libctx aware#11494
Closed
mattcaswell wants to merge 9 commits intoopenssl:masterfrom
Closed
Make PrivateKey loading libctx aware#11494mattcaswell wants to merge 9 commits intoopenssl:masterfrom
mattcaswell wants to merge 9 commits intoopenssl:masterfrom
Conversation
levitte
reviewed
Apr 8, 2020
levitte
reviewed
Apr 8, 2020
crypto/evp/evp_pkey.c
Outdated
Member
There was a problem hiding this comment.
So while you're making new public functions out of the others, this one you're making internal... it seems inconsistent, wanna tell me why?
Member
Author
There was a problem hiding this comment.
It wasn't clear to me whether we wanted to encourage the use of EVP_PKCS82PKEY or not. While I wasn't sure I erred on the side of caution thinking it was easier to make things public later than the other way around.
mattcaswell
force-pushed
the
privkey-libctx
branch
from
ed1c8ed to
7d154a8
Compare
Member
Author
|
Fixup pushed addressing the comment above. I also rebased to resolve a conflict with master. Please look again. |
Member
|
travis error is relevant.. include/openssl/pem.h:353:34: error: unknown type name 'FILE' |
slontis
reviewed
Apr 9, 2020
slontis
reviewed
Apr 9, 2020
mattcaswell
force-pushed
the
privkey-libctx
branch
from
7d154a8 to
bfbc677
Compare
Member
Author
|
I've rebased this and pushed a fixup to (hopefully) resolve the travis issue. Please take another look. |
This was referenced Apr 9, 2020
The Ed448 private key decoding makes algorithm fetches. Therefore we teach d2i_PrivateKey et al about libctx and make sure it is passed through the layers.
The Ed448 private key deconding needs to use a library ctx. So we implement a priv_decode_with_libctx function for it.
We restrict this to just the PrivateKey loading code at the moment.
Now that d2i_PrivateKey_ex() and other similar functions exist we should use it when loading a PEM PrivateKey.
Since loading a private key might require algorithm fetches we should make sure the correct libctx is used.
mattcaswell
force-pushed
the
privkey-libctx
branch
from
bfbc677 to
93be520
Compare
Member
Author
|
Rebased again to fix conflicts with master. Also another fix up to address travis issues. Ping? |
This was referenced Apr 10, 2020
slontis
approved these changes
Apr 14, 2020
slontis
added
the
approval: done
openssl-machine
added
approval: ready to merge
Collaborator
|
This pull request is ready to merge |
Member
Author
|
Pushed. Thanks. |
openssl-machine
pushed a commit
that referenced
this pull request
Apr 15, 2020
The Ed448 private key decoding makes algorithm fetches. Therefore we teach d2i_PrivateKey et al about libctx and make sure it is passed through the layers. Reviewed-by: Shane Lontis <[email protected]> (Merged from #11494)
openssl-machine
pushed a commit
that referenced
this pull request
Apr 15, 2020
The Ed448 private key deconding needs to use a library ctx. So we implement a priv_decode_with_libctx function for it. Reviewed-by: Shane Lontis <[email protected]> (Merged from #11494)
openssl-machine
pushed a commit
that referenced
this pull request
Apr 15, 2020
We restrict this to just the PrivateKey loading code at the moment. Reviewed-by: Shane Lontis <[email protected]> (Merged from #11494)
openssl-machine
pushed a commit
that referenced
this pull request
Apr 15, 2020
Now that d2i_PrivateKey_ex() and other similar functions exist we should use it when loading a PEM PrivateKey. Reviewed-by: Shane Lontis <[email protected]> (Merged from #11494)
openssl-machine
pushed a commit
that referenced
this pull request
Apr 15, 2020
Since loading a private key might require algorithm fetches we should make sure the correct libctx is used. Reviewed-by: Shane Lontis <[email protected]> (Merged from #11494)
openssl-machine
pushed a commit
that referenced
this pull request
Apr 15, 2020
Reviewed-by: Shane Lontis <[email protected]> (Merged from #11494)
Member
|
Do you have more PR's that you are about to merge? libcrypto.num is a bit of a problem. |
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
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.
During loading of a private key it is possible that the implementation will need to use a cryptographic algorithm Notably in decoding an Ed448 private key we automatically derive the public key (because it is not encoded along with the private key). To do so we need to use SHAKE256. This means that we have to make the private key loading functions OPENSSL_CTX aware.
We also update libssl to use the new private key loading functions.
This is needed for alpha1