Extensible crypto for wallets
SNARKs and STARKs require signatures algorithms that differ from Ethereums default one.
EIP-1024 proposes encryption functions to be added to wallets, forcing all wallets to implement new crypto, which is complex and risky.
DApps have anticipated future needs for new cryptographic algorithms, for example diffie-hellman, off-the-record messaging, etc. Going through an EIP process each time is a bottleneck.
As discussed in the ETH1x workshop, we should focus on solving classes of problems, not point features. This proposal aims to solve this class of problems.
DApp developers can submit webassembly bytecode for their custom crypto using a
register_algorithm API. It can then be called using a
register_algo(algo_wasm_blob) -> code_hash use_algo(code_hash, [...algo_input]) -> algo_output
They are defined as follows:
def register_algo(algo_wasm_blob): code_hash = sha3(algo_wasm_blob) cached_algos[code_hash] = algo_wasm_blob return code_hash
def use_algo(code_hash, [...input]): wasm_blob = cached_algos[code_hash] derived_key = sha3(private_key, code_hash) output = ewasm_engine(wasm_blob, [derived_key, ...input]) return output
This API allows implementing new signature schemes, but also more complex protocols involving
A well designed API also allows adding other primitives like symmetric encryption/decryption, public key encryption, diffie-helman, off-the-record messaging, etc.
In particular it allows implementing
If the algorithm needs random numbers, it can use
hash(derived_key, input_nonce) with a DApp supplied nonce in input.
User supplied crypto. A DApp is allowed to supply it’s own algorithms. This is the most flexible approach as wallet developers are not involved in adding new cryptographic methods. An alternative would be to have wallet maintainers approve a set of algorithms, much like precompiles in Ethereum.
Key derivation. Especially when arbitrary code is involved, it should not be possible to output any information on the private key. In the proposed API, the worst that could happen is that the
derived_key is leaked (i.e. when the
algo_wasm_blob implements the identity function). This does not compromise the private key or the derived keys of other algorithms.
Choice of WebAssembly. Nodes will have eWASM implementations available already to support eWASM precompiles which can be re-used here. Browser integrated wallets like Metamask/Brave/Opera have WebAssembly available through the host browser.
Q1. How hard is it for native/mobile wallets to process eWASM?
Q2. Are there attack vectors for browser integrated wallets to run untrusted WebAssembly? Most of this would be covered by random webpages using WebAssembly, so the attacks would have to come from the integration with extension.