Implement 2FA without contracts

[abacabadabacaba]

The way 2FA is currently implemented, the user is required to deploy a contract to their account, which requires them to have at least 35Ⓝ in their account which is unusable for as long as 2FA is active. However, it is possible to implement 2FA differently, by using clever cryptography to make the wallet and the contract helper together generate a single signature, so that regular full access keys can be used and no contract is needed. Here is a preliminary implementation of the necessary cryptographic algorithms, it needs to be integrated into the wallet and the contract helper. Also, an upgrade path should be provided for the users to switch from the legacy contract-based 2FA to the new system.

[vgrichina]

I feel like more straightforward solution would be to rewrite multisig contract with no_std which is likely to reduce amount locked to something like 3-5 NEAR (judging by the fact that it's theoretically possible based on AssemblyScript contracts / some no_std POCs).

Motivation:

• we still need actual multisig support long-term (e.g. foundation currently is using some hacky solutions), not just 2FA for wallet. With "m of n" multisig for Argent-style guardians, etc
• with contract-based account we can add more specific rules for security (daily spending limits, etc). Generally it's not best UX if you have to do 2FA for purchase of 0.25 NEAR worth of bananas for example. I guess specifically for 2FA it can be controlled by contract helper, but for other ways of multisig (e.g. you confirming from wallet on your phone) it wouldn't work.

[abacabadabacaba]

I think that we should use both approaches in the long term. Contract-based solution is more flexible but cryptography-based solution is more efficient.
This cryptographic solution works for the most common use case: just plain 2FA. Additional rules like daily spending limits can be implemented in the contract helper (it can approve some transactions without asking for the second factor). This should also work if 2FA is controlled by another device (e.g. a phone can do the same: approve some transactions without asking for the second factor).
By the way, m-of-n multisig can also be implemented cryptographically.

[vgrichina]

By the way, m-of-n multisig can also be implemented cryptographically.

@abacabadabacaba how does that work, would this still match 1 public key?

[abacabadabacaba]

It is possible to implement m-of-n generation of Ed25519 signatures such that the verification algorithm is unchanged (that is, anything that can verify a regular Ed25519 signature can also verify a signature generated in this fashion). In particular, there is a single Ed25519 public key that is used for verification.

For this to work, the key holders need to run two interactive algorithms: one that is used to generate the common public key and the individual private keys, and another one that is used to generate the signatures. Participation of all n key holders is required for the former algorithm, but for the latter any subset of at least m key holders is enough.

If m = n, the process of key generation can be simplified: each key holder can generate a separate key which can then be added together to produce a common key (the implementation above for the case m = n = 2 uses this approach).