But I don’t think that we can get the same encryption key if the time condition is met, because the derivation_id will be unique on each call.
What you could do is store the time (lockUtil in your example) together with the thing (e.g., file, note, etc.) that you time-lock encrypt. And when you want to decrypt, you ask the backend for a decryption key for exactly this time. That is, the backend would take the time for which you want a decryption-key as parameter. And the critical thing here is that the backend hands out the respective key only if the respective time (passed as parameter) has already passed (that is, is now or in the past), but it would not hand out the respective key if the time is in the future.
Thanks for the question @hokosugi. In order to get MEV protection, defi dapps need to build on top of this new functionality, for example as @franzstefan sketched in his answer. So existing defi dapp, possibly built on other chains, won’t just get MEV protection for free. The idea is that users can send encrypted transactions so that these are ordered while still encrypted, and only later the defi dapp decrypts them and execute them in order. So if the defi dapp does not support a compatible decryption mechanism then it won’t be possible to leverage this new functionality.
Note that with the upcoming ethereum integration it would totally be possible to have defi dapp entirely on Ethereum, for example, which only leverage the IC to enable decryptability in the dapp.
Hey all I’m hoping this isn’t a stupid question Apologies if it is!
Is it possible to use the vetkd_public_key to encrypt data, and later decrypt using a derived vetkd_encrypted_key? Or does it only work to encrypt and decrypt using the derived key?
Use case: I’m needing the ability for anonymous users to send encrypted data to the canister, and then have only authorised users be able retrieve and decrypt the data.
Correct me if I’m wrong but, in this use case, if we use the derived key to encrypt and anyone (including anonymous calls) can make the call to derive it, that pretty much defeats the purpose of encrypting it in the first place. So I wondered if we could use the public key to encrypt instead. Or is there another way around this that I’m totally missing?
I have a question again, on page 4 of the vetKey paper, there is a section titled “Blockchain-issued signatures and cross-chain bridges.”
How does this work? Is the bridge established by using vetKey as a signature for the verification process?
Also, if vetKey’s characteristics can be utilized, would it be possible to create anonymous bridges?
You can use whatever you want as the derivation_id for the private key derivation, so in your case you could use the canister ID and then use access control rules to determine who is allowed to derive it.
Hi guys! @NathanosDev beat me to the punch a bit, but the demo has been extended to include IBE, and is now merged in motoko and rust.
Two small reminders:
The bounty deadline is coming up at the end of August - if you have questions about anything don’t hesitate to shout here or to share progress.
If you have any feedback on the API, let us know so that we can refine. (I know there have been some questions around derivation id / path, so suggestions there are particularly useful).
We’re slowly winding back up after some vacation, and look forward to see the discussion, questions, submissions, and whatever else may come.
In the IC this is not needed, since there is a built-in certification mechanism, which means that any dapp can get blockchain-issued (threshold) certificates, e.g. on data stored in the dapp, even without vetkeys.
On other chain chains where such certification mechanism is not present, adding support to vetkeys could enable dapp-issued certificates. With this in place you could build some bridging protocol where dapps living on different chains can verify the authenticity of each other statements by verifying their signatures. Of course this is only part of a bridging protocol, since you also need a mechanism to deliver such messages.
As everybody else said, IBE would be the easiest way for doing this since you only need the verification key to encrypt, and the canister can then do access control to decide who can get the corresponding decryption key.
There is another way, which I wouldn’t recommend, which I am adding just for completeness. The vetkd_encrypted_key can be used to derive a (standard) public and private key-pair. So with some additional interaction, entities can derive a public key for their own, publish it (e.g. in the canister), and then anybody can encrypt using the public key. The user who can access the vetkd_encrypted_key can then access the private key and decrypt the messages.
IBE is of course much simpler since it removes the need to generate and publish individual keys, anybody can just derive the public key.
gmgm reviving this thread for a moment with a question!
I’m preparing to present vetKeys at ETH Milan next week. I’ll likely include the MEV protection ideas, but would love to hear if you guys have some ETH-centric applications where vetKeys could be an awesome addition. Let me know!
Seed phrase backup, via II and Vetkeys.
If you lost access to your Metamask, you could restore the phrase, if you still somehow have access to your II.
This is something we want to include in our MetaMask snap based IC wallet.
Also I’m starting to come to a concrete use case and hoping that vetKD will be sufficient. Essentially I want to create a canister that can publish packages to npm. To do this it would need to have the full auth token available to it unencrypted. vetKD could allow for the encryption, and the canister would act as the client and gather the keys. Unfortunately I don’t think this is secure enough…but combined with AMD-SEV enclaves perhaps it would be.
This could be extended to general passwords perhaps, where the canister can temporarily hold the decrypted key in memory inside of an AMD-SEV enclave, and then perform HTTP requests to external services.
AMD-SEV may be on mainnent ~Q1 2024, any rough quarter estimate for vetKD?
Hi @lastmjs, we recently started thinking again about integration, we should be able to give an update in the next weeks.
If I understand your use case, you mainly need an encryption key to transfer the token to the canister, since you then rely on SEV-SNP for storing the secret. One thing to notice is that the canister has to generate some (ephemeral) transport key pairs to get the encrypted key from the nodes running vetkd. So you could as well use the transport key to transfer the token to the canister directly, without relying on vetkd. The main advantage I see with vetkd is in the simplification of the key management on the canister: the canister does not need to generate and announce the long term public keys (it only generates some ephemeral keys), long term encryption keys for the canister could be computed publicly from a master public key.
Not exactly. I want to store the secret encrypted at all times, except when actually needed to perform the outgoing http request to npm. I don’t see SEV-SNP as adequate for long-term storage of secret material.
I’m hoping that the enclave will provide a safe enough location to temporarily decrypt the npm token.
So I want to get the token into the canister securely, encrypted. I want it to stay in the canister always encrypted, and only be retrieved and decrypted temporarily inside of the enclave to perform the http request. I’m also hoping that the request is encrypted with TLS inside of the enclave so that once the request leaves the enclave that the token is safe.
Hey guys, sorry for the late update! Some of our resources have been strategically reallocated to other high-impact projects, such as multi-chains integration. Moreover, we have to balance our efforts with other competing features like threshold Schnorr. So the timeline for VetKeys is not very clear at this point. If there is substantial demand from the community on this feature, then it could be prioritised higher, potentially making a six months timeline a realistic goal. So let us know what you plan to use this feature for, and if you have any prototypes you are interested to turn into products. Your feedback is very valuable in helping us prioritise and use our resources more effectively!
I believe that integration into OpenChat and DSCVR and MEV will help us gain more users.
I understand that Threshold Schnoer Signatures can earn TPS compared to ECDSA, but I think the use cases are few because it can only be utilized for BTC. I would like to see vetKey prioritized if possible.
I’m hoping this isn’t a stupid question 
Apologies if it is!
exactly what I was looking for. Appreciate your help!