As there have been some discussions going in this thread related to security (protocol review, testing, QA in general etc.), let me point out to you this new discussion thread that may be of interest, at least to some of you: Security Sandboxing (Community Consideration)
With this thread, we have just started a community discussion on security sandboxing. It would be great if those of you interested in the topic would join the discussion there.
As security has had so much resonance in the ECDSA, Bitcoin, and other feature discussions, we would like to follow an approach of having a community discussion as a first step of the whole process in order to get your requirements and thoughts on security sandboxing.
Congratulations @diegop ! Sorry 1 silly question: I read this article recently regarding Taproot upgrade for the Bitcoin network due in November where it will change its crptographical method from ECDSA to Schnorr. Iâm wondering how this change will affect the integration work that is being done by Dfinity at this stage. Thanks.
Thanks @diegop ~ much appreciated and excellent post by Manu!
Not sure if I missed his comments but I cannot seem to find Manuâs comments about the IC planning to implement Schnorr in line with how BTC is switching to Schnorr (and discarding use of ECDSA unless I am completely wrong on this one). In this regard, I would presume Dfinity is on top of this and as long as the ICâs implementation of ECDSA works fine with BTC (once Schnorr is turned on) then this is probably a non-issue (and my sincere apologies for unnecessarily bringing this issue up).
Not sure if I missed his comments but I cannot seem to find Manuâs comments about the IC planning to implement Schnorr in line with how BTC is switching to Schnorr (and discarding use of ECDSA unless I am completely wrong on this one). In this regard, I would presume Dfinity is on top of this and as long as the ICâs implementation of ECDSA works fine with BTC (once Schnorr is turned on) then this is probably a non-issue (and my sincere apologies for unnecessarily bringing this issue up).
Thatâs a very good question. I think the article you linked above makes it seem like Schnorr will completely replace ECDSA, and there will be no ECDSA in bitcoin anymore after taproot. This is not the case, addresses currently protected by ECDSA signatures will continue to work as before. Schnorr is just a new option that will additionally be supported. Does that answer your question?
Yes ~ perfect thanks @Manu ~ much appreciated. Sorry but I must have misinterpreted the articles I have read so far which make it seem like Schnorr is going to replace ECDSA when I guess it is in addition to ECDSA. All good!
Just in case anyone here is interested. Jens Groth and I released a paper on the security of several variations of ECDSA, which is available as Cryptology ePrint Archive: Report 2021/1330. While this paper is not specifically on threshold ECDSA. In fact, variations considered are directly motivated by our current design for threshold ECDSA, and the analysis in this paper form the theoretical foundations for the security of our threshold protocol.
Hereâs an update on our progress w.r.t. the implementation efforts for the threshold ECDSA feature.
We have implemented a good part of the âfoundationâ for the feature such as data types, the artifact pool for t-ECDSA artifacts, creating and validating dealings etc., so far all with mock crypto. Some cryptographic primitives have been implemented in parallel, but not yet integrated with consensus so far.
The next big milestone is to get the integration between consensus and crypto for the 4-tuple generation working by around November 20. This is the core part of the protocol and a pretty complex part for consensus. We plan to get this done with some substantial âshortcutsâ to get this core part of the feature working end to end. The shortcuts comprise, for example, skipping encryption, zero-knowledge proofs, and complaints. Once we are there, we will implement the functionality we have shortcut in the first iteration and remove the shortcuts one after the other. This agile way of addressing this pretty challenging implementation is the most efficient path towards a fully-working protocol implementation.
We will keep you posted on implementation progress more regularly in the future!
Let me close the week with some information on the timeline of the threshold ECDSA feature:
After setting our next milestone as mentioned in my earlier post this week, we realized that it is highly likely that the feature will only be final next year. It is hard to give a good estimate right now when in Q1 we would be able to release. This will become clearer when more of the implementation will be available. We will keep you posted on this and the implementation progress!
But now letâs get to some great news: We had our first âBitcoin Community Developer Workshopâ yesterday with key folks from DFINITY working on the threshold ECDSA and Bitcoin features and quite a notable number of our dear forum participants. See Direct Integration with Bitcoin - #101 by dieter.sommer for some of the main outcomes of this workshop. Minutes to follow!
I havenât thought to ask this yet, but what about ECDSA threshold encryption? Will this be possible?
Iâm thinking about possible implications for social recovery, proxy reencryption perhaps, stuff like that. It could be useful to encrypt data from within a canister
It looks like ECDSA stands for âElliptic Curve Digital Signature Algorithmâ, so it probably only does signatures
Yes, indeed, this feature will âonlyâ do threshold ECDSA signatures.
Threshold decryption could be implemented as well using multi-party computation algorithms, but this would be a different feature. That is, the private key (decryption key) would be held in a secret-shared manner by all the replicas in the subnet and replicas could jointly decrypt a ciphertext. Do you have concrete use cases where this would be useful?
We have been looking at threshold decryption for backing up threshold ECDSA keys at some point in time.
: 
