Open edsko opened 4 years ago
Is this still relevant? The current API has this signature:
updateKES
:: HasCallStack
=> ContextKES v
-> SignKeyKES v
-> Period -- ^ The /current/ period for the key, not the target period
-> Maybe (SignKeyKES v)
(We will however change the return type to IO (Maybe (SignKeyKES))
when implementing secure forgetting).
This still only forwards the key by one evolution (which is equivalent to one KES period), but it makes the current period explicit, so we can still tell which period we're evolving to. updateKESTo
can easily be implemented in terms of this, if so desired.
In practical KES implementations, fast-forwarding isn't really feasible anyway; in order to forward the key n evolutions, we have to perform the single evolution calculation n times.
iterationCountKES
has since been renamed to totalPeriodsKES
; it indicates the number of evolutions a KES key can undergo before it becomes invalid.
What isn't explicitly documented yet is the relationship between KES periods and "iterations" or "evolutions" - but for practical intents and purposes, they are equivalent. More precisely:
ocertKESPeriod
).t
), so the key's current KES period is ocertKESPeriod + t
The KES interface (https://github.com/input-output-hk/cardano-base/blob/master/cardano-crypto-class/src/Cardano/Crypto/KES/Class.hs) should be improved:
Natural
in the mock implementation should benewtype
dupdateKES
should get an argument: the KES period to evolve to.We might after all have to skip some periods. For the mock, I can implement this as
But I don't know if this is correct in the general case: does
iterationCountKES
return the period or the iteration count? If the former, this is correct generally, though we still might want to make this part of the main API; in that case, this function should also be renamed, as it's not the iteration count. If the iteration count is something separate from the rest, this function is wrong, but in that case documentation should be improved to document what this is.