Cold Password Mixing
Please see the Introductory Security Procedures for more general information about how to get started with security. This section will detail how to use the cold password keygen procedure from within the GUI or CLI.
GUI
The GUI is the easiest way to generate a cold password. Simply navigate to the "Keys" tab on the left side panel to get started.
WARNING: this process should be done from a cold, air-gapped computer. If you are attempting to generate mnemonics for use in a hardware wallet from a hot, online computer you are putting yourself at risk. In that case, it is more secure to rely on the hardware wallet's mnemonic generation process. If you don't know how to do this, please see the introductory guide linked above to learn how to set one up.
In the image above, first let's explain what the options are.
- "Generate Random Entropy Mnemonic" -- this is used to generate a random mnemonic from internal random entropy. You can use this to generate a source salt words group.
- Show password: this will display the password you are typing in
- Modular Concat Password: this will break up the password into a number of fields to make typing in long passwords easier
- Salt Words: this is the source salt words group. This is used to increase entropy by acting as a random source. These can be persisted to E2EE Cloud storage or physically and are used as a protection against insufficient entropy in your password.
- Metadata fields: these are optional fields that can be used to add additional entropy to your password. By default these are set to first / middle / last name and birthdate. It is only used for entropy and is automatically added to the concat field at the bottom.
- Password: This box shows the concat password or the one you need to type in if not concatting.
- KDF: This is the key derivation function. Argon2d is the default and you should rely on the built-in settings
- Memory KiB: Amount of memory to pass to Argon2d, decrease if runtime length is too long
- Threads: concurrency level to pass to Argon2d, decrease if runtime length is too long
- Iterations: time constraint to pass to Argon2d, decrease if runtime length is too long
- KDF: DSha256 is a legacy format which uses a simple iterative SHA with many rounds, recommend minimum 1m rounds.
Keep in mind, the password you enter here should ideally never be entered into a hot / online computer, and should be different from the one you use normally with your key manager or E2EE cloud backup solution.
The default parameters are already high for the generation process, but feel free to set them as high as you can, within the amount of time that is reasonable for you to wait. The longer the better, but it is not necessary to go beyond the defaults.
If you need to generate multiple mnemonics, add an offset to the end of the password field i.e. /0 or /1 -- it is
safe to store metadata about these offsets to keep track of it internally for yourself.
When generating the cold password -- make sure you use sufficient entropy if you are leaving salt words empty. Short passwords at this step are dangerous (without a randomly initialized salt), as they won't gather enough entropy to generate a sufficiently random mnemonic. Mnemonics are typically generated using a randomized seed collected with hardware entropy. As long as you use a sufficiently matching amount of entropy it should be secure. This requires memorizing a very long password. 100+ characters is ideal, but this is much easier than memorizing a random mnemonic because it can be built with whatever associations are easiest for you to memorize. A mixture of dictionary words, symbols, fragments of other passwords you're familiar with, and more is ideal. Try easy association expansions. If part of your password for instance is 'dog', this can be expanded to 'dogcat' to lengthen it and is an easy to memorize association.
So long as you have some symbols and other standard password features, most of the length in generation should be focused on just expanding it for entropy purposes.
Keep in mind, using a salt is the recommended path here, you should back this up (and so long as you have sufficient entropy, it's okay to backup the salt to your E2EE cloud so you don't lose access to it.) The only reason NOT to use a salt is if you want to rely on this purely as a brainwallet where you can recover it even in the event of loss of your cloud / physical backups.
Important note -- do not ever copy any mnemonics intended to be used with hardware wallets onto the USB drive. Manually enter them into a Trezor or Ledger wallet from the terminal / GUI output. Do not write any data to disk on the cold computer unless it is the salt words.
You can use the random generate button to generate a salt, and it's okay back this up to your E2EE cloud (if you want to persist it on the cold computer, use the TAILS encrypted persistent store to do so.)
Another important note: never re-use the same password + offset + hashing function type with a different round combination. Any given input will hash rounds sequentially, making all later rounds derivative of earlier rounds. If an earlier round mnemonic is compromised, then all later rounds are compromised as well.
If generating mnemonics for use with external servers, copy them to the main computer and deploy them over secure SSH. Trezor can be used for generating SSH keys.
This is what your final output will look like after generation, there should be sufficient information here to verify after you load it onto a hardware wallet that the addresses match. Check the account addresses to make sure that you have input it correctly.
This process will yield an unlimited number of mnemonics which you can use for different purposes.
There's a choice here in securing the salt, if using a physical copy alone, it should have multiple redundant backups in the event of natural disaster / theft -- otherwise you should rely on some kind of E2EE cloud backup storage solution. Remember so long as you use sufficient entropy in the cold mixing step, protecting the salt is not as important.
Even after doing all of this, you should STILL use a final passphrase, which is okay to use the hot/warm passwords for so long as you have an additional separate PIN on the hardware device. The tradeoff here is around the passphrase length / ease of use in entering for frequency of transactions. Use a longer passphrase when you are making less frequent use of the wallet and if it doesn't impact convenience.
Experimental Further Steps
Note these steps are not fully supported yet and might require manual operations.
If you'd like to secure this even further. Consider generating separate mnemonics associated with metadata keys, i.e. security Q/A questions, and building it into a multi-sig scheme. This process is not yet well supported but will eventually be done. Similarly, you can apply same process towards either generating mnemonics for friends, or for generating Shamir shares.
All of these keys can be used in multi-signature schemes and thresholds set independently of the key distribution. As long as these keys are maintained transactions can update signature thresholds without having to rotate any keys.
The final note on recovery procedures is to generate a large amount of metadata about yourself as a recovery step. In the event of failures of everything else, you should build a metadata prompt using personal information that is easier to recover than passwords. I.e. name, date of birth, town of birth, drivers license number, passport number, secret questions / answers, email, etc.
These metadata items can be either concatted or padded with randomness to generate a set of metadata keys, allowed to be used in threshold schemes for recovery.
Metadata can also be used to pad primary cold passwords, but in that case should only be used with high degree of confidence of recall (i.e. maybe just name/dob in case others forgotten.)
Notes:
- Cold computers with USB random data sources can also be used to generate one time pads for secure message encryption.
- PGP Key management / SSH keys can be generated from hardware wallet