You still need to order the messages right? How would you be able to get rid of most of the consensus protocol?
1 Like
In my experience, enclaves are generally âgood enoughâ for most enterprises applications. They demonstrate a clear commitment to security and a best effort attempt to protect users.This is usually enough to meet regulatory and contractual standards(whether that should be the case is another discussion). If we want to open the IC up to enterprise SEV is probably our best option at the moment.
3 Likes
Wonder why I canât include links in my post 
I found a paper posted on Twitter in response to this thread here. They propose a protocol named D-KODE to solve the problem of producing a âPublic key of an offline Bobâ (quote p4, Begin of section âScenario 2â).
How is the vetKD proposed here related to D-KODE? If not related, is there a paper where I can read up on the math and implementation specifics behind vetKD?
If such a system distributed n key shares to n IC nodes, is it a possible scenario that an attacker gains access (i.e. read capabilities) to t key shares and therefore is able to reconstruct the secret?
2 Likes
This is the paper:
Authors: Easwar Vivek Mangipudi and Aniket Kate
Title: D-KODE: Mechanism to Generate and Maintain a Billion Keys
Published: Cryptology ePrint Archive, Paper 2022/161
3 Likes
Hi @benjmanable!
(apologies for the delayed reply, I missed this with various holidays.)
The D-KODE motivation is indeed related to ours but the proposed solutions are quite different (namely that we will take a simpler pairing-based approach, while they take a heavier lattice-based approach).
There is no paper yet as weâre still pinning down the details, but it is in progress. Have no doubt that I will post here when we have something publicly digestible 
Re an attacker gaining access to t shares â generally we (and all blockchains) work under the assumption that an attacker wonât get access to t of n nodes (and thereby t (master-)secret key shares).
We do, however, plan for protection of the derived decryption keys by deriving encrypted shares. Even when combined, this gives the guarantee that nodes and/or a dapp will only see an encrypted (unusable) version of the userâs decryption key. Depending on dapp design, the user could decide who (eg. them alone, or a canister, or a node, or another user) has control to decrypt and use the key.
2 Likes
Hi @ais @gregory, our team is building Lighthouse - Perpetual storage on Filecoin and also built IC Drive previously. We also recently released an open-source Encryption SDK - Kavach - GitHub - lighthouse-web3/encryption-sdk: Build your trustless, decentralized and fault tolerant Applications using distributed key shards with threshold cryptography. We are interested in using IC canisters for storing the shards of the encryption key to the file and retrieving and aggregating on the users only when a signature is verified from an EVM-based wallet address. We think this use case can be relevant for storing private data and bringing smart contract-based access control not just on IC but also on other web3 storage systems.
It will be great to get your feedback on it as our team plan to implement it soon.
10 Likes
Hi @nandit123 ! Very interesting use case you have there! Do you have some documentation on how this key sharding would work cryptographically? I assume a key âshardâ is a Shamir share of the secret key? And would you keep all shards on the IC, or would you keep different shards on different chains? In the latter case: how would you protect the shards on those chains?
If youâre building this mainly on the IC, then vetKD could be exactly what you need. Essentially, the decryption key shards/shares would not be stored on chain, but the nodes in an IC subnet would store master key shares that would allow your users to reconstruct decryption keys on the userâs side whenever they need them, protected by any access policy that can be expressed in a canisterâwhich is pretty much anything you can think of, including verifying an ETH transaction.
6 Likes
It uses BLS Threshold Cryptography as in our GitHub repo. Currently, shard generation happens on a centralized server, and shards are stored on 5 nodes controlled by our team. Let me know if you need more info here.
The plan is to keep all shards on the IC chain independent of the use case.
Yeah, I wasnât aware of vetKD. Is it already live? By ânodes in an IC subnet,â do you mean IC Canisters? @gregory
3 Likes
Hey @nandit123,
Sorry, for the late reply. Iâll try to answer your questions but would also encourage you to watch the community conversation on this topic.
No, itâs not live yet.
Nodes are the physical machines that make up a subnet on the Internet Computer. Canisters are run by these nodes.
3 Likes
Do you have any updates for us?
3 Likes
Almost!
We are still discussing interface details and working on prioritization internally, but we have made some progress with the formalization.
Main updates:
- The paper is as well as done and will appear online in the next week or so. Iâll post it here.
- @gregory will go to Tokyo to give the talk at the Real World Crypto (RWC) conference next week.
- I am writing a vetKD primer that will give a bit of background about tBLS, Identity Based Encryption (IBE), and a high level intro to vetKD. Iâll put it online before the end of the week, with the goal that you can use it as a basis to better understand the talk/paper. If there are any other major things youâd like explained, let me know.
They are the main updates.
Aside. If you are interested generally in whatâs going on in cryptography, I highly recommend that you attend RWC (physically or virtually) itâs really a great place to see the cutting edge of crypto research in practice. You need to be an IACR member to attend - anyone can join for $50 per year. IACR members can attend all IACR conferences online at no cost. You can see the program for RWC here, register here, and learn more about the IACR and becoming a member here.
19 Likes
Thank you!
I appreciate that the primer will be up this weekend. I will read it before next weekâs RWC and if I have any questions, I will ask him directly 
2 Likes
Hello!
Apologies for the delay - many things to explain, github outages, and coordinating across three continents⌠you know how it goes.
Gregâs talk is in the morning and the VETKeys primer is now live on the blog!
It gives a brief overview of the background for VETKeys, the primary goal is to introduce you to crypto terms and notation. Note, if I talk about crypto, I always mean cryptography.
There are many, many other things to explain, so if you like this sort of foundational thing, tell us and we can do more. Also good to know if there are specific topics that youâd like.
Action items for you!
We are discussing priorities now, and still finishing the paper. It would be really helpful if you tell us
- If you would like to see us develop this feature, why, and how important is it to you?
- what would you need in terms of support from us (technical explainers like the primer, tutorials, samples, etc)
Thank you and enjoy!
12 Likes
Hello DFINITY community,
I am currently working on developing a no-key-wallet that allows users to securely interact with another blockchain without having to manage their private keys. My goal is to provide a user-friendly solution that maintains a high level of security and privacy.
Iâve been exploring the use of threshold ECDSA to distribute the signing process across multiple parties, which would eliminate the need for users to manage their private keys directly. However, I recently came across this discussion and wanted to inquire whether this technology would be a better fit for my project.
As I understand it, VETKeys also involves distributing sensitive information (like private keys) across multiple parties to minimize the risk of compromise. I would like to know if VETKeys offers any significant advantages over threshold ECDSA for my specific use case or if there are any critical differences between the two technologies that I should be aware of before moving forward.
Additionally, I would like to understand how the current development status of VETKeys might impact my project timeline. I noticed that the VETKeys initiative is still in its early stages, with the community feedback phase being discussed. If I were to consider VETKeys as a solution, what would be a realistic timeframe for its availability?
I would greatly appreciate any insights or advice from the community and the DFINITY team. Your expertise will help guide my decision-making process as I strive to develop a secure and user-friendly no-key wallet for the Internet Computer ecosystem.
Furthermore, I would also appreciate any suggestions or recommendations for other technologies or methodologies that could be suitable for my project. As a developer, I am always open to exploring new solutions and approaches to ensure the best possible outcome for the end users.
Thank you in advance for your valuable feedback and support. I look forward to engaging with the community, learning from your experiences, and contributing to the ongoing discussions around privacy, confidentiality, and key management on the Internet Computer.
Best regards,
Also, I would like to address the two questions you asked:
- If you would like to see us develop this feature, why, and how important is it to you?
Yes, I would definitely like to see the development of the VETKeys feature. As a developer working on the Internet Computer, privacy and key management are crucial aspects of building secure and user-friendly applications. Implementing a feature like VETKeys has the potential to greatly improve user experience by simplifying key management and enhancing privacy. For my specific use case, the no-key wallet project, it would be an invaluable addition, allowing users to access their wallets without worrying about private key management. The importance of this feature cannot be overstated, as it could help to drive the adoption of the Internet Computer by making it more accessible to non-technical users.
- What would you need in terms of support from us (technical explainers like the primer, tutorials, samples, etc)?
In terms of support, the following resources would be extremely helpful for developers looking to integrate VETKeys into their projects:
- A detailed technical primer explaining the underlying concepts, principles, and mechanisms behind VETKeys.
- Step-by-step tutorials covering various use cases and scenarios, with examples in different programming languages, to demonstrate how to implement and use VETKeys in real-world applications.
- Sample code and templates that developers can use as a starting point for integrating VETKeys into their own projects.
- Comprehensive documentation covering the VETKeys API, including clear explanations of all functions, parameters, and return values, along with examples of how to use them effectively.
- Regular updates on the development progress of VETKeys, including any planned enhancements, bug fixes, or changes to the API.
6 Likes
Comment/s
In the article under Internet Computer Content Validation Bootstrap
(i) in explaining IBE, you probably meant
KD runs the IBE key generation algorithm to generate a master (public and private) key pair (mpk,msk) instead of (msk, mpk).
(ii) in âThe threshold settingâ you suddenly mention T,V,E. For a naive user, you might want to define V, E,T prior to this mention.
Questions:
(a) how does Bob authenticate idbob to KD in IBE? through internet identity?
(b) In an implementation on IC of VETKD, do you envisage a threshold set of canisters running this protocol for each bob?
4 Likes
Iâll happily be that annoying guy who just asks when E2E is being shipped?
Realistic before the end of Q2? Excited for this feature.
6 Likes
I believe that is partially up to you! We are in the process of prioritizing work for the coming months, so it would be great to know what people are interested in more or less.
Any particular use cases that require this feature would be good to know about so I can build a strong case here.
A full implementation is for sure not realistic by EoQ2, but we are planning an interface with a test-key canister (Ă la bitcoin integration beta testing last year) so that people can already experiment with integrating and playing around with use cases.
2 Likes
Thanks for that, I switched pub and priv and bolded V, E, and T in the first paragraph.
Re questions
(a) how does Bob authenticate idbob to KD in IBE? through internet identity?
Yes, Internet Identity would be one way to do it, but any access control policy implemented in an app could also work depending on the type of application. âIdentityâ can be considered quite fluid in this feature, it can be an arbitrary string, so it could be that authentication is not necessary. Consider the example where you encrypt a message âto the futureâ, the ID or string that you encrypt to could be a future date. When that date is reached, the dapp derives keys for that day and send to the user.
Happy to describe more use cases in a blog post if you think itâs useful.
(b) In an implementation on IC of VETKD, do you envisage a threshold set of canisters running this protocol for each bob?
Yes, exactly. The idea is that there would be at least one subnet that is âequippedâ with master keys from which Bobs can derive VETKeys. Depending on the implementation and subnet size we hope to achieve at least 100 key derivations per second.
2 Likes
Hi @b3hr4d, thanks so much for the detailed feedback and for your answers to the questions. Itâs much appreciated! Your project sounds great and I wish you the best with it.
The main difference is that VETKeys are essentially threshold BLS keys which generally tend to be easier to deal with than T-ECDSA keys. If you want to sign transactions on other chains (eg Bitcoin or Ethereum) then it is likely that youâll still need an ECDSA signing key. This could be stored in shares on the IC but any signatures would need to be generated locally on the userâs device or in the browser. Itâs not entirely clear how this would differ in terms of efficiency relative to using the threshold ECDSA signing directly. Also, note above some comments between @lastmjs and @gregory about the security considerations for this.
Regarding the development status, again, this is still in discussion, but we do our best to get a test/beta interface out soon.
For the other technologies, I leave you in the capable hands of the community
I get the feeling that some other community wallet/auth projects have similar questions, so stick around the forum and Iâm sure there will be some interesting conversations popping up.
4 Likes
The presentation video is now available for everyone to watch!
8 Likes