I think that’s at least a possibility. That’s why it’s better to not rely on any current implementation details.
A question out of curiosity: Is there any application where it is desirable to be able to derive a canister’s public key without asking the canister? It is not something that you can do in the “real” world. You can ask your friends for their public keys in person but you cannot detect if they gave you someone else’s public key or if they share the private key with someone else. No matter what you use (PKI, identity based encryption, etc.) can change that. Still nobody has a problem with that. So why the need with canisters?
Well, we have that property for Bitcoin addresses for example - I can send you a signature and you can check that it belongs to the owner of a Bitcoin address.
If you first have to ask the canister, you have to either use update calls (expensive, canister may not want to pay for it) or a query call with certified variables (non-trivial to implement).
But no, I don’t have anything concrete in mind.
BTW, I wonder if the Internet Identity would have used this instead of our slightly odd “Canister Signatures” if we had had it back than? Even if we did, we can’t get rid of them now (at least until the next major crash of this beta network ;-)). But it might be an interesting question to think about for those who implement similar services.
He meant salt, not seed. A salt used in the derivation of per-dapp principals so that your identity anchor can’t be traced across different dapps. If you are thinking of the recovery phrases then of course they are not stored anywhere. They are created client side, never leave your device and are not stored on your device either.
One reason for not wanting to publish the master public key was indeed the fact that this would in some way require the concrete implementation of having a single master key and deriving each canister “root key” from this. We thought it to be a cleaner API to allow everyone to just query canister root public keys.
The ic0 system API will be such that any canister can query any canister’s root public key. This is more general than originally envisioned as we resolved some underlying architecture challenges of making this work in the most general deployment of having any number of ECDSA master keys on any number of subnets for different ECDSA curves. We won’t have this general deployment, at least initially.
We did not see any application either that would be prevented by this approach. So the canister whose public key you want to obtain need not be involved in any other canister getting the key, so does not incur any cost in this case. But that’s more the special case. If public keys should be given to end users, this, of course, means the canister incurs some cost for this. A query with a certified variable for this is cheap, but you have to go through the complexity of implementing it as you mention somewhere. The canister offering its keys (or derived Bitcoin addresses) as part of its API will definitely be an important key distribution scenario for many applications, e.g., a DEX giving every user their own Bitcoin address to transfer funds to.
As @timo mentions, this is definitely a possibility for the future. We have concluded the design of the mechanisms for the rollout now. In summary, there will initially be one ECDSA signing subnet and one for key backup (the NNS). The architecture incl. NNS proposals and Registry records are all kept sufficiently general to support the most generalized way of deploying threshold ECDSA: An arbitrary number of ECDSA master keys, multiple ECDSA curves, the keys sitting on an arbitrary number of subnets, multiple keys per subnet, and subnets being either signing subnets or only key-holding subnets for key backup purposes. Note that not all aspects of the implementation support this generality now, but the API does.
I plan to post more details on the rollout decisions and system integration design when there is some time for that. There will probably also be a Community Conversation in the near future on this topic: Threshold ECDSA signatures: System integration.
For threshold ECDSA, we have been working intensively on the design of the system integration in the recent weeks. This has been split off as a separate feature from the main feature IC-316 “Threshold ECDSA signatures.” The new system integration feature is IC-733 “Threshold ECDSA signatures: System integration.” It deals with the following questions which are crucial for system integration and deployment of the feature:
Rollout: How do we roll out threshold ECDSA to the Internet Computer mainnet?
Key generation: How do subnets get a threshold ECDSA key?
Deployment: How many and which subnets will support threshold ECDSA keys? How many threshold ECDSA keys do we have?
Subnet recovery: How can we do subnet recovery for subnets that support ECDSA?
Pricing: How many cycles do we charge for a sign_with_ECDSA ic0 system call?
We have answered all these questions and have a design ready, implementation of which has already started in parallel to the work on the main feature. I’ll post details on the design in a future post soon to share key results on how we intend to move forward in this area.
Threshold ECDSA signatrures progress update
The crypto and consensus teams are still working intensively on the main IC-316 feature to complete the implementation of the threshold ECDSA signing protocol.
But, admittedly, this powerful API for public key retrieval has only been possible to be decided on very recently, once we had a clear view of how we could implement it also in the most general deployment scenarios (arbitrarily many master keys on many subnets, any canister being able to use any of the keys etc.). The earlier thinking was that a canister could only query its own public key for exactly the reasons of reasonable implementability of the API in the most general settings we could envision. But that’s resolved now for the very general, powerful, API.
We have made lots of progress both with the core threshold ECDSA signing feature as well as the system integration of threshold ECDSA.
Core feature: We are about to finalize the implementation of complaints handling, which is the last big open item for the signing protocol.
System integration: Work has progressed well for the efforts related to the NNS proposals required to create ECDSA master keys, reshare keys, and activate signing for a threshold ECDSA subnet. Some areas where we still have work items open are the following: Key resharing protocol to reshare an ECDSA master key from one subnet to another subnet, tweaks to the management canister API for threshold ECDSA, XNet message routing for ECDSA-related messages, as well as provisioning 34 nodes for a large threshold ECDSA subnet.
Testing / QA: Once we complete the implementation, we have a substantial testing effort as well as internal and external code reviews ahead of us.
Implementation of complaints handling, the last major open part for the core signing feature, has been finished. The core threshold ECDSA feature is now working in an end-to-end manner. @rsubramaniyam and @Manu have demonstrated the feature in last week’s DFINITY Global R&D meeting.
Now we are focussing on getting all the remaining parts of the feature done. See my post above for major items this comprises – system integration and specifically Xnet re-sharing require still quite an effort until completion. An effort on writing a system testing suite has been started in parallel. More updates to follow.
The engineering team is still working on the implementation of this feature on multiple fronts: The cryptographic primitives are essentially finished, but there is still an effort required for finalizing the integration of crypto with consensus, e.g., for the X-Net re-sharing of a threshold ECDSA key, as well as some other parts of system integration. For example, the functionality related to the NNS proposals for key management (particularly Xnet re-sharing) still requires some more work to get finalized. A pretty small remaining item will be the integration with DFX which is essentially enabling the feature and generating / loading a key when DFX starts up a replica. Depending on performance measurements, we will need to give performance some attention, but that is currently open.
Another important task coming up is the security review of the consensus-related parts of the code through an external company. This will be started shortly and will help us increase our assurance on the code. We are planning to publish the resulting audit report once the findings have been addressed to share the gained insights with our community.
On the front of the closely-related Bitcoin feature, we have made great progress and will soon be able to run a first beta deployment on an IC subnet (Direct Integration with Bitcoin - #263 by dieter.sommer). So, the puzzle pieces are (slowly) coming together finally to enable a trustless Bitcoin integration unheard of so far on any blockchain!
For those, who have not see this yet: @victorshoup and @JensGroth of the DFINITY Foundation have published their threshold ECDSA work which is the foundation for our threshold ECDSA implementation. You can have a look at the paper uploaded to eprint at the below URL.
Design and analysis of a distributed ECDSA signing service Jens Groth and Victor Shoup DFINITY
The implementation has further progressed and we think that this or next week we may be ready for a first deployment of the feature on an IC subnet. This deployment will likely not contain the Xnet re-sharing yet, but the core signing algorithm. The purpose of this first deployment is to observe the behaviour of the feature on mainnet and to get operational experience with it before we will release the feature on the NNS and a large dedicated threshold ECDSA subnet.
As of last week, the major open issues to be implemented for a first deployment have been the following:
Payload validation to be finished. This is a prerequisite for the protocol to be secure and we won’t release on mainnet even for any form of testing purposes before this has been done.
Fixing some issues with Xnet communication for signing requests. Currently, Xnet routing of signing requests and responses still has some glitches.
A further major item that we do not necessarily need for a first deployment, but that is crucial for the overall feature is the following:
Xnet re-sharing requires to be end-to-end tested and validated. The protocol itself is implemented (crypto and consensus), but we have not been able to end-to-end validate its correctness.
There are multiple further items that still need to be done, but we are slowly getting there.
As promised long time ago, I wanted to give you an overview of the system integration of threshold ECDSA and particularly how we intend to deploy the feature.
New and Updated NNS Proposals for Managing Threshold ECDSA Keys
We needed to define or extend multiple NNS proposals to realize the threshold ECDSA key management functionality required for the intended deployment scenarios.
do_update_subnet: Updated proposal that allows for defining that a specific subnet should generate a new threshold ECDSA key with a given key id.
create_subnet: Updated proposal that allows for creating a new subnet with a threshold ECDSA key being re-shared from a specified subnet (actually, multiple keys from different subnets could be re-shared to this subnet in the future, the proposal is already generalized to such scenarios). Re-sharing works by the key source subnet computing initial threshold ECDSA dealings encrypted towards the replicas of the target subnet (Phase 1 of the cryptograpihc re-sharing protocol), which are then stored in the CUP for the to-be-created subnet in the Registry. This is all orchestrated by the NNS canisters when executing the create_subnet proposal. Once the new subnet bootstraps, its replicas pick up the initial dealings from the Registry and compute their threshold ECDSA key shares from those initial dealings (Phase 2 of the cryptographic re-sharing protocol).
update_ecdsa_signing_subnets: New proposal for enabling / disabling the signing functionality for a subnet for a key id.
set_recovery_cup: New proposal for setting the recovery cup with the initial threshold ECDSA dealings of the intended key from the given subnet.
A proposal for deleting a given threshold ECDSA key from a subnet.
Note that key ids are pairs comprising the cryptographic group (as variant) and a key identifier (as byte array). Example: (secp256k1, prod_key_1)
Deployment Architecture
Our intended deployment architecture is as follows:
We initially want one production threshold ECDSA key (and probably a test key, however, this discussion is about the production key) replicated on two subnets for reasons of key availability.
The NNS will hold the production threshold ECDSA key passively, i.e., the NNS will not accept signing requests with this key.
A new 34-node subnet will hold the same production threshold ECDSA key and accept signing requests.
Provisioning Flow
Provisioning flow with abstract API calls (the used key name is an example and not defined yet):
Computes ECDSA dealings for nodes X, Y, Z, ... from the existing key (secp256k1, prod_key_1) and stores them in the Registry as part of the genesis CUP (Catch Up Package) for the new subnet to be created, then creates a new 34-node subnet with nodes X, Y, Z, ..., the nodes of which pull the ECDSA dealings from the Registry and finalize the re-sharing protocol to obtain the threshold ECDSA key (secp256k1, prod_key_1) in secret-shared form.
update_ecdsa_signing_subnets(A, true, key_id_1)
Enables the new 34-node subnet to accept signing requests for the key (secp256k1, prod_key_1).
In case one of the subnets holding the threshold ECDSA key (secp256k1, prod_key_1) is destroyed such the key cannot be reconstructed from the available shares any more and thus needs recovery, we use the set_recovery_cup proposal to create a recovery CUP (Catch Up Package) with ECDSA dealings of the key from which the key shares are computed.
Further Notes
Currently, each subnet can hold a single threshold ECDSA key, future extensions may lift this constraint, e.g., once we need a key in another group or would want multiple keys in the same group. The further may happen sooner than later in order to be able to realize a decentralized CA, which would require one of the secp256r1 groups.
There will be a talk on May 24th in which we will present more details about this topic.
See the attached figure for an overview of the rollout and related key management process.
It provides a mock implementation to allow deployment both locally and on IC. You can simply change the canister id back to aaaaa-aa after this feature is rolled out on main net.
