Threshold Key Derivation - Privacy on the IC

@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.

1 Like

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?

1 Like

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.

1 Like

Hello. Any updates on this?

EDIT:

there is an update! two hours ago!


:joy: :joy: what is this even

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.

10 Likes

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.

13 Likes

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?

2 Likes

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.

7 Likes

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?

1 Like

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.

5 Likes

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 to vetkd_derive_encrypted_key to better express the action that is done (key derivation) and to be more in line with names like sign_with_schnorr and sign_with_ecdsa .

  • the argument field public_key_derivation_path was renamed to public_key, so that both derivation path arguments (one per API) have the same name

  • the key_id’s curve was renamed from bls12_381 to bls12_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.

10 Likes

Can the vetKey API be called from an external principal? Or only from canisters because it requires payment?

1 Like

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”).

1 Like

I updated the file sending demo so that it uses the new VetKD system interface.

2 Likes