With current algorithms, any key pair generation operation is significantly more computationally intensive than any operation that you carry out with the actual keys - signature creation, in our case. This is particularly true for RSA key pairs, for which the key pair generation is a nondeterministic process - you just don't know exactly how many integers you will have to test before hitting an appropriate prime. The performance cost is not quite as significant for elliptic curve algorithms, but it is still there - hence the convenience of pre-generating them. Alas, if selecting a pre-generated key delays things in a comparable way, pre-generating keys won't buy us anything much. That's what I am trying to assess.

On Thu, Aug 19, 2021 at 6:45 AM libor.peltan <libor.peltan@nic.cz> wrote:

Interesting!

Could you please tell me more about the computational-intensive key generation? I ve never experienced this. How many zones do you (roughly) operate? What algorithm?

What I observe often is that the key generation takes much time, but it's caused by lack of entropy, and it that case, it obviously didn't consume CPU from other processes, like answering.

Anyway, there is an operational question about how to use pregenerate with normal zone. Firstly, it doesn't generate KSKs. It's also supposed to work with "manual" policy so that the server does never try to generate a key itself. Thinking about it, it Might work with automatic policy, but I've never tried it.

Libor

Dne 19. 08. 21 v 14:35 Luveh Keraph napsal(a):

The general idea is to have a sufficiently large number of keys in reserve - since the key generation process tends to be computationally intensive, I do not want to have to generate keys as I need them, for that would have an impact on the performance of the server. Anyway, I think that your answer addresses my question all right; thanks.

On Thu, Aug 19, 2021 at 1:15 AM libor.peltan <libor.peltan@nic.cz> wrote:

Hi Luveh,

what do you need to achieve in first place?

What is your configured key lifetime? "Two years worth of keys" might be just "three" for some operators ;)

Do you use `keymgr pregenerate` command to pre-generate the keys? Please note, that this feature is intended mostly for Offline KSK operation. And it pre-generates just ZSKs.

In any case, if you look at the output of `keymgr list`, you will see the "timers" of each key. This should answer the question, in which order they will be used: the lifetime phases of all the keys are already pre-planned.

Regarding Knot slowness: it is possible. Knot is programmed possibly ineffectively when handling large amount of keys. The reason is, that normally there are just few, or at most several keys in the zone.

Libor

Dne 18. 08. 21 v 22:59 Luveh Keraph napsal(a):

I have been looking into the key pre-generation capability of keymgr, and the following question has come up:

Imagine I pre-generate, say, one month's worth of keys for a given zone. This zone is defined so that it will be signed automatically on bringing up the Knot server. Next I start the Knot server. What criteria are used in order to select the keys, among the pre-generated ones, to be used to sign this zone?

The reason I am asking is because I pre-generated two years worth of keys for a particular zone, and when I started the Knot server it took a significant amount of time selecting the appropriate keys from among the pre-generated ones.