Threshold Key Derivation - Privacy on the IC

Node provider posts pseudonymously on this forum, asking innocently for help with technical issues, identifying himself as a node provider. Now anyone can contact him, just like it would be the case when node providers were publicly known.

Point is any node provider can be anonymous but doesn’t have to be. Any node provider can at any point make as much of his identity public as he chooses. Or make himself reachable. In other words anonymity of always optional. Hence, by definition, anonymity cannot provide any advantage against collusion.

Exactly. The threat is not honest node providers turning malicious after being contacted by some other malicious node provider. The threat is an attacker signing up as multiple node providers by using a bunch of strawman entities. And against threat non-anonymity is better. Because the more people can scrutinize the node provider applications the higher the chances to reveal the true identity behind them.

1 Like

As you know, @victorshoup explained Threshold FHE on IC in yesterday’s R&D meeting. Is Threshold FHE scheme independent from the way that Gregory explained, FHE using vetKD for bootstrap?


Hello! Good news! The paper is finally online if you are interested to really go into the details :partying_face:
If you have questions, want explainers about anything in particular, or any other comments, let us know.

Some replies to earlier messages…

Hard to say. The design and integration of a full implementation is still being discussed.
However, the Crypto team is working on a canister interface that will allow to experiment with a test implementation. This should be ready soon™…

I have not looked too much into the details of drand. On the conceptual level they are similar. The most notable difference is that drand key shares are not encrypted. Also on the network / usage level they will be different. How far did you get with reading both? Happy to fill in any gaps.

Yes, @victorshoup’s work with Zama is independent. Rather than ‘bootstrapping’ into FHE, they are pushing the boundaries of FHE to allow it to happen onchain in a much more practical way. Very cool stuff.


That’s why we use robust ZK identity providers to stop this.

We should seek to hide the network topology from the node operators, so that they don’t even know what subnet they are in. If they don’t know what subnet they are in currently, nor at any point in the future with node shuffling, it would become extremely difficult to collude with a small number of node operators in the same subnet.

watch and learn here :eyes:

1 Like