# Can \`sign\_with\_ecdsa\` be forged? **URL:** \ **Category:** Developers\ **Created:** [May 13, 2024, 3:12am UTC](https://forum.dfinity.org/t/can-sign-with-ecdsa-be-forged/30679 "2024-05-13T03:12:27Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![qwertytrewq](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/qwertytrewq/32/10423_2.png) [@qwertytrewq](https://forum.dfinity.org/u/qwertytrewq)\ **Post date:** [May 13, 2024, 3:12am UTC](https://forum.dfinity.org/t/can-sign-with-ecdsa-be-forged/30679/1 "2024-05-13T03:12:27Z")
Can a hacked canister hardware secretely call `sign_with_ecdsa` (and receive a valid signature for the hacker’s provided data) _without_ the user instructing it to call `sign_with_ecdsa`? This is important for [A proxy "joining" multiple HTTP requests into one - #18 by qwertytrewq](https://forum.dfinity.org/t/a-proxy-joining-multiple-http-requests-into-one/30541/18) algorithm. That algorithm had a security “leak” (need to check canister behavior post-factum to punish it, rather than preventing to) while using vetKeys. I simplified the algorithm to use tECDSA instead of vetKeys. After this the question arises, whether the simplification also removed this “security leak”. ---
**Author:** ![tkachenko](https://avatars.discourse-cdn.com/v4/letter/t/bcef8e/32.png) [@tkachenko](https://forum.dfinity.org/u/tkachenko)\ **Post date:** [May 13, 2024, 11:53am UTC](https://forum.dfinity.org/t/can-sign-with-ecdsa-be-forged/30679/2 "2024-05-13T11:53:40Z")
I believe this question is already [answered](https://forum.dfinity.org/t/a-proxy-joining-multiple-http-requests-into-one/30541/22) in your linked thread, i.e. one corrupted node can’t forge tECDSA signatures or do unauthorized requests. Quoting the [developer docs](https://internetcomputer.org/docs/current/developer-docs/smart-contracts/encryption/t-ecdsa): > The Internet Computer implements a novel threshold ECDSA protocol as part of its chain-key signatures suite. In this protocol, the private ECDSA key exists only as secret shares held by nodes. Secret shares are shards of the ECDSA private key. Signatures are computed using those secret shares without the private key ever being reconstructed. Each replica of such subnet holds a key share that provides no information on its own. More than one third of the nodes are required to generate a threshold signature using their respective key shares. ---
**Author:** ![andrea](https://avatars.discourse-cdn.com/v4/letter/a/c37758/32.png) [@andrea](https://forum.dfinity.org/u/andrea)\ **Post date:** [May 14, 2024, 8:43am UTC](https://forum.dfinity.org/t/can-sign-with-ecdsa-be-forged/30679/3 "2024-05-14T08:43:53Z")
> [@qwertytrewq](#): > > Can a hacked canister hardware secretely call `sign_with_ecdsa` Hi @qwertytrewq I tried to follow the original thread but I have to admit I am a bit confused. Canisters are SW installed on all the nodes of a subnet. The execution of the canister is replicated on all the nodes of the subnet and what the canister executes is agreed upon using a consensus protocol. This allows them also to agree on the result of the execution of the canister. Some observations: - What do you mean by hacked hardware? If by HW you mean a single node of the subnet (up to less than a third of the nodes) is hacked/corrupt, then they cannot privately compute a signature between themselves. Signatures are computed using a threshold protocol, so you would need to corrupt more than a third of the node to compute signatures. - Canisters cannot compute anything privately, not even with vetKeys. Everything they compute is replicated on all the nodes of the subnet, and the inputs are agreed (and thus visible) to all the nodes. - `sign_with_ecdsa` is a system API offered to canisters, not to users. So every canister can call this API with arbitrary arguments, according to its source code and the inputs they may receive from external users or other canister. You could say that it is the canister that controls the signing key (although they cannot access it). > That algorithm had a security “leak” while using vetKeys. Can you expand on this security leak? The confidentiality brought by vetkeys comes from additional encryption keys specified by the users and a new threshold protocol run by the nodes of the subnet. However, vetkeys is also a system API offered to canisters, not users. So the trust assumptions between users and canisters are essentially the same for both functionalities. ---
**Author:** ![qwertytrewq](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/qwertytrewq/32/10423_2.png) [@qwertytrewq](https://forum.dfinity.org/u/qwertytrewq)\ **Post date:** [May 14, 2024, 8:51am UTC](https://forum.dfinity.org/t/can-sign-with-ecdsa-be-forged/30679/4 "2024-05-14T08:51:56Z")
> [@andrea](#): > > - What do you mean by hacked hardware? If by HW you mean a single node of the subnet (up to less than a third of the nodes) is hacked/corrupt, then they cannot privately compute a signature between themselves. Signatures are computed using a threshold protocol, so you would need to corrupt more than a third of the node to compute signatures. Yes, I mean this. > [@andrea](#): > > > That algorithm had a security “leak” while using vetKeys. > > Can you expand on this security leak? The confidentiality brought by vetkeys comes from additional encryption keys specified by the users and a new threshold protocol run by the nodes of the subnet. However, vetkeys is also a system API offered to canisters, not users. So the trust assumptions between users and canisters are essentially the same for both functionalities. I mean that a vetKey SK that a replica retrieved can be used by a hacked replica again, without the allowance of the owner of the canister. I provided a [bug report](https://github.com/dfinity/interface-spec/pull/158#issuecomment-2106573927) on this ---
**Author:** ![andrea](https://avatars.discourse-cdn.com/v4/letter/a/c37758/32.png) [@andrea](https://forum.dfinity.org/u/andrea)\ **Post date:** [May 14, 2024, 5:15pm UTC](https://forum.dfinity.org/t/can-sign-with-ecdsa-be-forged/30679/5 "2024-05-14T17:15:45Z")
> [@qwertytrewq](#): > > I mean that a vetKey SK that a replica retrieved can be used by a hacked replica again, without the allowance of the owner of the canister. I think there may be a misunderstanding on what the vetKeys functionality actually provide. The state of a canister should **not** be considered private, as node providers can have access to it. This is true also if vetKeys are used. What vetKeys enables is a way for users interacting with a canister they trust (and possibly control) to deterministically derive keys that can be both decrypted and used off-chain. There are use cases where it does make sense to have a canister perform some secret key operations, like decrypting messages. Time-lock encryption is one such example enabled by vetKeys. However, once the canister has used the private key to perform some decryption, both key and message should be no longer considered confidential. To summarise, this is not a bug of vetKeys, the example you list is just a use case not enabled by this functionality. ---
**Author:** ![qwertytrewq](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/qwertytrewq/32/10423_2.png) [@qwertytrewq](https://forum.dfinity.org/u/qwertytrewq)\ **Post date:** [May 15, 2024, 10:36am UTC](https://forum.dfinity.org/t/can-sign-with-ecdsa-be-forged/30679/6 "2024-05-15T10:36:18Z")
> [@andrea](#): > > However, once the canister has used the private key to perform some decryption, both key and message should be no longer considered confidential. Yes, it is now so. But I propose to make it false: Add encryption/decryption methods (that don’t expose the SK) to the API and remove the method that exposes SK. I reported it at the MR of vetKeys, so knowledgeable people will take my opinion into account.