key prefixes for ics chains

[vchong]

Wrt

tmkms/README.yubihsm.md

Lines 530 to 531 in 46205b1

	- `chain.key_format.account_key_prefix` - set it as a bech32 prefix for account public key (for example, `cosmospub` for Cosmos network)
	- `chain.key_format.consensus_key_prefix` - set it as a bech32 prefix for validator consensus public key (for example, `cosmosvalconspub` for Cosmos network)

for ics chains (e.g. stride, neutron, etc) should the key prefix be set to the ics chain name itself, or cosmos?
What happens if the wrong prefix is set?

[tony-iqlusion]

ICS chains work the same as any other chain, e.g. for Neutron it's neutron.

If you set it incorrectly, the key will be serialized incorrectly.

[vchong]

If you set it incorrectly, the key will be serialized incorrectly.

Thanks for the swift reply! Wouldn't tmkms still sign properly regardless? After all, when reduced to the raw bytes and bits, the key remains the same? E.g. test output below:

# tmkms.toml
account_key_prefix = "simapppub"
consensus_key_prefix = "simappvalconspub"

# tmkms log
Public key: fetched key1=<some hex string same as below>=...
Public key: base64 decoded key1, size: 32
added consensus Ed25519 key: simappvalconspub1zcjduepq3xayec22g2lra2q94hqekgcdpktf4zmuase7adlma2grqsc83xksrgx59u
...
..[simapp-testnet-1..] received request: PingRequest
..[simapp-testnet-1..] sending response: Ping(PingResponse)
..[simapp-testnet-1..] received request: PingRequest
..[simapp-testnet-1..] sending response: Ping(PingResponse)
..

# tmkms.toml
account_key_prefix = "cosmospub"
consensus_key_prefix = "cosmosvalconspub"

# tmkms log
Public key: fetched key1=<some hex string same as above>=...
Public key: base64 decoded key1, size: 32
added consensus Ed25519 key: cosmosvalconspub1zcjduepq3xayec22g2lra2q94hqekgcdpktf4zmuase7adlma2grqsc83xks2zs7ft
...
..[simapp-testnet-1..] received request: PingRequest
..[simapp-testnet-1..] sending response: Ping(PingResponse)
..[simapp-testnet-1..] received request: PingRequest
..[simapp-testnet-1..] sending response: Ping(PingResponse)
..

[tony-iqlusion]

Yes, it's required for the key to display correctly when using tmkms keys list

[vchong]

Ok, so the prefix is for display only. Thanks again for the help!

[vchong]

keys list doesn't list the prefix though?

$ tmkms yubihsm keys list
Listing keys in YubiHSM <serial>:
- <id or index>: [cons] <64B hex string>
   label: "Ed25519 Key <number>"
...

[tony-iqlusion]

If it's not displaying it, you have something configured incorrectly

[vchong]

The output looks the same as https://github.com/iqlusioninc/tmkms/blob/main/README.yubihsm.md#tmkms-yubihsm-keys-list-list-signing-keys though.

$ tmkms yubihsm keys list
Listing keys in YubiHSM #9876543211:
- 0x#0001: 1624DE64200FB6DB3175225219D290497E3B78190A3EEDA89AEBBC2E2294547CA98E76F9D5

Were you referring to keys import maybe?
https://github.com/iqlusioninc/tmkms/blob/main/README.yubihsm.md#tmkms-yubihsm-keys-import--import-encrypted-backups-of-signing-keys

$ tmkms yubihsm keys import steakz4u-validator-key.enc
    Imported key 0x0001: cosmosvalconspub1zcjduepqtvzxa733n7dhrjf247n0jtdwsvvsd4jgqvzexj5tkwerpzy5sugsvmfja3

[tony-iqlusion]

If correctly configured, it should also display in tmkms yubihsm keys list, despite the README not showing that:

Listing keys in YubiHSM #00NNNNNNNN:
- 0x0001: [cons] cosmosvalconspub1zcjduepqdgvppnyr5c9pulsrmzr9e9rp7qpgm9jwp5yu8g3aumekgjugxacq8a9p2c
[...]

It seems you haven't designated that key as being a consensus key for a particular chain yet?

[vchong]

You're right. There's another example in the README showing the prefix.

user@host:~/.tmkms$ sudo tmkms yubihsm keys list
Listing keys in YubiHSM #0123456789:
- 0x0001: [cons] cosmosvalconspubxxxxxxxxxx
   label: ""
user@host:~/.tmkms$ appd tendermint show-validator
cosmosvalconspubxxxxxxxxxx

If correctly configured

Does this refer to the configuration in:

• tmkms.toml in general?
• tmkms.toml when running keys list?
• tmkms.toml when programming the hsm?
• the hsm in general?

[tony-iqlusion]

You need to assign the key to the consensus role for a particular chain. See: https://github.com/iqlusioninc/tmkms/blob/main/tmkms.toml.example#L50

[vchong]

Got it! We only have

keys = [
    { chain_ids = ["cosmoshub-3"] }

instead of

keys = [
    { chain_ids = ["cosmoshub-3"], key = 1, type = "consensus" }

Thanks!