ERC-6327: Elastic Signature

Abstract

---

Elastic signature (ES) aims to sign data with a human friendly secret. The secret will be verified fully on-chain and is not stored anywhere. A user can change the secret as often as they need to. The secret does not have a fixed length. The secret will be like a password, which is a better understood concept than private key. This is specifically true for non-technical users. This EIP defines a smart contract interface to verify and authorize operations with ES.

Motivation

---

What would a changeable "private key" enable us? For years, we have been looking for ways to lower on-boarding barrier for users, especially those with less technical experiences. Private key custody solutions seem to provide an user friendly on-boarding experience, but it is vendor dependent and is not decentralized. ES makes a breakthrough with Zero-knowledge technology. Users generate proof of knowing the secret and a smart contract will verify the proof.

Use case

ES is an alternative signing algorithm. It is not an either-or solution to the private key. It is designed to serve as an additional signing mechanism on top of the private key signature.

• A DeFi app can utilize ES into their transfer fund process. Users will be required to provide their passwords to complete the transaction. This gives an extra protection even if the private key is compromised.
• ES can also be used as a plugin to a smart contract wallet, like Account Abstraction ERC-4337. A decentralized password is picked instead of the private key. This could lead to a smooth onboarding experiences for new Ethereum Dapp users.

Specification

---

Let:

• pwdhash represents the hash of the private secret (password).
• datahash represents the hash of an intended transaction data.
• fullhash represents the hash of datahash and all the well-known variables.
• expiration is the timestamp after which the intended transaction expires.
• allhash represents the hash of fullhash and pwdhash.

There are three parties involved, Verifier, Requester and Prover.

• A verifier,
  • SHOULD compute fullhash from a datahash, which is provided by the requester.
  • SHOULD derive pwdhash for a given address. The address can be an EOA or a smart contract wallet.
  • SHOULD verify the proof with the derived pwdhash, the computed fullhash and a allhash, which is submitted by the requester.
• A requester
  • SHOULD generate datahash and decide an expiration.
  • SHALL request a verification from the verifier with,
    • proof and allhash which are provided by the prover;
    • datahash;
    • expiration.
• A prover
  • SHOULD generate the proof and allhash from,
    • datahash and expiration which are agreed with the requester;
    • nonce and other well-known variables.

There are also some requirements.

• well-known variable SHOULD be available to all parties.
  • SHOULD include a nonce.
  • SHOULD include a chainid.
  • MAY include any variable that is specific to the verifier.
• public statements SHOULD include,
  • one reflecting the pwdhash;
  • one reflecting the fullhash;
  • one reflecting the allhash.
• The computation of fullhash SHOULD be agreed by both the verifier and the prover.
• The computation of datahash

IElasticSignature Interface

This is the verifier interface.

verify function SHOULD be called by another contract. The other contract SHOULD generate the datahash to call this. The function SHOULD verify if the allhash is computed correctly and honestly with the password.

Rationale

---

The contract will store everyone's pwdhash.

The chart below shows ZK circuit logic.

To verify the signature, it needs proof, allhash, pwdhash and fullhash.

The prover generates proof along with the public outputs. They will send all of them to a third-party requester contract. The requester will generate the datahash. It sends datahash, proof, allhash, expiration and prover's address to the verifier contract. The contract verifies that the datahash is from the prover, which means the withdrawal operation is signed by the prover's password.

Backwards Compatibility

---

This EIP is backward compatible with previous work on signature validation since this method is specific to password based signatures and not EOA signatures.

Reference Implementation

---

Example implementation of a signing contract:

verifier.sol is auto generated by snarkjs, the source code circuit.circom is below

Security Considerations

---

Since the pwdhash is public, it is possible to be crack the password. We estimate the Poseidon hash rate of RTX3090 would be 100Mhash/s, this is the estimate of crack time:

8 chars (number) : 1 secs

8 chars (number + english) : 25 days

8 chars (number + english + symbol) : 594 days

12 chars (number) : 10000 secs

12 chars (number + english) : 1023042 years

12 chars (number + english + symbol) : 116586246 years

The crack difficulty of private key is 2^256, the crack difficulty of 40 chars (number + english + symbol) is 92^40, 92^40 > 2^256, so when password is 40 chars , it is more difficult to be crack than private key.

Copyright

---

Copyright and related rights waived via CC0.