# A Path to "Easy and Secure" Account

(This article assumes you have some knowledge of Ethereum smart contracts, passkey, and related technologies.)

For a self-custodial Ethereum smart contract wallet, security primarily relies on the security of the "contract and frontend." However, we must not overlook the choice of signature algorithms and their impact on security:

The most widely adopted algorithm currently is **SECP256K1**. While SECP256K1 is mathematically secure, mathematical security does not necessarily equate to security in real-world usage. Risks include not only the risk of private key loss but also the risk of private key theft by malware or brute force attacks due to weak wallet passwords.

What about [WebAuthN](https://www.w3.org/TR/webauthn-2/)?

With WebAuthN, wallets can directly invoke the SECP256R1 algorithm protected by a secure chip on the device for signing ([link1](https://developer.apple.com/passkeys/), [link2](https://developer.android.com/training/articles/keystore)). This approach offers higher security compared to users storing their private keys in a file on their computer. However, the use of SECP256R1 is not without issues, and we need to consider the following:

1. SECP256R1 is not a [precompiled contract](https://eips.ethereum.org/EIPS/eip-7212), meaning that verifying a SECP256R1 signature in the EVM may require over 300k gas.
- 300k gas is unacceptable not only on Layer1 but also on Layer2.

2. SECP256R1 may have a "[backdoor](https://bitcoinmagazine.com/technical/satoshis-genius-unexpected-ways-in-which-bitcoin-dodged-some-cryptographic-bullet-1382996984)" (although there are no known public attacks).
- Given that contract wallets may become widely adopted, this is a risk that cannot be ignored.

3. Device-dependent SECP256R1 signatures may be vulnerable to attacks, such as:
- Some device manufacturers might leak private keys stored in a secure chip to law enforcement agencies under certain circumstances.
- Some device manufacturers might submit your device's public key to law enforcement agencies, potentially exposing the purchase records of anonymous wallet owners on the blockchain.

The above issues are significant, and we must address them before implementing SECP256R1 signatures.

Fortunately, [webauthn-halo2](https://github.com/zkwebauthn/webauthn-halo2) provides inspiration, as it can address these issues to some extent:

1. **Gas**:
- While ZKP in contracts often result in high gas cost, it's not an absolute rule. Some algorithms can bring gas advantages through clever circuit design. For example, the gas consumption of webauthn-halo2 is only half of that of conventional signature algorithms!

2. **Backdoors and Manufacturer Attacks**:
- In on-chain contracts, we cannot directly store SECP256R1 public keys but should store the hash value of the public key. To prevent "rainbow table attacks," this hashing algorithm should accept a secret "setting," such as the zkp-friendly [Pedersen-Hash](https://iden3-docs.readthedocs.io/en/latest/iden3_repos/research/publications/zkproof-standards-workshop-2/pedersen-hash/pedersen.html#pedersen-hash). Generating this hash requires user input (such as the user wallet's unlock password).

Through these two steps, we can address the "backdoor" and manufacturer attack issues. However, the gas issue is only partially solved. If the gas consumption of SECP256R1 zkp verification in the contract can be kept under 100k, we can consider that the high gas problem is solved on Layer2.

---

https://twitter.com/jayden_sudo/status/1700883545290658081