Can threshold ECDSA be used to encrypt canister data?
(Ignoring concerns around potential node provider collusion, etc. for now)
3 Likes
No, it can only be used to sign data.
1 Like
Threshold encryption is now on the roadmap, under Upcoming: Roadmap
“Enable threshold encryption on the IC by allowing canisters to call a threshold decryption interface. The interface would enable canisters or individual users to encrypt messages under the public key of the subnet, and decrypt the ciphertexts under the corresponding decryption key that is secret-shared among the replicas. Threshold encryption will enable canisters to store end-to-end encrypted user data (e.g., storage, messaging, social networks) without having to rely on browser storage for user-side secrets, as well as enabling transaction privacy within canisters (e.g., closed-bid auctions, front-running prevention).”
10 Likes
@skilesare, @lastmjs, & @domwoe,
I could really use your help with this regarding ntagle.
The entire usage of ntagle rests on being able to securely store symmetric encryption keys.
Users will need to login, so I can have them sign messages before sending them to the canister.
What I need to know is:
-
If the secrets are plaintext while the logic is actively running internally within the canister, would this still basically be public and viewable by a bad node provider? If so this really means nothing about data can be secret with the network, which is hugely disappointing.
-
Could I use the ECDSA feature to encrypt keys with the public key before storing them to state, then then decrypt the keys when needed for the authentication logic? I assume only the canister can call the usage of the secret key? Would I be able to safely store any data I’d need for generating these calls to the ECDSA functions (like, could a node provider replicate my canister’s ECDSA calls and get back the original data)?
-
@skilesare basically said inter-canister calls can all be revealed from the logs. I guess this includes the ECDSA calls too?
@domwoe when we talked you mentioned there may be some advantage to splitting up sensitive data across multiple subnets. Do you think this is the best approach to pursue? If so, how could I help make the necessary inter-canister calls secure?
3 Likes
Are you asking about signing or encrypting? These are two distinct cryptographic operations, and you might be conflating the two. I assume you’re most interested in encrypting data.
- The safest assumption is that any data you store in a canister is viewable by the node provider. The nodes seem pretty locked down from what I’ve learned, but a motivated node provider I believe would be able to get all data stored in all canisters on its subnet. This is hugely disappointing. But, you can client-side encrypt data before sending it to the IC. This would help because node operators wouldn’t have the decryption keys. But the problem is, where would the user store these keys? It’s a hard UX problem. That’s where threshold encryption comes into place. I think it might be exactly what you’re looking for. This allows you to store the encryption/decryption key on the IC distributed across multiple nodes. A user can then request the key, I assume based on regular IC authentication, and encrypt and decrypt data on their own devices.
- ECDSA is only for signing data, not for encrypting or decrypting data.
- I don’t know about this
2 Likes
Thanks for this! Who would have thought to look at the roadmap 
Should I be concerned that it is all blacked out?
@domwoe This might mean it was in planning but no longer?
I am thinking of ways to onboard companies to certain features in the IC. Privacy is always a rebuttal for data storage; and we need to be able to tell the truth about current state.
It is in the process of launching.
That one is a different feature
1 Like
Looks like it is being explored, but I’d imagine threshold encryption is a way off. I have some ICDevs bounties that need it. They are in the freezer for now.
2 Likes
Do your tags have an encryption feature or just a signing feature? If the tag can sign then the tag probably has an enclave.
What you want is an enclave in the dfinity nodes. We don’t have those yet, but research is being done.
Signing should be enough in your tag to prove the presence of the tag. The signing algo likely reports a public key which isn’t secret and sends a signature of a payload back(random number, time stamp) that only having the private key would possibly be able to produce.
1 Like
The tags generate unique URLs with a CMAC parameter based on the scan count using AES-128.
Unfortunately, since it’s all symmetric encryption this typically means the Secure Dynamic Messaging server (in this case an SDM canister) must hold the secret keys for each tag.
One option would be for the encoder to generate a huge list of valid CMAC messages (perhaps the first 100,000 scans), hash the values, and then upload that data to the canister. We don’t have a CMAC library for Motoko yet, so that’s already similar to what I’m currently doing.
The transfer code will change between each tag owner (it’s a random string encoded statically to the tag in plaintext by the current owner when they "unlock"the tag for transfer), so even the original encoder won’t have all the necessary information to transfer ownership of the digital assets associated with the tag.
For the transfer code, I’m going to need a creative solution to make sure that information is stored, transmitted, and validated securely.
1 Like
I’m not enough of a crypto expert to know if this is viable, but nu-cypher has some tech that lets a node re-encrypt without knowing the actual code and a few other multi party compute schemes. I’d love to see if any of these could be put inside of canisters to create a multi canister encryption scheme. It would be “slow” but might dove some problems.
3 Likes
Interesting parts → rust-umbral/umbral-pre-wasm at master · nucypher/rust-umbral · GitHub
GitHub - nucypher/rust-umbral: Umbral implementation in Rust
It seems that Alice would need to use her secret key and Bob’s public key to generate the re-Encryption for the capsule… 
jargon aside - a canister would need to store a secret key to do this.
1 Like
Yes, but if someone gets that key, the worst they can do is encrypt encrypted data.(I think…I may be misinterpreting this).
Where this gets i is, I think, other libraries they have involve some basic multiparty compute. So you can apply basic logic without having to see the data. I saw a demo one…it was like 3 years ago. Looked like cool tech.
Just looking at the code - they need the original private key for round #2.
Bob is the only person who does not need it. Translation: our middle-man canister proxies would need it.
i.e. Node provider gets the key used in 1 and in 2 so they can undo the whole thread back to original text.
1 Like
Anyone know people at Dmail?
‘VRF (measurable random function) + BLS (non-interactive threshold signature) + Container.’
https://dmail.ai/Dmail_litepaper.pdf look in Distributed storage.
Or Dmail Network: Decentralized EMail for the Web 3 Generation in DMAIL Message.
They were thinking about using a token to do this.
1 Like
Hey! This was a little easter egg that I placed on the roadmap - there was a way to ‘decrypt’ if you somehow collaborated with the page, but indeed it looked confusing. I made the text ‘normal’ now, so you can read. This is a feature currently in discussion - will start a forum thread in the coming days 
6 Likes
I copy and pasted it to read it. What was the desired way to decrypt?
Also - super excited for this feature as it is a major blocker to b2b coming to the IC with $$ for devs.
2 Likes
This is great to hear! we are super interested to know what have been the main blockers to could be solved with this, so keep them coming. Looking forward to kicking off the discussion!
3 Likes
Sharing for visibility 
9 Likes