Encrypting pool files using cntools question

Staking & Delegation Stake Pool Security
1

Hi There,
Would a block producer generate blocks successfully if pool files are encrypted and protected using cntools command line interface?

When the pool shows as encrypted on cntools, all files are read-only (400) and cold.skey file is encrypted. Would this be Ok to produce blocks?

Thanks,
Mil

2

I am not using cntools, but you don’t need the cold key on the block producer, so I assume it is fine. But I still don’t understand why cold.skey is there, it should only be on the cold machine, it should never be on a server. I assume it is there for commodity when rotating the kes keys and the operational certificate.
The read-only files are ok (400) if they belong to the user running the cnode service. It is even better to be read-only and only readable by that user.

3

As far I understand you do need the cold key to rotate the kes keys, so it makes sense your explanation.

What about the counter file? Read-only wont allow cntools to change the counter. I assume that it should not be read-only.

Thanks for the response

4

Before to renew u will need to decrypt the files

Make a copy before to encrypt the files because if u will forget the password …

5

Thanks. Makes sense.

6

@Alexd1985 Does cntools software encrypt the cold keys and store them on the block producer? In a LUKS encrypted container?

7

It deletes the cold.skey pool file and generates cold.skey.gpg encrypted file in the block producer.

8

OK, I see the encryptFile function in the cntools.library that provides this “feature”:

# Command     : encryptFile [file] [password]
# Description : Encrypt file with GPG
# Parameters  : file      >  Path for file to encrypt, will get a new .gpg file extention added to filename
#             : password  >  Password to encrypt file with
encryptFile() {
  exec >&6 2>&7 # normal stdout/stderr
  sleep 0.1
  echo "${2}" | gpg --symmetric --yes --batch --cipher-algo AES256 --passphrase-fd 0 --output "${1}.gpg" "${1}" &>/dev/null && \
  safeDel "${1}" >/dev/null || {
    exec >&8 2>&9 # custom stdout/stderr
    println ERROR "${FG_RED}ERROR${NC}: failed to encrypt ${1}"
    return 1
  }
  exec >&8 2>&9 # custom stdout/stderr
  println DEBUG "${1} successfully encrypted"
}

So cntools encourages cold keys to be actually hot and on the same machine!

1 Like
9

Yes, the counter file needs to be read-write before the kes rotation, I assume cntools are making it read-write before generating the operational certificate, then read-only again.
However, since the Vasil Hard Fork, the counter needs to be exactly 1 more than the counter used when minting the last block (or 0 if the pool never minted a block), and I understand from people using cntools that the counter for the next operational certificate can be given by them when generating it. The counter file can be generated with carano-cli, there is a subcommand for that.

1 Like
10

Can you provide the cardano-cli command to generate a new counter for reference and those not using cntools? Thanks!

11

cardano-cli node new-counter --cold-verification-key-file cold.vkey --counter-value 0 --operational-certificate-issue-counter-file cold.counter

1 Like
12

–counter-value 0 means current counter?

13

No, it means next.

14

Just because cntools has a function to encrypt/decrypt does not mean the tools are encouraging cold keys to be on the block producer. For example, the cold keys could be encrypted on an air-gapped machine; unencrypted when KES rotation is required; KES, etc. sneakernet’d back to the block producer.

This is actually described along with a diagram in the guild operators documentation, review the offline workflow for clarification: Overview - Guild Operators

1 Like