chore(CON-1412): Avoid handling VetKdKeyIds in the IDKG component
#2388
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
Sawchord
changed the title
VetKdKeyIds in the IDKG component
Sawchord
changed the title
VetKdKeyIds in the IDKG componentVetKdKeyIds in the IDKG component
Sawchord
commented
Nov 12, 2024
eichhorl
reviewed
Nov 13, 2024
maksymar
approved these changes
Nov 13, 2024
eichhorl
approved these changes
Nov 13, 2024
alin-at-dfinity
approved these changes
Nov 14, 2024
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 is a PR to secure, that the IDKG protocol can only be invoked with IDKG compatible variants of the
MasterPublicKeyId.It does so by introducing a new type
IDkgMasterPublicKeyId, which wrapsMasterPublicKeyIdand assures, that only an IDKG compatible variant is uses (Either::SchnorrorECDSA).Then it changes the type at some places in the code and then makes changes upstream, such that the Key only needs to be checked once, and from then on it is guaranteed to be IDKG compatible key.
The newly introduced
::VetKDvariant necessitates the introduction of this change. The VetKeys will be using the NiDKG protocol for its key generation, and therefore, a lot of the functions in theconsensus::idkgsubmodule don't make sense to be used with the new variant.The keys get transformed back into
MasterPublicKeyIdfor serialization, so this change does not introduce compatibility issues.When deserializing a
IDkgMasterPublicKeyId, we need to check that it is IDKG compatible and reject otherwise. Since we did not introduce VetKeys yet (and in fact lack the code to do so), there can be no::VetKDvariants ofMasterPublicKeyIdyet in the state.