Extensibility for additional KES keys?

[amesgen]

Certain projects (like Peras and Mithril) also need forward secrecy functionality (for the same fundamental reason as Praos). However, they will most likely require different KES keys than what is being used today.

• Ouroboros Peras requires certificates, which are stake-based threshold multi-signatures. The current KES keys do not have any nice sublinear aggregation properties, so certificates would be very large here (without heavy/still-impractical machinery like SNARKs). One plausible candidate (with forward secrecy) are Pixel signatures which are forward-secure and have the crucial property that any number of Pixel signatures on the same message can be aggregated in constant space.

  Another nice property is that the size of public keys and signatures is independent of the maximum number of time periods $T$, so one can easily choose a large value like $T = 2^{32}$ and still get reasonable public key/signature sizes. So one would most likely only push a new key when setting up a new node, eg due to a planned hardware migration, or if a previous key on some machine has been compromised.

• Mithril is another protocol that requires stake-based multi-signatures. Currently, they use non-forward secure cryptography, and require everybody to re-register keys every ~5 days, but they are currently in the process of changing their certificate scheme, but I don't know the details here.

This issue is about getting an idea of how easy it would be to let the KES agent manage additional keys in the future.

[perturbing]

I believe that there is a per process max limit on the size of mlocked memory. Given this table in the pixel paper

note that the size of the signing key is significant (source). This might impact the ability to store even one or multiple of these keys in the agent.

[amesgen]

Just adding some concrete numbers from the Pixel paper (not the Pixel++ paper above):

Notably, 43 kB private keys for $T = 2^{32}-1$ evolutions, which is more than enough for at least Peras (we could evolve the key every Peras round, which is ~90 seconds, so the key would last for 12250 years), and I'd guess also Mithril; we could even reduce $T$ and hence get smaller private keys.

The limit (in kilobytes) can be checked via ulimit -l, eg for me its 8192 kB, so plenty of space for such a Pixel secret key; but the situation can of course be different on other machines.