# Threshold Key Derivation - Privacy on the IC **URL:** \ **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:** 4
**Author:** ![mparikh](https://avatars.discourse-cdn.com/v4/letter/m/91b2a8/32.png) [@mparikh](https://forum.dfinity.org/u/mparikh)\ **Post date:** [March 30, 2023, 3:20pm UTC](https://forum.dfinity.org/t/threshold-key-derivation-privacy-on-the-ic/16560/62 "2023-03-30T15:20:25Z")
Thanks! A clarificatory question: When you refer to a **Node** in the **Syntax** section of [Internet Computer Loading](https://internetcomputer.org/docs/current/blog/features/vetkey-primer) , i believe you are referring to SmartCanisters and **not** Nodes (as in Nodes on Internet Computer). Did i get it right? ---
**Author:** ![free](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/free/32/615_2.png) [@free](https://forum.dfinity.org/u/free)\ **Post date:** [March 30, 2023, 3:34pm UTC](https://forum.dfinity.org/t/threshold-key-derivation-privacy-on-the-ic/16560/63 "2023-03-30T15:34:59Z")
No, these are actually nodes making up a subnet (similar to tECDSA). If it was canisters holding shares of the master key, it would be trivial to collect all these shares (by looking at the state of a single replica; or at least one replica per subnet, if said canisters were spread across multiple subnets) and reconstruct the master key. With nodes holding the shares, you’d need simultaneous control of a majority of the subnet’s nodes (similar to what you’d need to do to extract a subnet’s secret key). ---
**Author:** ![mparikh](https://avatars.discourse-cdn.com/v4/letter/m/91b2a8/32.png) [@mparikh](https://forum.dfinity.org/u/mparikh)\ **Post date:** [March 30, 2023, 6:30pm UTC](https://forum.dfinity.org/t/threshold-key-derivation-privacy-on-the-ic/16560/64 "2023-03-30T18:30:59Z")
cool. Trying to understand this statement : “Nodes can also combine encrypted shares to produce the full encrypted derived key ek using a Combine algorithm”. Because each Node participating in this protocol has it’s own master-secret-key-share (msks-i) and is passed in the full public transport key (tpk) along with the id ([i.e.bob@email.com](mailto:i.e.bob@email.com)) from bob, it can produce a derived encrypted key share (eki) representing a “shared” bob. A threshold set of ekis are required to produce a “complete” bob; provided that these ekis can be decrypted. Since only bob holds the private transport key (tsk) with which these ekis are encrypted, a node can gossip with other nodes and produce that combined threshold share (aka full derived keys) which are encrypted. This Combine function is therefore convenient because an actor (Bob) needs to interact with only one node; as opposed to threshold set of nodes. Did I get the above right? What happens if that node is a rogue node? ---
**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:** [March 30, 2023, 7:21pm UTC](https://forum.dfinity.org/t/threshold-key-derivation-privacy-on-the-ic/16560/65 "2023-03-30T19:21:29Z")
The talk was great!!! I’m making an assumption that it would be nice to have verified. The Dapp controls these access to the keys correctly? So if the smart contract says that Bob can decrypt Alice’s encryption then he gives Bob the key he needs. Is that correct? It seems like this adds another level of trust to this scheme and the canister code is going to have to get pretty serious about immutability or DAO horizoning. In other words, could an upgraded canister arbitrarily decide to start issuing decryption keys to everyone? ---
**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:** [March 30, 2023, 7:26pm UTC](https://forum.dfinity.org/t/threshold-key-derivation-privacy-on-the-ic/16560/66 "2023-03-30T19:26:36Z")
I believe that next to ETH integration(to capture the known degens), this is likely the most important feature for the IC. Encryption in a secure way needs to be solved to bring enterprise onto the IC. As mentioned in the talk this would open up numerous use cases for businesses in the “Shared Data Spaces” realm. At Origyn we need to encrypt certain product and user details that should only be accessible to authenticators, customers, or service providers who have been granted access. So certificates end up with a mix of open, transparent data and permissions, encrypted data. Keep up the good work and I can’t wait to see what you all come up with! ---
**Author:** ![lastmjs](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/lastmjs/32/3406_2.png) [@lastmjs](https://forum.dfinity.org/u/lastmjs)\ **Post date:** [March 30, 2023, 8:11pm UTC](https://forum.dfinity.org/t/threshold-key-derivation-privacy-on-the-ic/16560/67 "2023-03-30T20:11:06Z")
I just thought of a potential use case while on an airplane today. I was thinking about how a DAO or group could control an npm account and push new package versions to npm. The token could be verifiably encrypted, and a canister could decrypt the token just when necessary to do an http outcall to deploy a new version of a package. Though, the decrypted token would be available temporarily in the memory of the nodes right? Hopefully AMD-SEV or something similar gets deployed soon to help on that front. ---
**Author:** ![free](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/free/32/615_2.png) [@free](https://forum.dfinity.org/u/free)\ **Post date:** [March 30, 2023, 8:20pm UTC](https://forum.dfinity.org/t/threshold-key-derivation-privacy-on-the-ic/16560/68 "2023-03-30T20:20:09Z")
> [@mparikh](#): > > Did I get the above right? Exactly. > [@mparikh](#): > > What happens if that node is a rogue node? I don’t know much about the specifics of vetKD, but given that this is a subnet, the result would be the same as talking to a random malicious node on a random subnet: it could take arbitrarily long to respond, it could respond with garbage, but it wouldn’t be able to produce an invalid response with a valid subnet signature. So after either a timeout or an invalid response, you would query again for the status of your request and will likely hit an honest node. ---
**Author:** ![mparikh](https://avatars.discourse-cdn.com/v4/letter/m/91b2a8/32.png) [@mparikh](https://forum.dfinity.org/u/mparikh)\ **Post date:** [March 30, 2023, 9:06pm UTC](https://forum.dfinity.org/t/threshold-key-derivation-privacy-on-the-ic/16560/69 "2023-03-30T21:06:50Z")
> [@skilesare](#): > > In other words, could an upgraded canister arbitrarily decide to start issuing decryption keys to everyone? Assuming that Bob’s authentication to idbob passes through a dapp, the dapp could update itself to pass “true” to every authentication request. See below. > [@ais](#): > > Identity” can be considered quite fluid in this feature, it can be an arbitrary string, so it could be that authentication is not necessary. So yes your assertion is correct. Immutability / some kind of sensible implementation would be required. @free @ais Given that there’s one masterkey and assuming various different dapps that piggyback on the same arbitrary string (ie “[bob@email.com](mailto:bob@email.com)”), what is the mechanism of distinguishing different idbobs (one idbob per dapp)? ---
**Author:** ![mparikh](https://avatars.discourse-cdn.com/v4/letter/m/91b2a8/32.png) [@mparikh](https://forum.dfinity.org/u/mparikh)\ **Post date:** [March 30, 2023, 9:47pm UTC](https://forum.dfinity.org/t/threshold-key-derivation-privacy-on-the-ic/16560/70 "2023-03-30T21:47:03Z")
Indeed! More generally, this would solve “how to store a api-key securely to call private apis which require api-keys” on IC ; baring a small window of time where the dapp smart canister (hosted on nodes) would have the decrypted api-key (aka token) in RAM. ---
**Author:** ![free](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/free/32/615_2.png) [@free](https://forum.dfinity.org/u/free)\ **Post date:** [March 31, 2023, 6:48am UTC](https://forum.dfinity.org/t/threshold-key-derivation-privacy-on-the-ic/16560/71 "2023-03-31T06:48:29Z")
Disclaimer: I’m not a cryptographer, I’m a systems software engineer. My first run-in with cryptography beyond the basics of public key cryptography (I just had to look up the proper term for it) was when I joined DFINITY a few years back. I’m also not directly involved with vetKD. So take my answers with a grain of salt. > [@mparikh](#): > > Given that there’s one masterkey and assuming various different dapps that piggyback on the same arbitrary string (ie “[bob@email.com](mailto:bob@email.com)”), what is the mechanism of distinguishing different idbobs (one idbob per dapp)? I imagine one simple solution would be for the vetKD implementation to e.g. always prepend the canister ID (of the canister making the request) to the provided ID. That way, when Alice asks canister C to derive a public key for ID `"bob@email.com"`; or Bob asks canister C to derive the secret key for the same; they will actually be getting the public/secret key derived from `"|bob@email.com"`. So asking canister C for the public/secret key for `"bob@email.com"` would result in a different key pair than asking the same from a canister D. And the only way to get the former key pair would be to go through canister C. And canister C may enforce whatever rules it chooses to decide whether to allow or not a given principal to retrieve the secret key derived from `"bob@email.com"`. ---
**Author:** ![hokosugi](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/hokosugi/32/7499_2.png) [@hokosugi](https://forum.dfinity.org/u/hokosugi)\ **Post date:** [April 5, 2023, 12:00am UTC](https://forum.dfinity.org/t/threshold-key-derivation-privacy-on-the-ic/16560/72 "2023-04-05T00:00:57Z")
What is the difference between vetKD and [drand](https://github.com/drand/tlock)? Both use t-BLS signatures and IBE cryptography for encryption and decryption. Please tell us what exactly are the differences. ---
**Author:** ![rabbithole](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/rabbithole/32/8138_2.png) [@rabbithole](https://forum.dfinity.org/u/rabbithole)\ **Post date:** [April 8, 2023, 3:26pm UTC](https://forum.dfinity.org/t/threshold-key-derivation-privacy-on-the-ic/16560/73 "2023-04-08T15:26:33Z")
I need this functionality because this is the whole point of my application! I am working on encrypted file storage and I abandoned the idea of storing keys on the user side as soon as I learned about the possibility of using end-to-end encryption in the canister in the near future. At the moment, I just have a file storage until I again implement encryption support already on the side of the canister. I’m also inspired by the ability to decrypt data based on time, sharing files with someone in case of an accident. I would like to be able to work with this functionality in the near future, so please add +1 to the number of applications that really need it 🙂 ---
**Author:** ![dfisher](https://avatars.discourse-cdn.com/v4/letter/d/4da419/32.png) [@dfisher](https://forum.dfinity.org/u/dfisher)\ **Post date:** [April 9, 2023, 9:37pm UTC](https://forum.dfinity.org/t/threshold-key-derivation-privacy-on-the-ic/16560/74 "2023-04-09T21:37:43Z")
So maybe Q4 full implementation? ---
**Author:** ![lastmjs](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/lastmjs/32/3406_2.png) [@lastmjs](https://forum.dfinity.org/u/lastmjs)\ **Post date:** [April 16, 2023, 4:15am UTC](https://forum.dfinity.org/t/threshold-key-derivation-privacy-on-the-ic/16560/75 "2023-04-16T04:15:53Z")
I’ve thought of another use case, this time for the Internet Computer itself. I’ve written a tweet thread and I’ll open a forum post if initial feedback is good: [https://twitter.com/lastmjs/status/1647448096744550403](https://twitter.com/lastmjs/status/1647448096744550403) The idea is to use ZK proofs to vet node operators, and then use VetKD to encrypt their KYC/B information, store it in the NNS subnet, and allow decrypting it only with an NNS proposal. This would allow almost anonymous node operators while allowing deterministic decentralization, legal compliance, and legal or reputational courses of action if node operators misbehave. I truly believe, if I haven’t made some grave mistake in understanding, that this is a solution to one of the biggest attack vectors of the IC, that being collusion between node operators in static subnets. ---
**Author:** ![Sormarler](https://avatars.discourse-cdn.com/v4/letter/s/c57346/32.png) [@Sormarler](https://forum.dfinity.org/u/Sormarler)\ **Post date:** [April 16, 2023, 6:38am UTC](https://forum.dfinity.org/t/threshold-key-derivation-privacy-on-the-ic/16560/76 "2023-04-16T06:38:38Z")
I really think this is a win-win situation for both the internet computer and node operators. ---
**Author:** ![hokosugi](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/hokosugi/32/7499_2.png) [@hokosugi](https://forum.dfinity.org/u/hokosugi)\ **Post date:** [April 16, 2023, 6:58am UTC](https://forum.dfinity.org/t/threshold-key-derivation-privacy-on-the-ic/16560/77 "2023-04-16T06:58:24Z")
Who determines the authenticity of the initial KYC data that the node provider registers, Dfinity? If the prover is the node provider himself, I don’t think we would know if the KYC is true or not. ---
**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:** [April 16, 2023, 7:45am UTC](https://forum.dfinity.org/t/threshold-key-derivation-privacy-on-the-ic/16560/78 "2023-04-16T07:45:06Z")
> [@lastmjs](#): > > this is a solution to one of the biggest attack vectors of the IC, that being collusion between node operators in static subnets I understand the goal of allowing node operators to stay anonymous as much as possible, as a goal in itself. But it does not change anything regarding their ability to collude. Those who want to collude will find each other no matter what. Or do you mean they would be harder to attack by an attacker whose goal is to hack multiple and then „make“ them collude? ---
**Author:** ![lastmjs](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/lastmjs/32/3406_2.png) [@lastmjs](https://forum.dfinity.org/u/lastmjs)\ **Post date:** [April 17, 2023, 10:57am UTC](https://forum.dfinity.org/t/threshold-key-derivation-privacy-on-the-ic/16560/79 "2023-04-17T10:57:28Z")
This would make it much harder for node providers to collude wouldn’t it? Right now they have free and open access to each other’s contact information more or less. With this solution I’m hoping it would be much harder for them to find each other, especially once we have node rotation/shuffling. ---
**Author:** ![JaMarco](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/jamarco/32/7629_2.png) [@JaMarco](https://forum.dfinity.org/u/JaMarco)\ **Post date:** [April 17, 2023, 2:46pm UTC](https://forum.dfinity.org/t/threshold-key-derivation-privacy-on-the-ic/16560/80 "2023-04-17T14:46:21Z")
> [@timo](#): > > Those who want to collude will find each other no matter what. What do you mean by that, how would anonymous node operators find each other secretly? ---
**Author:** ![Vivienne](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/vivienne/32/29170_2.png) [@Vivienne](https://forum.dfinity.org/u/Vivienne)\ **Post date:** [April 17, 2023, 3:44pm UTC](https://forum.dfinity.org/t/threshold-key-derivation-privacy-on-the-ic/16560/81 "2023-04-17T15:44:28Z")
Maybe by being the same node operator with multiple identities [Previous page](https://forum.dfinity.org/t/threshold-key-derivation-privacy-on-the-ic/16560.md?page=3) [Next page](https://forum.dfinity.org/t/threshold-key-derivation-privacy-on-the-ic/16560.md?page=5)