@nokemono, what vetKeys will provide is mainly a management canister API that canisters can call to derive a strong cryptographic key from a master key (see vetkd_encrypted_key
in the proposed API), where the master key is secret-shared among the nodes of a subnet. The derivation is done based on some derivation information that the canister developer chooses (plus the calling canister’s principal). The derivation information is essentially a byte string and can be (but doesn’t have to be) a user’s principal. The derivation is deterministic, that is, if the same derivation information is passed to the API, the derived vetKey will also be the same. So, if a canister developer uses a user’s (unique) name or principal as derivation information, then the vetKey for the user will be unique, yes. However, it really depends on the use case: for example, the canister developer could (for whatever reason) also choose to use the same derivation information for two different users, in which case both users would receive the same vetKey and it thus would not be unique.
As asked here about tecdsa Subnets with heavy compute load: what can you do now & next steps - #18 by Jesse
I guess the same question could be asked of vetkeys. If you have to bail on a subnet and get a new canister ID, all those keys will be lost to you?
The vetKeys feature is designed such that, as also mentioned above, the calling canister’s principal is implicitly part of the derivation information. That means that if keys are derived with a different canister (meaning it has a different canister ID), then the derived keys will be different, even if the same derivation information is used.
So, if you want to manually “move” a canister to a different subnet so that it has a different=new canister ID, you first have to come up with a migration strategy for data that is encrypted with vetKeys you derived with the old canister. Once you delete the old canister, you loose the ability to derive vetKeys relative to its (old) canister ID.
How exactly the mentioned migration looks like very much depends on how the vetKeys were used.
Engineering has recently begun working on the system integration of vetKeys. The ETA of the production release is end of Q1/2025 - beginning Q2/2025.
You have been saying the same since early 2023
Hey @Catthew,
there have been multiple stages towards vetKeys that required different teams from R&D.
First stage was research which was done in 2023 and published here: vetKeys: How a Blockchain Can Keep Many Secrets
Second stage was implementing a developer preview to define the APIs, create a small SDK and allow developers to get experience working with the new primitive and provide feedback. We’ve sponsored this with bounties.
In both of these stages only individual R&D teams had needed to be involved. For the final stage, the system integration which now started, multiple R&D need to coordinate, and other work like general performance improvements as well as threshold Schnorr/EdDSA has been prioritized over vetKeys.
Is the proposed vetkey API with hard-coded key available in main net? Or only in a local replica?
Can it be called only by a canister or also by an external principal?
Yes, vetkeys API with a hard-coded key is implemented in the chainkey testing canister, which is available on mainnet (vrqyr-saaaa-aaaan-qzn4q-cai
), i.e., the caller needs to call that canister instead of the management canister. The key ID supported there is insecure_test_key_1
.
AFAICT, the chainkey testing canister currently allows calls by external principals, but maybe this will be changed in the future to keep the API as close as possible to the management canister API.
Where can I find an estimate of the cycles costs for the upcoming vetkd_public_key
and vetkd_encrypted_key
APIs?
Is it reasonable to expect a cost similar to the threshold ECDSA API?
We are currently in the process of determining the price, but didn’t make a final decision yet.
Yes. It is safe to assume that the API fees for threshold signatures (tECDSA/tSchnorr) are an upper bound for the fees for threshold key derivation (vetKD/vetKeys). It is a likely scenario that the fees for vetKD will be the same as for tECDSA/tSchnorr, at least initially.
Hello! Here is a quick update from the DFINITY team. As we are progressing in our integration of threshold key derivation (aka the vetKeys feature) into the Internet Computer Protocol, we also made some minor adaptions to the expected vetKD API (see this commit). In particular:
-
the IC method
vetkd_encrypted_key
was renamed tovetkd_derive_encrypted_key
to better express the action that is done (key derivation) and to be more in line with names likesign_with_schnorr
andsign_with_ecdsa
. -
the argument field
public_key_derivation_path
was renamed topublic_key
, so that both derivation path arguments (one per API) have the same name -
the
key_id
’s curve was renamed frombls12_381
tobls12_381_g2
to be more precise, more future-proof, and to make it obvious that the master public key is in group G2
The various vetKD-related examples all have been updated accordingly (see examples/pull/1087). The chainkey-testing-canister was updated as well, (see chainkey-testing-canister/pull/9) and it was re-deployed.
Can the vetKey API be called from an external principal? Or only from canisters because it requires payment?
The vetKey APIs will only be callable by canisters. Last week, I also adapted the IC spec PR to explicitly mention this (“This method can only be called by canisters, i.e., it cannot be called by external users via ingress messages”).
I updated the file sending demo so that it uses the new VetKD system interface.