Threshold Key Derivation - Privacy on the IC

Roadmap
,
162

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

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
164

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
165

Hello. Any updates on this?

EDIT:

there is an update! two hours ago!

image
image991×493 16.2 KB

:joy: :joy: what is this even

166

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
167

You have been saying the same since early 2023

168

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
169

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
170

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
171

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
172

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
173

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.

13 Likes
174

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

1 Like
175

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
176

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

2 Likes
177

looking forward vetkey

178

Slowly catching up on this and drawn back to the conversation by the latest roadmap update. Do we have an estimated date for vetKeys release?

1 Like
179

As we are getting closer to the release of the VetKeys feature we would like to share a preview of the tooling, and ask for your feedback.

We’re inviting the community to test, explore, and provide feedback on the API design and overall usability before we finalize these libraries.

What’s Included in the VetKeys tooling?

1. VetKeys CDK - Supports canister developers

Tools to help canister developers integrate VetKeys into their Internet Computer (ICP) applications.

  • KeyManager – a library for deriving and managing encrypted cryptographic keys.
  • EncryptedMaps – a library for securely storing and sharing encrypted key-value pairs.

2. VetKeys SDK - Supports frontend developers

Tools for frontend developers to interact with VetKD enabled canisters.

  • KeyManager – Facilitates interaction with a KeyManager-enabled canister
  • EncryptedMaps – Facilitates interaction with a EncryptedMaps-enabled canister
  • SDK Utils – Utility functions for working with VetKeys

3. VetKeys Password Manager - Example application

The VetKey Password Manager is an example application demonstrating how to use VetKeys and Encrypted Maps to build a secure, decentralized password manager on the Internet Computer (IC). This application allows users to create password vaults, store encrypted passwords, and share vaults with other users via their Internet Identity Principal.

The example application is available in two versions:

Call for Feedback

We want to ensure that VetKeys and these libraries are intuitive, secure, and developer-friendly. If you’re considering implementing VetKeys in your project or just want to try it out, your feedback is invaluable.

Here are some specific areas where we’d love to hear from you:

  1. Ease of Use – Was it straightforward to integrate the libraries into your project?

  2. API Clarity – Are the APIs well-designed, or do certain methods feel confusing or redundant?

  3. Security Considerations – Do you see any potential risks or areas for improvement in key management and encryption?

  4. Performance – How does the current implementation perform in real-world use cases? Are there any noticeable bottlenecks?

  5. Missing Features – Are there any functionalities you expected but couldn’t find?

  6. Developer Experience – How was the documentation? What could be improved in the examples or setup?

  7. Management Canister API Feedback – If you’ve worked directly with the VetKeys management canister API, do you have any insights on its usability and effectiveness?

Get Involved

:backhand_index_pointing_right: Try out the examples and explore the libraries.

:backhand_index_pointing_right: Report issues or suggestions in this thread.

:backhand_index_pointing_right: Share your experience—we’ll be using community feedback to refine the final release.

Looking forward to your feedback! :rocket:

13 Likes
180

Is there also a Motoko example available?

181

Thank you for the update. Quick question: what is the cost of each basic operation and wen for mainnet?