| KDF-index-space allocation | Signature Structure |
Signing Keys
In this post, all the subjects we discussed this far will finally come together as we discuss the coinZdense signing key. For the most part, a signing key, at any point in time, is a combination of:
- A master key
- One or more privilege-tree node identifiers
- A KDF index-space range
- A public key
- Possibly an attenuation derivation index
- A transaction signing index
- A small collection of level keys
We discussed the master key a lot when discussing one-time chunk signing private keys and when discussing salting.
The privilege-tree node identifier is a subject we will discuss in more detail later on. For now, it is sufficient to know that for a root of authority signing key, there is a single privilege-tree node identifier defined by the unsalted generic hash of the appname field in the parametrization file of the blockchain using coinZdense. We will look at the more involved usage of privilege-tree node identifiers when we discuss attenuation and revocation in later posts.
The KDF index-space range consists of an index and a bit count. For the root of authority signing key, the index is zero and the bit count 64, meaning the root of authority signing key is allocated a full 2^64 values of index space starting at an index of zero. We discussed KDF index-space allocation in our previous post, and as it's the most technical post in this series, it might not be 100% clear to you yet. We won't go in to it too much this post, but we are going to revisit the subject when discussing attenuation later on.
Next we have the public key, that is actually the private key of the top level key and an important part of our key as it allows us to use the same key on multiple client systems, given a few caveats we will discuss later on.
Thus far, the static part of signing key. If the key is created, this part so far won't change.
If the signing key parametrization in the application RC file defines a reserved part to the signing key index space, then the signing key will contain an index especially for the creation of derived keys with attenuated authority. As you noticed, we forward reference to attenuation quite a bit in this post, but while it is an essential part of the coinZdense signing key design, it isn't really a big part of the meat of this post today, so just know the details are coming.
Next, we have the transaction index, a dynamic number that is always there and will go up by one every signed transaction.
The derivation index and the transaction index will change as signed operations are published on the blockchain. Our API assumes such a blockchain is available for synchronization between instances of the same signing key on different devices, so these indices should be retrievable from the blockchain given the pubkey.
The above image gives a timeline, showing the transaction index could get synchronized between instances, with the blockchain as intermediate party.
The next chunk of the signing key consists of a collection of level keys. In principle this part can always be reconstructed from the previous parts, and partially it always will, but full reconstruction takes a lot of time and processing power, so for practical reasons, the active level keys are partially cached. The private part of the index keys is always reconstructed from the master key with every run. The collection of OTS pubkeys though, at the broad side of our merle tree, will get cached in a file locally.
Note in the image, depicting a three level signing key, that there is only one root key, but potentially two, or even up to four level keys at each of the remaining levels. For one reason because the transaction index and derivation may map to different level keys. A second reason is API latency for signing operations. It won't get implemented in the MVP reference implementation just yet, but the design anticipates we will need it for real life operations. The reason we want this is API responsiveness will suffer if we don't implement this. Creating a replacement level key can take many seconds, whereas signing a transaction would usually take a small sub-seconds time. So while it will be rare that a transaction signing requires one or more new level keys, when it happens it will make the operation take quite a long time. Now assuming our library is made part of a multithreaded application, if we can calculate the next version of a soon-to-be replaced level key ahead of time in the background, then this massive difference in time needed to complete signing a transaction could be prevented most of the time.
I hope for you as a reader, with this post on signing keys, things are finally starting to come together in your head, and you are starting to grasp the coinZdense library design. In our next post we are going to be looking at the actual signatures these signing keys will create, at least in their most basic form, signatures by a root-of-authority signing key.
Don't get confused by the name root-of-authority, there is no God key for coinZdense, think of these as the owner-key on HIVE. In fact, I hope that one day, a few years in the future, coinZdense will be mature enough for HIVE to implement its then quantum-resistant version of the owner-key as a coinZdense root-of-authority signing key. The authority decomposition and attenuation on HIVE though is just a pale reflection of what coinZdense attenuation hopes to achieve. More on that in a few posts. First up in our next post will come the signatures made by root-of-authority signing keys. We shall name them owner-keys interchangeably for now.
| KDF-index-space allocation | Signature Structure |
|
|
|