# Threshold Key Derivation - Privacy on the IC

**URL:** <https://forum.dfinity.org/t/threshold-key-derivation-privacy-on-the-ic/16560>\
**Category:** Developers\
**Tags:** Discussing, privacy\
**Created:** [November 14, 2022, 2:14pm UTC](https://forum.dfinity.org/t/threshold-key-derivation-privacy-on-the-ic/16560 "2022-11-14T14:14:11Z")\
**Posts on this page:** 20\
**Page:** 9

<div class="post-metadata">

**Author:** ![skilesare](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/skilesare/32/5609_2.png) [@skilesare](https://forum.dfinity.org/u/skilesare)\
**Post date:** [October 4, 2024, 5:59pm UTC](https://forum.dfinity.org/t/threshold-key-derivation-privacy-on-the-ic/16560/163 "2024-10-04T17:59:22Z")

</div>

As asked here about tecdsa [Subnets with heavy compute load: what can you do now & next steps - #18 by Jesse](https://forum.dfinity.org/t/subnets-with-heavy-compute-load-what-can-you-do-now-next-steps/35762/18)

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?

---

<div class="post-metadata">

**Author:** ![franzstefan](https://avatars.discourse-cdn.com/v4/letter/f/ba8739/32.png) [@franzstefan](https://forum.dfinity.org/u/franzstefan)\
**Post date:** [October 8, 2024, 12:24pm UTC](https://forum.dfinity.org/t/threshold-key-derivation-privacy-on-the-ic/16560/164 "2024-10-08T12:24:21Z")

</div>

> [@skilesare](#):
>
> 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.

---

<div class="post-metadata">

**Author:** ![Catthew](https://avatars.discourse-cdn.com/v4/letter/c/a8b319/32.png) [@Catthew](https://forum.dfinity.org/u/Catthew)\
**Post date:** [October 22, 2024, 8:40am UTC](https://forum.dfinity.org/t/threshold-key-derivation-privacy-on-the-ic/16560/165 "2024-10-22T08:40:21Z")

</div>

Hello. Any updates on this?

EDIT:

[![](https://us1.discourse-cdn.com/flex023/uploads/dfn/original/3X/f/1/f17050e096653aa3ba68428d14482e14c95cd79c.jpeg "ICP Developer Journey 5.1 | Developing an encrypted notes dapp with vetKeys") ](https://www.youtube.com/watch?v=9xfl8Lln3_s)

there is an update! two hours ago!

 ![image](https://us1.discourse-cdn.com/flex023/uploads/dfn/original/3X/6/0/605f70ee3ce792448bcd771ff7dc09cf2c831401.png)  
😂 😂 what is this even

---

<div class="post-metadata">

**Author:** ![domwoe](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/domwoe/32/5165_2.png) [@domwoe](https://forum.dfinity.org/u/domwoe)\
**Post date:** [October 23, 2024, 3:15pm UTC](https://forum.dfinity.org/t/threshold-key-derivation-privacy-on-the-ic/16560/166 "2024-10-23T15:15:19Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Catthew](https://avatars.discourse-cdn.com/v4/letter/c/a8b319/32.png) [@Catthew](https://forum.dfinity.org/u/Catthew)\
**Post date:** [October 24, 2024, 6:31am UTC](https://forum.dfinity.org/t/threshold-key-derivation-privacy-on-the-ic/16560/167 "2024-10-24T06:31:10Z")

</div>

You have been saying the same since early 2023

---

<div class="post-metadata">

**Author:** ![domwoe](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/domwoe/32/5165_2.png) [@domwoe](https://forum.dfinity.org/u/domwoe)\
**Post date:** [October 24, 2024, 7:46am UTC](https://forum.dfinity.org/t/threshold-key-derivation-privacy-on-the-ic/16560/168 "2024-10-24T07:46:11Z")

</div>

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](https://eprint.iacr.org/2023/616)  
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.

---

<div class="post-metadata">

**Author:** ![timo](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/timo/32/5543_2.png) [@timo](https://forum.dfinity.org/u/timo)\
**Post date:** [December 26, 2024, 5:47pm UTC](https://forum.dfinity.org/t/threshold-key-derivation-privacy-on-the-ic/16560/169 "2024-12-26T17:47:42Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![tkachenko](https://avatars.discourse-cdn.com/v4/letter/t/bcef8e/32.png) [@tkachenko](https://forum.dfinity.org/u/tkachenko)\
**Post date:** [January 2, 2025, 5:27pm UTC](https://forum.dfinity.org/t/threshold-key-derivation-privacy-on-the-ic/16560/170 "2025-01-02T17:27:31Z")

</div>

Yes, vetkeys API with a hard-coded key is implemented in the [chainkey **testing** canister](https://github.com/dfinity/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.

---

<div class="post-metadata">

**Author:** ![ilbert](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/ilbert/32/8717_2.png) [@ilbert](https://forum.dfinity.org/u/ilbert)\
**Post date:** [January 28, 2025, 5:59pm UTC](https://forum.dfinity.org/t/threshold-key-derivation-privacy-on-the-ic/16560/171 "2025-01-28T17:59:54Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![franzstefan](https://avatars.discourse-cdn.com/v4/letter/f/ba8739/32.png) [@franzstefan](https://forum.dfinity.org/u/franzstefan)\
**Post date:** [January 29, 2025, 10:36pm UTC](https://forum.dfinity.org/t/threshold-key-derivation-privacy-on-the-ic/16560/172 "2025-01-29T22:36:31Z")

</div>

> [@ilbert](#):
>
> Where can I find an estimate of the cycles costs for the upcoming `vetkd_public_key` and `vetkd_encrypted_key` APIs?

We are currently in the process of determining the price, but didn’t make a final decision yet.

> [@ilbert](#):
>
> Is it reasonable to expect a cost similar to the threshold ECDSA API?

Yes. It is safe to assume that the [API fees for threshold signatures (tECDSA/tSchnorr)](https://internetcomputer.org/docs/current/references/t-sigs-how-it-works/#api-fees) 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.

---

<div class="post-metadata">

**Author:** ![franzstefan](https://avatars.discourse-cdn.com/v4/letter/f/ba8739/32.png) [@franzstefan](https://forum.dfinity.org/u/franzstefan)\
**Post date:** [January 31, 2025, 1:23pm UTC](https://forum.dfinity.org/t/threshold-key-derivation-privacy-on-the-ic/16560/173 "2025-01-31T13:23:08Z")

</div>

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](https://github.com/dfinity/portal/pull/3763/commits/dff6e57af420780f09ef19bb3e0e2078347426d9)). 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](https://github.com/dfinity/examples/pull/1087)). The chainkey-testing-canister was updated as well, (see [chainkey-testing-canister/pull/9](https://github.com/dfinity/chainkey-testing-canister/pull/9)) and it was re-deployed.

---

<div class="post-metadata">

**Author:** ![timo](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/timo/32/5543_2.png) [@timo](https://forum.dfinity.org/u/timo)\
**Post date:** [February 5, 2025, 11:58am UTC](https://forum.dfinity.org/t/threshold-key-derivation-privacy-on-the-ic/16560/174 "2025-02-05T11:58:26Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![franzstefan](https://avatars.discourse-cdn.com/v4/letter/f/ba8739/32.png) [@franzstefan](https://forum.dfinity.org/u/franzstefan)\
**Post date:** [February 5, 2025, 3:55pm UTC](https://forum.dfinity.org/t/threshold-key-derivation-privacy-on-the-ic/16560/175 "2025-02-05T15:55:03Z")

</div>

The vetKey APIs will only be callable by canisters. Last week, I also [adapted](https://github.com/dfinity/portal/pull/3763/commits/9c0178eae658dab77de1d69e68103eb305378207) the [IC spec PR](https://github.com/dfinity/portal/pull/3763) to explicitly mention this (“This method can only be called by canisters, i.e., it cannot be called by external users via ingress messages”).

---

<div class="post-metadata">

**Author:** ![kristofer](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/kristofer/32/11135_2.png) [@kristofer](https://forum.dfinity.org/u/kristofer)\
**Post date:** [February 11, 2025, 2:04pm UTC](https://forum.dfinity.org/t/threshold-key-derivation-privacy-on-the-ic/16560/176 "2025-02-11T14:04:50Z")

</div>

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

> **[GitHub - kristoferlund/send\_file\_to\_eth\_demo: ICP vetKeys demo: Send encrypted files to any...](https://github.com/kristoferlund/send_file_to_eth_demo)**
>
> ICP vetKeys demo: Send encrypted files to any Ethereum address

---

<div class="post-metadata">

**Author:** ![witter](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/witter/32/4571_2.png) [@witter](https://forum.dfinity.org/u/witter)\
**Post date:** [February 12, 2025, 12:28pm UTC](https://forum.dfinity.org/t/threshold-key-derivation-privacy-on-the-ic/16560/177 "2025-02-12T12:28:23Z")

</div>

looking forward vetkey

---

<div class="post-metadata">

**Author:** ![robert\_t](https://avatars.discourse-cdn.com/v4/letter/r/8c91f0/32.png) [@robert\_t](https://forum.dfinity.org/u/robert_t)\
**Post date:** [March 7, 2025, 11:49am UTC](https://forum.dfinity.org/t/threshold-key-derivation-privacy-on-the-ic/16560/178 "2025-03-07T11:49:19Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![kristofer](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/kristofer/32/11135_2.png) [@kristofer](https://forum.dfinity.org/u/kristofer)\
**Post date:** [March 19, 2025, 4:27pm UTC](https://forum.dfinity.org/t/threshold-key-derivation-privacy-on-the-ic/16560/179 "2025-03-19T16:27:17Z")

</div>

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**](https://github.com/dfinity/vetkd-devkit/blob/main/cdk/key_manager/README.md) – a library for deriving and managing encrypted cryptographic keys.
- [**EncryptedMaps**](https://github.com/dfinity/vetkd-devkit/blob/main/cdk/encrypted_maps/README.md) – 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**](https://github.com/dfinity/vetkd-devkit/blob/main/sdk/ic_vetkd_sdk_key_manager/README.md) – Facilitates interaction with a KeyManager-enabled canister
- [**EncryptedMaps**](https://github.com/dfinity/vetkd-devkit/blob/main/sdk/ic_vetkd_sdk_encrypted_maps/README.md) – Facilitates interaction with a EncryptedMaps-enabled canister
- [**SDK Utils**](https://github.com/dfinity/vetkd-devkit/blob/main/sdk/ic_vetkd_sdk_utils/README.md) – 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:

- [**Basic Password Manager**](https://github.com/dfinity/vetkd-devkit/blob/main/examples/password_manager/README.md) - A simpler example without metadata.
- [**Password Manager with Metadata**](https://github.com/dfinity/vetkd-devkit/blob/main/examples/password_manager_with_metadata/README.md) - Supports unencrypted metadata alongside encrypted passwords.

## **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**

👉 **Try out the examples** and explore the libraries.

👉 **Report issues or suggestions** in this thread.

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

Looking forward to your feedback! 🚀

> **[GitHub - dfinity/vetkeys: Libraries and examples for integrating verifiable...](https://github.com/dfinity/vetkeys)**
>
> Libraries and examples for integrating verifiable encrypted threshold keys (vetKeys) into Internet Computer applications

---

<div class="post-metadata">

**Author:** ![rbole](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/rbole/32/1334_2.png) [@rbole](https://forum.dfinity.org/u/rbole)\
**Post date:** [March 19, 2025, 8:25pm UTC](https://forum.dfinity.org/t/threshold-key-derivation-privacy-on-the-ic/16560/180 "2025-03-19T20:25:26Z")

</div>

Is there also a Motoko example available?

---

<div class="post-metadata">

**Author:** ![w3tester](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/w3tester/32/15045_2.png) [@w3tester](https://forum.dfinity.org/u/w3tester)\
**Post date:** [March 20, 2025, 2:33am UTC](https://forum.dfinity.org/t/threshold-key-derivation-privacy-on-the-ic/16560/181 "2025-03-20T02:33:02Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![timo](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/timo/32/5543_2.png) [@timo](https://forum.dfinity.org/u/timo)\
**Post date:** [March 20, 2025, 2:34am UTC](https://forum.dfinity.org/t/threshold-key-derivation-privacy-on-the-ic/16560/182 "2025-03-20T02:34:13Z")

</div>

Is the CDK really meant for canisters or is it actually a Rust SDK analogous to the other (js) SDK?

Asking because it contains get\_encrypted\_vetkey which you don’t want to call from a canister because you don’t want to handle secrets in a canister. Same applies to EncryptedMaps.

[Previous page](https://forum.dfinity.org/t/threshold-key-derivation-privacy-on-the-ic/16560.md?page=8)

[Next page](https://forum.dfinity.org/t/threshold-key-derivation-privacy-on-the-ic/16560.md?page=10)
