Setting up the keyring
The keyring holds the private/public keypairs used to interact with the node. For instance, a validator key needs to be set up before running the Injective node, so that blocks can be correctly signed. The private key can be stored in different locations, called "backends", such as a file or the operating system's own key storage.
Available backends for the keyring
The os
backend
os
backendThe os
backend relies on operating system-specific defaults to handle key storage securely. Typically, an operating system's credential sub-system handles password prompts, private keys storage, and user sessions according to the user's password policies. Here is a list of the most popular operating systems and their respective passwords manager:
macOS (since Mac OS 8.6): Keychain
Windows: Credentials Management API
GNU/Linux distributions that use GNOME as default desktop environment typically come with Seahorse. Users of KDE based distributions are commonly provided with KDE Wallet Manager. Whilst the former is in fact a libsecret
convenient frontend, the latter is a kwallet
client.
os
is the default option since operating system's default credentials managers are designed to meet users' most common needs and provide them with a comfortable experience without compromising on security.
The recommended backends for headless environments are file
and pass
.
The file
backend
file
backendThe file
stores the keyring encrypted within the app's configuration directory. This keyring will request a password each time it is accessed, which may occur multiple times in a single command resulting in repeated password prompts. If using bash scripts to execute commands using the file
option you may want to utilize the following format for multiple prompts:
# assuming that KEYPASSWD is set in the environment
yes $KEYPASSWD | injectived keys add me
yes $KEYPASSWD | injectived keys show me
# start injectived with keyring-backend flag
injectived --keyring-backend=file start
The pass
backend
pass
backendThe pass
backend uses the pass utility to manage on-disk encryption of keys' sensitive data and metadata. Keys are stored inside gpg
encrypted files within app-specific directories. pass
is available for the most popular UNIX operating systems as well as GNU/Linux distributions. Please refer to its manual page for information on how to download and install it.
The password store must be set up prior to first use:
pass init <GPG_KEY_ID>
Replace <GPG_KEY_ID>
with your GPG key ID. You can use your personal GPG key or an alternative one you may want to use specifically to encrypt the password store.
The kwallet
backend
kwallet
backendThe kwallet
backend uses KDE Wallet Manager
, which comes installed by default on the GNU/Linux distributions that ships KDE as default desktop environment. Please refer to KWallet Handbook for more information.
The test
backend
test
backendThe test
backend is a password-less variation of the file
backend. Keys are stored unencrypted on disk.
Provided for testing purposes only. The test
backend is not recommended for use in production environments.
The memory
backend
memory
backendThe memory
backend stores keys in memory. The keys are immediately deleted after the program has exited.
Provided for testing purposes only. The memory
backend is not recommended for use in production environments.
Adding keys to the keyring
You can use injectived keys
for help about the keys command and injectived keys [command] --help
for more information about a particular subcommand.
To create a new key in the keyring, run the add
subcommand with a <key_name>
argument. For the purpose of this tutorial, we will solely use the test
backend, and call our new key my_validator
. This key will be used in the next section.
$ injectived keys add my_validator --keyring-backend test
# Put the generated address in a variable for later use.
MY_VALIDATOR_ADDRESS=$(injectived keys show my_validator -a --keyring-backend test)
This command generates a new 24-word mnemonic phrase, persists it to the relevant backend, and outputs information about the keypair. If this keypair will be used to hold value-bearing tokens, be sure to write down the mnemonic phrase somewhere safe!
By default, the keyring generates a eth_secp256k1
keypair. The keyring also supports ed25519
keys, which may be created by passing the --algo ed25519
flag. A keyring can of course hold both types of keys simultaneously.
Last updated