Completed: ICDevs.org Bounty #27b - NoKeyWallet - Rust - up to $10k

Hey @skilesare ,

We have made significant progress with the library.

Here’s the repository:

So far we’ve built the main functionality to create (and store) EVM addresses and sign (and store) transactions on behalf of the canister. We also added support for Legacy, EIP1559 and EIP2930 transaction types and different chain ids (eg. Ethereum testnets, Avalanche, BSC etc).

Up next:

  1. Handle nonce differently for each EVM chain

  2. Add more unit tests

  3. Add two more e2e tests (for creating a smart contracts / ERC20 transfers)

  4. Work on the “no key wallet” example canister to make more visually pleasing

Might also be a good time to have a look on the repo just to check we are on the same page. Also, what should we call the rust crate for this library?

7 Likes

Guys…this looks amazing so far. I don’t have a great answer on the Rust question as I don’t know my way around that ecosystem much. Can a rust dev make a comment?

I don’t know much about the EVM but I took a quick look and had some initial thoughts on the randomness and private keys in the wallet:

  1. I imagine it’s better to use the randomness from the IC instead of the getrandom crate
  2. People seem to agree that a private key stored in a canister would be very difficult to exfiltrate but not impossible.
1 Like

Maybe supporting standard derived path would be much better. We will open-source something soon, we can discuss later

1 Like

This can be useful: GitHub - rocklabs-io/ic-web3: Ethereum RPC client for canisters on the IC, ic-web3 can help access Ethereum RPC endpoints and sign/send Ethereum transactions from within canisters.

4 Likes

This particular package is using t-ecdsa I believe.

I don’t think so:

1 Like

Ah…ok. @LiveDuo we should be using t-ecdsa to sign these in a secure way. It may be ok to have a switch and just use a random key if a dev wants that kind of security, but it is likely not something that would be used in production. (Might be great for testing though).

@skilesare @paulyoung
We are using the sign_with_ecdsa system call to sign transactions. The getrandom library is only used for getting a random private key in unit / integration tests.

We enabled the js cargo flag because cargo build tries to include the getrandom library and has issues with wasm32-unknown-unknown target.

If there’s a better way to get randomness in unit / integrations tests we are happy to look into it. We will try changing the getrandom dependency to dev-dependencies and see if that works. Also, happy to change the js cargo flag if there’s a better way.

1 Like

People seem to agree that a private key stored in a canister would be very difficult to exfiltrate but not impossible.

Are there actionable things around this? Should we include a warning in the Readme file?

1 Like

That makes sense. Moving to dev dependencies makes that clearer.

A consumer of this crate might still see that and do the same thing, but my main concern was that the library itself was using it.

As an author I would over-communicate the risks involved so that people don’t overlook them or feel misled.

I tried to do that here: GitHub - codebase-labs/ic-auth-tokens: Generate authentication tokens based on the randomness provided by the Internet Computer

As a consumer I would really appreciate it being called out up front.

Given that it’s just used for creating a private key for testing we can possibly get by without it. An option is to hardcode an example private key for our tests.

As an author I would over-communicate the risks involved so that people don’t overlook them or feel misled.

I tried to do that here: GitHub - codebase-labs/ic-auth-tokens: Generate authentication tokens based on the randomness provided by the Internet Computer

As a consumer I would really appreciate it being called out up front.

There were a few forum discussion about the issue. Might be a good idea to include links to those too.

I came across a discussion about increasing the subnet size for the ecdsa signing canisters a few weeks ago. I was under the impression that the subnet will increase in size to (partially?) mitigate the issue.

Looking forward seeing how far how you guys gone.

We thought about supporting the standard derivation path and we probably end up doing it. We are thinking about providing two signing functions - one with only the required parameters for those that don’t know Ethereum as much and one with more parameters that gives developers more flexibility.

Do you have any use cases in mind?

I’m trying to understand the motivation for storing the private key. It seems unnecessary.

If that’s the case and you’re relying on tECDSA then I would encourage consumers of the crate to do the same (perhaps by doing that in the wallet?)

The private key never touches the canister, it’s just for the unit tests. If we remove one test there will be no private key in the crate at all.

We have this because we can’t do the tECDSA create private key call in our unit tests so we have to make a mock function.

2 Likes

I think that’s a good idea.

We just pushed the latest changes to the library.

From the previous time we finished:

  • Proper support for different EVM chains (so the transactions nonce are handled seperately).
  • More unit tests and e2e tests (including smart contract tests)
  • Work on the “No key wallet” example project to make it usable (probably most of our time)

Here are some relevant links:

Happy to hear what others think

2 Likes

We also deployed the starter project which is essentially a working “No Key Wallet”.

Feel free to test it out: https://vqbpb-giaaa-aaaap-qaxda-cai.ic0.app/

4 Likes