This document lays out a series of questions that helps identify the design principles and choices that fit the ideal key management architecture for your wallet or application. Before going through the questions, a general understanding of Web3Auth key management is necessary. Do either head to the docs or full MPC overview to get the general picture. Would we want to use existing social logins (e.g. Google, FB, etc..) , or a passwordless login of our own? What apart from user devices and cloud providers, what factors would users be interested in (e.g Devices, Social Recovery, QR backups, email backups)? Do we want to allow importing of keys, with the trade off of key generation integrity? Is non-custodiality defined as only a user should be able to access the key OR is prevention of denial of service also necessary? Should a user always be able to export their key? Enforicing security policies on all users vs key exportability, which is more important?

This document is a technical description of Web3Auth's MPC infrastructure and its interactions with applications. Its a high-level document, Web3Auth reserves the right to make changes to this document as needed. It is part of a set of documents that describes Web3Auth, others that maybe helpful include: Web3Auth User Key Architecture MPC Infra Architecture Questionaire Introduction With the growth of cryptographic applications, key management has become increasingly important. Mismanagement of private keys often results in considerable financial loss, and as usage of private keys become increasingly mainstream key loss and misuse will become even more prevalent and costly.

This document is a technical description of Web3Auth’s User Key Architecture in our full MPC solution. Its a high-level document, Web3Auth reserves the right to make changes to this document as needed. It is part of a set of documents that describes Web3Auth, others that maybe helpful include: Overview of Web3Auth and Application Interactions MPC Infra Architecture Questionaire Introduction Many existing non-custodial key management solutions present users with trade-offs between security, convenience, and redundancy. For example, backing up your key increases redundancy during key loss, but reduces security if that backup is stolen. Multisig wallets provide a balance of all three, but are more costly to deploy, are less private, and are not cross-chain.

Web3Auth Coinbase MPC Binance Extension Binance Custody ZenGo Wallet Particle Network Unipass SSS vs Full MPC vs Smart Contract Wallet Both/either

Existing private key management solutions have come a long way in terms of user experience. However, many of these solutions make tradeoffs with reduced guarantees on custody and censorship-resistance. For example, password-manager key management solutions can restrict user access by refusing to return the encrypted key from their servers. Which then ultimately derives down to resorting to the usual approach of protecting private keys via redundant backups. We propose a model of key management, tKey, that uses Shamir Secret Sharing to achieve this without sacrificing user experience, while retaining end-user autonomy and control over the private key. tKey manages private keys using the user's device, private input, and wallet service provider. As long as a user has access to 2 out of 3 (2/3) of these shares, they will be able to retrieve their private key. We describe the architecture of tKey and detail several core user flows for onboarding, key recovery, and device management. To achieve these flows, tKey leverages heavily on its service provider and its properties, which could be a centralized provider or something distributed, such as the Torus Network. tKey also depends on a persistent storage layer (e.g. IPFS, Arweave, Sia) to store encrypted metadata. tKey Overview The user starts by generating (client-side) a 2 out of 3 (2/3) Shamir secret sharing, $f_0(x) = a_0 + a_1x$, with three shares: $f_0(1), f_0(z_1), f_0(z_2)$ where $z_1,z_2 \in \mathbb{Z}_q$

Unlike normal threshold secret sharing where all shares have equal "weight" and any $t+1$ out of $n$ shares can be used to reconstruct the private key, in hierarchical threshold secret sharing, participants in the secret sharing are split into different "levels" and shares at a higher level are more important in the reconstruction threshold than shares at a lower level. This type of secret sharing has been studied extensively since the seminal work of Tassa, and since then many variants of hierarchical threhsold secret sharing have been introduced. In particular, we provide a simple adaptation of Pedersen-VSS below for a $(t,n)$ secret sharing where one of the shares is further sub-shared under a $(t',n')$ secret sharing, such that the secret sharing is linear, and adaptable for use as a subprotocol in an existing DKG and TSS scheme. Wlog, we assume that the $n^{th}$ share in the $(t,n)$ sharing is sub-shared. $HTSS-(t,n,t',n')$ Dealer $D$ performs a secret sharing of a secret $z$ D chooses 2 random polynomials $A(z),A'(z)$ over $\mathbb{Z}_q$ of degree $t$: $A(z)=a_0+a_1z+...+a_tz^t,A'_i(z)=a'_0+a'_1z+...+a'tz^t.$ such that $z=a_0=A(0)$ $D$ broadcasts $C{k}=g^{a_k}h^{a'_k}\bmod{p}$ for $k=0,...,t$. $D$ computes the shares $s_i=A(i),s'_i=A'(i)\bmod{q}$ for $i=1,2,3,n-1$ and sends $s_i,s'_i$ to party $P_i$ D also chooses 2 random polynomials $B(z),B'(z)$ over $\mathbb{Z}_q$ of degree $t'$: $B(z)=b_0+b_1z+...+b_tz^{t'},B'(z)=b'_0+b'1z+...+b'tz^{t'}$ such that $b_0=A(n)$ and $b'0=A'(n)$. $D$ broadcasts $C'{k'}=g^{b{k'}}h^{b'{k'}}\bmod{p}$ for $k'=0,...,t'$. $D$ computes the shares $u=B(i),u'_i=B'(i)\bmod{q}$ for $j=1,2,3,n'-1$ and sends $u_j,u'_j$ to party $P_j$

Existing private key management solutions have come a long way in terms of user experience. However, many of these solutions make tradeoffs with reduced guarantees on custody and censorship-resistance. For example, password-manager key management solutions can restrict user access by refusing to return the encrypted key from their servers. Which then ultimately derives down to resorting to the usual approach of protecting private keys via redundant backups. Torus Key Infrastructure(TKI) leverages on variations of threshold key management to achieve a great user experience without sacrificing secuirty, while retaining end-user autonomy and control over the private key. TKI manages private keys using the user's device, private input, and/or OAuth authentication methods (i.e. Google, Passwordless, Reddit) via Torus nodes. As long as a user has access to 2 out of 3 (2/3) of these shares, they will be able to retrieve their private key. In this documentation we further describe the architecture of TKI and detail several core user flows for onboarding, key recovery, and device management. Base Torus Key Infrastructure guarantees The user starts by generating a 2 out of n (in this example 2/3) Shamir Secret Sharing. This gives the user three shares: ShareA, ShareB, and ShareC.

Introduction User authentication on dapps generally make use of a custom message signature, and most dapps tend to implement their own user flows for authentication. Standardizing these flows helps to improve security across the ecosystem, as well as improve compatibility and extensibility. Using a user's Ethereum account to authenticate also allows them to reuse their existing on-chain information with new applications, and allows users to have full control of their data. In many ways, this is similar to the design goals of OAuth2.0, except that data on Ethereum is decentralised and controlled by the user. Signing in with Ethereum allows users to use data that they manage, instead of relying on centralised providers. We propose an OAuth2.0 compatible solution for Ethereum Sign-in that provides a secure standard for user authentication for dapps, as well as a way for web2 applications to leverage Ethereum's capabilities. The main challenge here is to extend the OAuth2.0 specification to accomodate for Ethereum's non-custodial properties, and to avoid reinventing the wheel for authentication since many of the security and usability issues have been addressed as the OAuth2.0 spec has evolved over the years. Project Goals & Deliverables On completion, this project aims to create an open specification for a Sign-In with Ethereum to be easily adopted by both Web3 and Web2 applications. The specification should achieve the following:

Introduction User authentication on dapps generally make use of a custom message signature, and most dapps tend to implement their own user flows for authentication. Standardizing these flows helps to improve security across the ecosystem, as well as improve compatibility and extensibility. Using a user's Ethereum account to authenticate also allows them to reuse their existing on-chain information with new applications, and allows users to have full control of their data. In many ways, this is similar to the design goals of OAuth2.0, except that data on Ethereum is decentralised and controlled by the user. Signing in with Ethereum allows users to use data that they manage, instead of relying on centralised providers. We propose an OAuth2.0 compatible solution for Ethereum Sign-in that provides a secure standard for user authentication for dapps, as well as a way for web2 applications to leverage Ethereum's capabilities. The main challenge here is to extend the OAuth2.0 specification to accomodate for Ethereum's non-custodial properties, and to avoid reinventing the wheel for authentication since many of the security and usability issues have been addressed as the OAuth2.0 spec has evolved over the years. Project Goals & Deliverables On completion, this project aims to create an open specification for a Sign-In with Ethereum to be easily adopted by both Web3 and Web2 applications. The specification should achieve the following:

Introduction Goals & Deliverables standardized way to authenticate instead of signing google sign in equivalent Basic authentication Sessions/duration

Introduction Incentives are an important aspect of any decentralized protocol. Because the goal of our decentralized key management system is to ultimately provide the most usable key management system for users, applications and node providers, a lot of thought must be put into designing the systems in place, our goals with the mechansims are: Ensure constructive behavior of all stakeholders. Peg token value to network growth and utilization at a log scale Creating a sustainable network equilibra in the long term that balances the different stakeholders and ensures unreplacability Below we’ll review the specific economic decisions that must be made, and the logic behind them. While portion highlights an overview of the main mechanisms that the token is currently proposed to be utilized in. Changes are expected, certain paramenters are to be determined as benchmarks and development proceeds on the core protocol.

End goal 2/4 (Most Ideal) Email 1 CredID_a 1 CredStore_a 2 CredID_b 1 CredStore_b 3 Backup 4

Recently in Singapore, a big topic of debate has risen surrounding the usecase of data collected from mandetory COVID contact tracing tokens issued by the government. The "Trace Together"(TT) token tracks proximity data between individuals and while initially the token was publicly promised to only be used in COVID usecases, was recently used in a court case/police investigations for a murder. This resulted in many Singaporeans feeling rather spooked. Previously TT's data usage was only COVID, now its for "serious" criminal cases, what next? It scares us when we are unsure if the government decides to use this data for other reasons not previously disclosed. The fear being that it would be too late by then as they now have full access of our data and in some ways a lot of control over us. While we can go into the discussion of privacy rights vs pragmatism in society, something that intrigued me more was the shift in the way data is managed with the TT initiative. Whereas traditionally, most data models today are centralized to a party managing it. E.g governments keep your data with regards to your identity, your tax payments, house/address etc... on their servers. In order to make it palatable to the general public, the Singaporean government used a more user centric, and arguably consensual data model, which technologically requires access to the token to retrieve its graph like data. Each TT token has a uniqueID which it then shares via bluetooth with other tokens/applications in close vicinity - logging that these individuals have been close to one another. This data is logged locally on the token itself and thus can only be accessed with the token. The uniqueID to citizen mapping is kept with the government themselves, and when they need to contact trace they'd request for the token and figure out the mappings there. Note that in this way, without your token physical (or others) the government can't process the data. This means that whereas with traditional models where parties that hold the vast amounts of data can do aggregate analysis/ and what not on the data, this isnt the case with the TT initiative, it's technologically impossible to gain inisights without the physical tokens themselves. This paradigm shift of requiring consent to anaylse data reduces the risk of our personal information being used for undisclosed usecases, yet it enables us to leverage on the powers of data - be it for health, criminal, economic or other usecases. I'm not sure if the individuals in the police investigation consented to access to their token, but assuming so, they were able to prove to the police exactly whom they were close to without constantly exposing whom they are in contact with through their whole life. On top of not having to constantly give access to my data, with these models we are able to restrict what data we share. Just like how one might not mind sharing their profile information on Google, but definitely do mind sharing their Google drive, these local data models can have similar/even stricter requirements. If I'm sharing information with regards to the murdur investigation, I'll just share who I've been with in the past week for example.

With the proliferation of blockchain and other cryptographic usecases, private keys have begun to hold more value both financially and in other forms. Equivalently, key management has risen in importance, with several key management systems that exist today. Torus' approach to key management leverages on a threhold key management model or MPC. We split a users key between a device, an input and the Torus network - a user can reconstruct their key by combining any of the two. The Torus Network's share/factor is further split amonst its node participants which are currently permissioned. Users access this factor by logging into OAuths such as Google, Linkedin, Wechat, etc... As a user uses their tKey across different devices they increase the number of shares that they hold, reducing the chance of losing a key. User's can also opt to increase their threshold thus level of secuirty to accessing a key, creating a 2FA like experience. This document further dives into several other key management models and how they compare to Threhold Key Management/Torus. TLDR: Summary at the bottom

With the proliferation of blockchain and other cryptographic usecases, private keys have begun to hold more value both financially and in other forms. Equivalently, key management has risen in importance, with several key management systems that exist today. This document further dives into several of them and their trade-offs. TLDR: Summary at the bottom Key Management Models Key Management on User-owned Devices This is pretty much the most basic way of managing key pairs - storing it on the user's device. This could range from their browser, desktop, mobile device or a hardware wallet/ledger. This is the most common way that keys are managed on wallets today but it suffers from several shortcomings. Mainstream users today are not familiar with key management and seedphrases. Furthermore standard key management suffers from trade-offs between; security (how likely it is for the key to be compromised), redundancy (if you lose a key without a backup, you lose it forever) and convenience. Other key management models attempt to improve on this for users.

User sessions are managed via Redis in Tyk, and in order for this to work across regions, we need to set up a Conflict-Free Replicated Database using Redis first. Installing Redis create a redislabs.com account download the binary for redis enterprise Ubuntu 18.04 create two servers via AWS (r5.large, memory optimised since Redis uses memory, > 10 GB storage) one in Singapore, one in US east/west ensure that security groups allow connections from anywhere

Torus is a decentralized key management system. It is a blockchain infrastructure layer that allows wallets and dapps to easily leverage secret-sharing schemes to improve key security and reduce key loss, while still providing a seamless user-experience. Torus provides an abstraction over private keys that is extensible to arbitrary access structures, authentication methods, and permissions, allowing users to manage their keys across different dapps, blockchains, and wallets. With the growth of cryptographic applications, key management has become increasingly important. Mismanagement of private keys often results in considerable financial loss, and as usage of private keys become increasingly mainstream through applications like DeFi, P2P messaging, and Decentralised IDs (DIDs), key loss and misuse will become even more prevalent. Torus aims to solve this by introducing an open platform for decentralized key management with the following properties: Usability: Users can access their keys using standard logins, without compromising on security or redundancy of their key. Incremental security: Users can easily upgrade the security of their keys with more factors of authentication or scoped permissions. Composability: Keys should be usable across blockchains and applications with minimal vendor lock-in. Self-custodial: Users have exclusive control over their keys and how they are managed, without relying on centralised third-parties.

tKey is an open standard for threshold key management. You've seen the prior spec for it and we have the user experience of tKey on a native application as shown below: And you can also try out the current implementation on beta.tor.us, just log in and set it up. There are several other implementations in the works including on BSC and others. We believe in the Universal Logins vision, that user accounts can be managed incrementally by different factors that they own or different forms of attestation. And that tKey implements a form of this vision. Our end-goal here is tKey to be adopted in multiple wallets/applications similar to how seed phrases are prolifirated today. Users would be in control of where their tKeys are kept and held. They have the discretion to choose which front-ends they would like to use thier tKey on. We have two main asks: For you to be an advisor/part of the working group of tKey, the open standard. Seperate from Torus. It is not pegged to any form of fundraising that we are trying to do on our side. tKey.io will be the homempage for the standard. We believe that tKey is an implementation of the philosophy of Universal Logins. And sharing it as such is a much more intuitive way of explaining the concept to both laymen/developers alike. That clarity is imporntant and what we hpoe to have.

Existing private key management solutions have come a long way in terms of user experience. However, many of these solutions make tradeoffs with reduced guarantees on custody and censorship-resistance. For example, password-manager key management solutions can restrict user access by refusing to return the encrypted key from their servers. Which then ultimately derives down to resorting to the usual approach of protecting private keys via redundant backups. We propose a model of key management, tKey, that uses Shamir Secret Sharing to achieve this without sacrificing user experience, while retaining end-user autonomy and control over the private key. tKey manages private keys using the user's device, private input, and wallet service provider. As long as a user has access to 2 out of 3 (2/3) of these shares, they will be able to retrieve their private key. We describe the architecture of tKey and detail several core user flows for onboarding, key recovery, and device management. To achieve these flows, tKey leverages heavily on its service provider and its properties, which could be a centralized provider or something distributed, such as the Torus Network. tKey also depends on a persistent storage layer (e.g. IPFS, Arweave, Sia) to store encrypted metadata. tKey Overview The user starts by generating (client-side) a 2 out of 3 (2/3) Shamir secret sharing. This gives the user three shares: ShareA, ShareB, and ShareC.

The state-of-the-art today for oracles on Ethereum almost exclusively follow some combination of the same 4-step formula outlined by Vitalik: Initial reporting Escalation Coin vote Fork Kleros and Augur both follow this model almost exactly, and some other projects have oracles that just use some subset of the aforementioned steps, like having an honest majority set of parties do an initial reporting, and using a coin vote if there's a dispute. In this model, each step costs more to execute, but incentives are structured so that there's minimal "overflow" to the next step. For example, on Augur, during escalation, each side of the dispute has to put up larger and larger deposits, and the coin vote is triggered when the amount of total deposits exceed some global threshold. If the coin vote is resolved, individuals who bet on the incorrect outcome lose their deposits. By having these incentive structures, we reduce the number of disputes that have to go to a coin vote.