WebOfTrust / keripy

Key Event Receipt Infrastructure - the spec and implementation of the KERI protocol
https://keripy.readthedocs.io/en/latest/
Apache License 2.0
59 stars 55 forks source link

Add rotation number, `r` field to state message structure to support HDK regeneration from key state for Signify #440

Open SmithSamuelM opened 1 year ago

SmithSamuelM commented 1 year ago

The rotation number, rn, r, field will be similar to the existing sequence number, sn, s, and first seen ordinal number, fn, f fields. It will be an ordinal but rn will index or count the number of rotations,. the rn field value is a hex string equivalend of the ridx (int) parameter to the SaltyCreator for generating HDKs in keeping.py. This will allow signify to regnerate private keys on demand and avoid storing or transmitting any encrypted keys to/from the cloud.

This use of the ridx is to maintain backwards compatibility. In the future it will be optional because the kidx field is already unique. The kidx counts all the keys in a key sequence so is zero based to the zeroth key for the whole history of keys for a given KEL not the zeroth key in each est event. This makes the ridx superflouous. This was not a problem when all keys had to start their lifecycle as rotation keys (except the inception signing keys) but with reserve rotation keys in combination with signing only keys, the lifecycle of a key in a key sequence is no longer monotonic. A key may appear multiple times in the case of a reserve rotation key. Thus the ridx would be problematic because any path of a reserve rotation key would not be identical if it included the ridx. Thus in the future a given key sequence should be able to specify that only the kidx can be in the path not the ridx. This means that the key state must also include the list kidxes for each establishment event so that a signing key can be regenerated from its path. And merel knowing the number of keys in a key list is not enough to reproduce the list of kidxes.

For reserve rotation members the kidx

The rn of an inception event is zero, 0, the first rotation after inception has rn == 1. In an establishment only EO KEL which does not have interaction events, the rn and sn are identically valued.

All that signify will need is the state message for any AID and from that and the secret salt ( which only the signify client has). Given the state (with the rn) and key lists for a given establishment event, the signifi client can recalculate the SaltyCreator path used to generate the keys in the first place.

A complication is dual indexed signatures but the cloud can calculate the indices for the signature and pass them to the client with the signing request.

This simplifies things.

in the actual compact label form of the state message the field labels are

s for sn f for fn r for rn

SmithSamuelM commented 1 year ago

A complication is for distributed multi-sig but the groupHab keeps a list of smids and rmids and so can figure out how to map the the key state of the group KEL to the key state of theof the local member and then to get both the rotation index and the key index in the the key list for a given member in order to compute the path.

SmithSamuelM commented 1 year ago

Revised HDK Support

The current HDK path generation in the key store makes the assumption that no key is reused in a sequence of keys for a given identifier prefix. Reserved rotation keys within a single non-distributed multi-sig group identifier violate that assumption. The current pathing includes the rotation index ridx and the key index kidx in the path. The key index is already unique as it is the index in the key sequence of all keys not the offset in a given rotation. This means that the rotation index is not actually necessary for the HDK to generate a unique path for each key, only the key index. Changing the pathing will break unit tests. One way to make it backwards compatible is to add a parameter that optionally indicates to allow reserve keys to be reused and hence not include the rotation index in the path. Suggest reservable True means not use ridx. False means use ridx.