19 Srp
2021
19 Srp
'21
15:18
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(a)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(a)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.
>
>