Skip to main content

Keyring

Use the CLI keyring to create, import, export, and delete keys.

The private/public keypairs required to communicate with the node are kept in the keyring. For instance, in order for blocks to be properly signed, a validator key must be created before starting the node. The term "backends" refers to a variety of storage options for the private key, including files and the operating system's key storage.

tip

Please refer to our Key Management if you need a refresher on private keys and key management.

Add keys​

To get assistance with the keys command or to learn more about a certain subcommand, use the corresponding commands listed below:

humand keys
humand keys [command] --help

Run the add subcommand with the <key_name> parameter to add a new key to the keyring. The freshly produced key requires a password, which you must supply. The following part will make use of this key.

humand keys add dev0

# Put the generated address in a variable for later use.
MY_VALIDATOR_ADDRESS=$(humand keys show dev0 -a)

This command creates a brand-new 24-word mnemonic phrase, persists it to the pertinent backend, and produces details regarding the keypair. Make sure to record the mnemonic phrase somewhere secure if this keypair will be used to store value-bearing tokens.

The keyring creates a eth_secp256k1 key by default. The --algo flag can be used to create ed25519 keys, which are likewise supported by the keyring. Of course, both sorts of keys can be kept on a keyring at once.

note

Note: The entire Ethereum public key of type eth_secp256k1 can be used to determine the Ethereum address associated with a public key by computing the Keccak-256 hash and truncating the first twelve bytes.

danger

NOTE: Due to compatibility issues with Ethereum transactions, Cosmos secp256k1 keys are not supported on Humans.ai.

Keyring Backends​

OS​

tip

Since operating system default credentials managers are made to accommodate users' most frequent needs and give them a comfortable experience without sacrificing security, they are the default choice and are designated as os.

To manage key storage safely, the os backend relies on operating system-specific defaults. According to the user's password policy, an operating system's credential sub-system typically manages password prompts, private key storage, and user sessions. The most popular operating systems and their associated password managers are listed below:

Seahorse is commonly included in GNU/Linux distributions that utilize GNOME as their primary desktop environment. KDE Wallet Manager is frequently offered to users of KDE-based distributions. Unlike the latter, which is a kwallet client, the former is actually a convenient frontend for libsecret.

file and pass are suggested backends for headless environments.

File​

The keyring is encrypted and kept in the configuration directory of the program by the file. Every time this keyring is opened, a password will be requested. This can happen numerous times in a single command, resulting in multiple password requests. You might want to use the syntax shown below for numerous prompts when using bash scripts to run commands using the file option:

# assuming that KEYPASSWD is set in the environment
yes $KEYPASSWD | humand keys add me
yes $KEYPASSWD | humand keys show me
# start humand with keyring-backend flag
humand --keyring-backend=file start
tip

The first time you add a key to an empty keyring, you will be prompted to type the password twice.

Password Store​

The pass backend manages the on-disk encryption of sensitive data and metadata associated with keys using the pass application. Keys are kept in app-specific directories inside gpg encrypted files. Both GNU/Linux distributions and the most common UNIX operating systems support pass. If you would want instructions on how to download and install it, please see the manual page.

tip

pass is encrypted using GnuPG. Upon execution, the gpg command automatically invokes the gpg-agent daemon, which manages the caching of GnuPG credentials. For additional details on configuring cache options like credentials TTL and passphrase expiration, please see the gpg-agent man page.

Prior to use, the password store must be configured:

pass init <GPG_KEY_ID>

Change <GPG_KEY_ID> to reflect your GPG key ID. You can encrypt the password store with either your own GPG key or a different key that you might want to use exclusively.

KDE Wallet Manager​

The KDE Wallet Manager is the backend used by kwallet, and it comes pre-installed on GNU/Linux versions that provide KDE as their default desktop environment. For further details, please see the KWallet Handbook.

Testing​

The test backend is a version of the file backend without a password. Keys are kept on disk unencrypted. Only testing reasons are served by this keyring.

danger

🚨 DANGER:Never use a test keying backend to generate your mainnet validator keys. By making your money remotely accessible via the eth_sendTransaction JSON-RPC interface, doing so could lead to a loss of funds. Ref: Security Advisory: Insecurely configured geth can make funds remotely accessible

In Memory​

The memory backend keeps keys in memory. Following program exit, the keys are immediately removed.

danger

IMPORTANT: Solely available for testing needs. The usage of the memory backend in production settings is NOT advised.