KID0001 - Prefixes, Derivation and derivation reference tables

Navigation

Back to table of contents

Editorial Notes

• KID0001 - Prefixes, Derivation and derivation reference tables (Seth)
  • explanation of SCIDs and derivation logic
  • Indexing & Ordering (high-level)
  • Cryptographic Agility & Digest Agility

• KID0001Comment
  • Commentary: qualified cryptographic material sections of whitepaper
  • Rationale for complexity necessary to support Digest Agility (as opposed to IPFS and other contemporary systems)
  • Key representation issues {later PR by Steve}
    • elliptic curve key compressed representations (TLS bias in most common libraries–> default is uncompressed representation)
    • Signatures in binary handled differently in different crypto libraries

Draft notes (pulled from former Kid0002)

KERI Derivation Codes vs. Multi-Codec

One of the important design constraints for KERI is performance in data streaming applications. Multi-codec is meant to be universally general. Such as function code byte(s), base code byte(s,) hash size byte(s). The average case for KERI is better by design. Performance optimization comes at the loss of generality. A generally compliant implementation of Multi-codec is more verbose on average than KERI codes.

KERI supports two formats for fully qualified cryptographic material. These are Base64 on 6 bit boundaries per character and Base2 on 8 bit boundaries per byte. Base64 is the most compact URL/File/Textual format. Base 2 with 8 bit boundaries is the most generally useful binary format. The coding is designed so that a base 2 stream with 8 bit boundaries and a base 64 stream with 6 bit boundaries have perfect boundaries for both. The number of Base 64-6bit characters is 4/3 of the number of base2-8bit bytes. Likewise the number base 2-8bit bytes is 3/4 the number of Base 64-6bit characters.

The base 64 standard adds pad characters to ensure these perfect boundaries. KERI uses these base64 pad characters opportunistically. In most cases, this means, zero overhead for its derivation code. Its worst case (for now) is 3 additional bytes (4 base 64 characters) for a derivation code when there are no pad characters on the base material. This case is comparable to a Multi-Codec with function, base, and length bytes. Also there is no assurance of perfect boundaries with multi-codec between Base64-6bit and Base2-8bit for a given base material length, which means that pad characters may be needed in addition to the MultiCodec characters. This further increases the average length for multi-codec over KERI.

Furthermore, anything that has perfect boundaries with divisor of 3 base2-8 bit and 4 base64-6 bit may also have perfect boundaries for both. This includes Hex (4 bit boundaries) and octal (3 bit boundaries). For example, 24 bits = 3x8bits = 4x6bits = 6X4bits =8X3bits. So KERI derivation codes satisfy the major binary representations. Perfect boundaries means conversion from characters streams to binary streams is optimized for transmission and processing. Eventually, as KERI becomes widely used, it is anticipated that full binary implementations of KERI will result. These binary representations will benefit from the ability to leverage crypto-graphic material streams (character or byte) that always align on perfect boundaries which should result in significant performance optimizations.

Attached Signature Count Code

After writing code to support generation and verification of Inception, Rotation, and Interaction events and also the
serialization and deserialization of event streams with attached signatures, realized that the idxs field was a problem.

1. the use case for peer did where a set of peer act as mutually witnesses in a multi-sig scheme would have each peer generate a partial set of signatures. In this case idxs must be empty. However if idxs is empty and the event stream protocol is not framed than there is no way to identifier how many attached signatures.

To fix this added an new Signature Material special case derivation code for a special class where the derivation code includes the number or count of attached signatures. This replaces the most common use case for the idxs field which is to provide the count of attached signatures. This count code is inserted after the event and before the set of attached signatures.

2. Given 1 then the only remaining use case for idxs is that one wants to require a given set of signatures. After some more thought realized that this is problem when done in a per event idxs field which includes per interaction event. We then have effectively interaction events defining what set of signatures to require to validate the interaction event. This is further constraint but just feels wrong to allow it this way. May cause some complications down the road. The best way to require a specific set of signatures is in the sith field but using the list format of weighted threshold. This is changed on each rotation event and is more in the spirit of KERI where control validation is established only in establishment events.