# Torus Key Infrastructure - Non-custodiality

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.


1. **ShareA is stored on the user's device**: Implementation is device and system specific. For example, on mobile devices, the share could be stored in device storage secured via biometrics.
2. **ShareB is managed by a login service via node operators**: This share is further split amonst a network of nodes and retrieved via conventional authentication flows.
3. **ShareC is a recovery share**: An extra share to be kept by the user, possibly kept on a seperate device, downloaded or based on user input with enough entropy (eg. password, security questions, hardware device etc.).

Similar to existing 2FA systems, a user needs to prove ownership of at least 2 out of 3 (2/3) shares, in order to retrieve his private key. This setup implemented in Torus' Key Management SDKs provides several benefits, and is **non-custodial for the following reasons below**:

* **No access from any other entity including Torus** - Login services only ever have access to one share, and thus it's not technologically possible for the any login provider, one node, or Torus to retrieve the user's private key without the user themselves.
* **Managed only on the client-side** - keys in TKI are always managed and access via client run code on their device. Servers never have access to a user's keys.
* **Control by the user** - the user is allowed to choose and manage their setups. It acts as a off-chain multisig, has revokability through refreshing of shares and is secured on factors that they choose for themselves.in control of ownership and access to their cryptographic key pair.
* **Interopebility** - Torus' SDKs output an API of a key pair on an elliptic curve which is directly compatible/exportable to other wallets in the blockchain ecosystem.