Is the CDK really meant for canisters or is it actually a Rust SDK analogous to the other (js) SDK?
Asking because it contains get_encrypted_vetkey which you don’t want to call from a canister because you don’t want to handle secrets in a canister. Same applies to EncryptedMaps.
The support libraries are Rust only at this time.
The final cost of deriving a VetKey has not yet been determined. But, it is likely to be somewhat on par with requesting an ECDSA signature. Over time, the ambition of course is to decrease this cost.
We aim for launch during Q2, exact dates not set yet.
One of the parameters to the function call is transport_key. That transport key is generated in the frontend. It facilitates the safe transfer of the encrypted VetKey from the management canister to the frontend.
pub async fn get_encrypted_vetkey(
caller: Principal,
key_id: KeyId,
transport_key: TransportKey
) -> Result<VetKey, String>;
You are correct in that the canister should not handle secrets. The derived encrypted VetKey is never decrypted by the canister, it is just passed on to the frontend.
Yes, that’s why I am asking why the function is in the canister dev kit (CDK) if it’s expected to be used by the frontend. I thought CDK was for writing canisters.
I clicked on this link in your prior post and there it appears: vetkd-devkit/cdk/key_manager/README.md at main · dfinity/vetkd-devkit · GitHub
The function gets the encrypted key from the management canister to be passed on to the frontend. The frontend cannot call the management canister itself. The key is not decrypted in transit.
Got it. Thanks! I forgot that it can’t be called by external principals (despite having asked it just a few posts above..).
When can we expect Motoko libraries? Any schedule or Roadmap?
Let us get back to you on that question next week after discussing internally.
Please note that the KeyManager and EncryptedMaps are support libraries only and are by no means required to use VetKeys. A Motoko based canister can call the management canister API directly to get public keys or to derive encrypted keys.
Oh, I see. Could you provide an example of how to achieve this using Motoko?
The encrypted notes example app is available in Motoko.
Note that the management canister API has changed slightly since that app was last updated.
To interact with the management canister API before the feature launch, you would use the testing canister instead that provides the correct API.
The keymanager has calls to list users and get access privs for other users, which should only be allowed to managers and not normal users. I attempted to make a PR but didn’t know the repo didn’t accept PRs yet. There are two places where it should check for manager permissions.
Forwarded feedback to the team, thanks!
I want to enable encryption and decryption within a Canister. It’s like making the previous ic-vekd-utils usable in Rust.
The use case I’m considering is to enable the use of signature algorithms not supported by tECDSA or tEdDSA. Specifically, I want to perform signatures using P-256/secp256r1, which is the most commonly used in the world of Digital Identity, within a Canister.
The Canister will create a seed for the private key, encrypt it, and store it. When a signature is required, it will decrypt the seed, generate the private key, perform the signature, and return it to the client.
The decrypted private key will be discarded immediately after use.
The decrypted private key will be discarded immediately after use.
This still means that the private key is accessible to the node providers for some time in the unencrypted form.
Anything encrypted or decrypted by the canister should be considered public because every node provider can see the message to be encrypted (the private key seed) and, therefore, use the private key for itself. To keep things private from the node providers (or eavesdroppers), VetKD requires a third party that is allowed to see the message to be encrypted and the decryption key. This can be a user, a trusted execution environment, or also secure multi-party computation.
Even if we decrypt a seed within a function and discard it when exiting the function, can node operators see the decrypted seed?
Yes. The time window would be fairly small, but that doesn’t improve things much.
Thanks for your clarification
Hey @kristofer, I’m not entirely sure how to use this, I’m not seeing the installation process guide and as this is not published on npm I’m not sure what to do. Also, if I just wanted to use the vetkd utils part of the frontend packages how would I do that?
You are right, @Typonomy, the packages have not been published to crates.io or npmjs.org yet. The easiest way to try things out is to fork the repositories I linked to and start from there.
If you only want to interact with the low level management canister API to do key derivation, you can also have a look at this demo app: GitHub - kristoferlund/send_file_to_eth_demo: ICP vetKeys demo: Send encrypted files to any Ethereum address