User should be able to "encrypt and save" restore progress.

[BenWestgate]

For L1 or L2 it should ask them if they'd like to save their restore progress to their Persistent Storage.

This would require writing an encryption key/passphrase (transfer key or resume key) down that is used temporarily until this wallet's seed is restored in full.

Save the last session's progress in an folder named by the unique Wallet name all at once to obfuscate the threshold.

Pad to the length of 8 shares as that is the maximum data that could be loaded without restoring the max threshold of 9.

Add random noise equal to this length so plaintext shares can not be linked with the ciphertext saved progress.

Use public key cryptography so that entered shares can be deniably encrypted to the Persistent Storage without re-entering that transport key each session. Deniable encryption means a random noise length of the plaintext is added before asymmetrically encrypting and discarded after decryption.

Private key length 128-bits. 256-bit ECC must be used, the public key is saved to the device, indexed by the shares identifier.

If the user "resumes" a wallet restore and types a correct resume key, it will be as if they had entered all their previously saved shares, even from multiple sessions. Effectively "loading" all saved restore progress for that header.

An incorrect resume key would throw an error as the result would be random data, not valid shares.

The resume keypair is unique per Share Header being restored and it is destroyed along with all ciphertexts immediately after a successful wallet restoration.

This allows multiple share sets to be restored in parallel as long as they all have unique headers.

Entering a valid share with an identical header to previously saved and encrypted shares will cause the software to ask if the user is ready to enter their resume key to "resume restoring secret with header ms1XYYYY".

The choices will be resume (decrypt and automatically enter saved shares) and Continue. After each valid share is entered, it will ask again if they'd like to load their saved progress (which will ask for the resume key) which they can skip. If they need to quit again, progress can be encrypted by this header's resume restore public key without writing or entering the private key.

The resume private key can be securely stored until the user is in a safe place to restore the seed and wallet.

[github-actions[bot]]

Stale issue message

[BenWestgate]

This issue belongs here since Bails will have nothing to do with codex32 creation and restore when this repo is finished.

[github-actions[bot]]

Stale issue message

[BenWestgate]

This is rather low priority and comes with a unique UX and security risks: A random private key must be generated and written down, then a public key stored plaintext, then shares are encrypted to the public key and saved.

Furthermore, when this feature is added, it should be the default, but done in RAM until the user asks to save their progress, at which point it would write the public key and encrypted data to their persistent storage after they write down and confirm their encryption key. So lets make it a bech32/codex32 format, be sure to check which hrp are claimed at the SLIP. Let's use a luks2 volume for this for better plausible deniability and less key length needed. 64, 80 or 96 bits should suffice to cost more to brute force than the seed itself, especially 96 and 80.