---
tags: company
---

# A Comparison of Key Management Systems

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.

### Custodial Key Management

A trusted 3rd party holds the private key on behalf of the user, and upon login, returns the private key to the user.

### Password Management Model

The password management model uses low entropy passwords provided by users to encrypt their client side generated keys. They then store these encrypted keys, and hashes of passwords on a server.

When the user logs in, they provide their username/password hash combination to the server, retrieving their encrypted keys and using their password to decrypt the encrypted keys locally.

The model allows the user to access his/her key via a password on any device - a boost in convenience for the end user.

A trade-off to the model is its non-custodiality. Because a password is used to encrypt a user's key, the model suffers from the same brute force/rainbow table attacks that traditional password systems suffer from. Any entity with access to the password hashes/encrypted key are able to repeatedly try different combinations to a users key. On a password with symbols, letters and numbers; it [takes 34 seconds](https://random-ize.com/how-long-to-hack-pass/) for 6 letters, 1-2 days for 8 letters. In addition, it's also possible to withhold access to the encrypted key, leading to censorship issues.

### Threshold Key Management

Threshold Key Management often users some kind of secret sharing to split up users key into shares. A threshold number of shares can be used to reconstruct the users key. Threshold managed keys allow users to have multiple factors to one key which they can manage and safely keep. It allows a user to keep factors as backups without compromising the main key, allowing redunency without the trade-off of security.

Ultimately the properties of this key management model are dependent on where a user keeps each individual share. Different wallets and solutions have taken different approaches depending on their usecase.

### Smart Contract Wallet Model

Instead of a key, smart contract wallets are contracts that hold and manage a user's assets, which inturn are managed by keys (or Externally Owned Accounts - EOA). And thus, again the properties of a smart contract wallet depend on the implementation and how its EOAs are managed. Similar to threshold key management, smart contract wallets have the benefit of multiple EOAs controlling a single account. The additionally can leverage on abstract computation to implement features like daily spending limits or permissions which may safe guard the user.

There are some tradeoffs that come with the ability of computation; less composability and cost. Smart contract wallets are restricted to the blockchain they've been implemented on, even among L1s and L2s. They're also not a primitive key, instead are a contract, so simple native functions you might expect like signatures or attestation don't work. Cost is another factor that exists today, though a smaller factor perhaps as faster/more scalabilble solutions are pushed out.

## Solutions

Here we go through several different products and thier implementations. There's a lot more nuance in many of these implementations, but hopefully it gives readers a good overview of the key management solutionsn. Feel free to reach out to [e-mail] if you feel any of these are inaccurate.

### Metamask

A chrome extension/mobile wallet that managages a key on your device. Simple and non-custodial but suffers from needing to onboard users with seedphrases and device syncing.

### Portis
Portis uses the password manager model to keep keys, they're a web wallet that's integrated into dapps that leverages on a user's browser iframes and the domain security model to secure a user's key.

They have an npm package that provides a web3 provider to developers.

### Fortmatic/Magic
Because Fortmatic also uses a password/email combination, they're often mistaken as the password manager model. However they actually are custodial to thier HSM and AWS. Whilst it takes a little bit of digging to come to this conclusion, their [blog](https://medium.com/fortmatic/security-infrastructure-at-fortmatic-4a95c3688997) alludes to the same conclusion:
Where they describe the interaction of a signup. Its clear authentication to access a key is dependent on the access token that the fortmatic relayer and/or AWS cognito has access to as well.

One can also see this for themsleves in how they handle recovery. Recovery is impossible in the password manager model unless you brute force a user's password, but custodially they are able to email authenticate and reset your password without your prior password.

### Bitski

Bitski is custodial and a web-wallet. They improve security/remove vunlerbilities by never exposing a user's key to the front-end/browser.

### Argent

Argent uses smart contract wallets and a key stored on their mobile application. They implement social recovery with other argent smart contract wallets and even pay for gas on behalf of the user.

### Authereum

Authereum similarly are a smart contract wallet designed for web usage where their EOA is managed via a password manager model. Recovery is done via attaching another key and downloading it.

### Torus/tKey

Torus implements a threshold model called tKey. They 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 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.

### Fireblocks

Fireblocks similarly does threshold key management, but for enterprise usecases instead of on a personal level. They allow different individuals to manage assets in a firm in configurations different per usecase.

### Summary

| Brand | Model | Familar mainstream UX | Synced across platforms | Key recovery | Web/mobile/native compatible | Blockchain agnostic | Non-custodial |
| -------- | -------- | --------------- | --------| ------| ------| ----- | --|
| Metamask | User devices- chrome extension/mobile | N | QR code bridge/sync | Copy a seed phrase | potentially| N|Y|
|Fortmatic/Magic |Custodial| Y| Y | Y - resetting password | Y | Y| custodial to amazon |
|Portis| Password manager| Y| Y|Download/copy backup|N - no mobile/native support |Y | semi?|
|Bitski | Custodial | Y | Y| Y - resetting password | Y | Y | N
|Argent | Smart contract wallet/ mobile user device | Y | N | Y - social recovery| N - not yet web i think | N | Y |
| Authereum | Smart contract wallet - password manager | Y | Y | Y - social recovery | N - perhaps they'll get an app soon | N | semi?
| Fireblocks | Threshold key mgmt | N | N/A | Y | Y | Y| Y |
| Torus/tKey | Threshold key mgmt - user device, torus network | Y | Y | Y - user backups and shares on different devices | Y | Y | Y|