`torus profile recover` and paper keys

Nobody has claimed this yet.

If someone loses their passphrase, we have no way for them to recover or reset it.

The passphrase is not stored anywhere, and is used to derive the key to encrypt their master key, which is in turn used to encrypt their org specific keys. In other words, once you lose your passphrase, you've lost access to *everything* else.

We need a method for a user to recover their master key, and re-encrypt it with a new phassphrase.

# Existing setup

A user's passphrase is via `scrypt` to 256 bytes. The first 192 bytes are used to encrypt the master key via `triplesec`. The next 32 bytes are used for `hmac` authentication against the server during logic. The final 32 bytes are used for v2 login (implementation in progress), which uses `eddsa` for authentication.

# New setup

We need to:
- allow a user to authenticate with their passphrase as is done now
- allow a user to authenticate with a backup paper key, which has restricted access
- it can retrieve the master key
- it can change the master key
- it can change the passphrase based eddsa login details
- store the master key in a way that is accessible by both the passphrase and the paper key

If both the passphrase and the paper key allow access to the master key, then if a user loses their passphrase, they can authenticate against the server using their paper key, download the master key, and re-upload the master key, encrypted for their paper key and their new passphrase (which they would also upload).

## Shared encryption of the master key

Under the new scheme, the user's passphrase will be stretched and split as such:

| 0 - 31 | 32-63 |
| ------ | ------- |
| curve25519 for master key | eddsa for auth |

An account with a paper key will use an entirely different method for decrypting the master key. Since both the `torus` client will have to know how to do this, and the server will know which accounts are configured this way, we can _reset_ the bytes used and stretch less.

The paper key will likewise be stretched to 64 bytes, and split in the same way.

The master key will be encrypted via `triplesec` as before, but we will generate the passphrase via `ecdhe` (see `curve25519.ScalarMult`) using the curve25519 portions of both the passphrase and the paper key. there is no need to manually stretch the `ecdhe` output before feeding into `triplesec`, as `triplesec` will `scrypt` itself.

# Creating the paper key

New accounts will generate and display the paper key during signup.
Existing accounts will need to upgrade. We can do this in the client by detecting that the server has told us we're on the old login flow during login.

The paper key itself should be a mneumonic sentence, generated via https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki or similar.

# The profile recover command

`torus profile recover` (or `torus recover`?) will prompt for your email and your paperkey, then allow you to enter a new passphrase. It will handle re-encrypting the master key with your new passphrase/existing paper key

The issue names the `torus profile recover` command and the existing login flow; begin by locating those entry points and tracing how the passphrase-derived key is stored and used. Done means new and upgraded accounts can create and use a paper key, recover the master key, and re-encrypt it with a new passphrase while preserving restricted paper-key access.

Written by the indexing model from the issue text.