Feature: AsymmetricKey::generate_another()#3770
Merged
reneme merged 3 commits intorandombit:masterfrom Oct 25, 2023
Merged
Conversation
5 tasks
02fec16 to
2e99e4f
Compare
Given some abstract public or private key, downstream users can generate another keypair with the same algorithm parameters. This is most-useful for generating ephemeral key-agreement keys.
2e99e4f to
a878ffa
Compare
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
3 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.
As suggested in #3706, this adds
::generate_another(RNG&). Given some (abstract) asymmetric key object, one can simply generate another equivalent key pair that uses the same algorithm and parameters. This comes in handy if one needs to generate an ephemeral key pair for a public key received from a peer.Currently, the new method is used in the
KEX_to_KEM_Adapterclass, only. Though, the DLIES and ECIES implementation might benefit from them as well. At first glance, their APIs appeared to require a bit of a make-over to benefit from::generate_another(). I've left this for future work.Similarly, the PKCS#11 key variants are left for future work -- currently throwing
Not_Implemented. It remains to-be-discussed whether::generate_another()should generate a software instance of the given asymmetric algorithm or whether they should attempt to generate an equivalent keypair via PKCS#11.