Crate akd_client

Overview

This crate contains a “lean” client to verify AKD proofs which doesn’t depend on any crates other than the native hashing implementations and VRF functionality through the akd_core crate. This makes it suitable for embedded applications, e.g. inside limited clients (Android, iPhone, WebAssembly, etc) which may not have a large dependency library they can pull upon.

Features

The features of this library are

1. default blake3: Blake3 256-bit hashing
2. sha256: SHA2 256-bit hashing
3. sha512: SHA3 512-bit hashing
4. sha3_256: SHA3 256-bit hashing
5. sha3_512: SHA3 512-bit hashing

which dictate which hashing function is used by the verification components. Blake3 256-bit hashing is the default implementation and utilizes the blake3 crate. Features sha256 and sha512 both utilize SHA2 cryptographic functions from the sha2 crate. Lastly sha3_256 and sha3_512 features utilize the sha3 crate for their hashing implementations. To utilize a hash implementation other than blake3, you should compile with

//          [disable blake3]      [enable other hash]
cargo build --no-default-features --features sha3_256

Modules

• crypto
  Functions for performing the core cryptographic operations for AKD
• ecvrf
  This module contains implementations of a verifiable random function (currently only ECVRF). VRFs are used, in the case of this crate, to anonymize the user id <-> node label mapping into a 1-way hash, which is verifyable without being regeneratable without the secret key.
• hash
  This module contains all the hashing utilities needed for the AKD directory and verification operations
• types
  This module contains all of the structs which need to be constructed to verify any of the following AKD proofs
• utils
  Utility functions
• verify
  This module contains verification calls for different proofs contained in the AKD crate

Structs

• AkdLabel
  The label of a particular entry in the AKD
• AkdValue
  The value of a particular entry in the AKD
• AppendOnlyProof
  Proof that no leaves were deleted from the initial epoch. This is done using a list of SingleAppendOnly proofs, one proof for each epoch between the initial epoch and final epochs which are being audited.
• AzksElement
  Represents an element to be inserted into the AZKS. This is a pair consisting of a label (NodeLabel) and a value. The purpose of the directory publish is to convert an insertion set of (AkdLabel, AkdValue) tuples into a set of AzksElements, which are then inserted into the AZKS.
• AzksValue
  The value associated with an element of the AZKS
• AzksValueWithEpoch
  Used to denote an azks value that has been hashed together with an epoch
• HistoryProof
  This proof is just an array of UpdateProofs.
• LookupProof
  Proof that a given label was at a particular state at the given epoch. This means we need to show that the state and version we are claiming for this node must have been:
• MembershipProof
  Merkle proof of membership of a NodeLabel with a particular hash value in the tree at a given epoch
• NodeLabel
  Represents the label of a AKD node
• NonMembershipProof
  Merkle Patricia proof of non-membership for a NodeLabel in the tree at a given epoch.
• SiblingProof
  Represents a specific level of the tree with the parental sibling and the direction of the parent for use in tree hash calculations
• SingleAppendOnlyProof
  Proof that no leaves were deleted from the initial epoch. This means that unchanged_nodes should hash to the initial root hash and the vec of inserted is the set of leaves inserted between these epochs. If we built the tree using the nodes in inserted and the nodes in unchanged_nodes as the leaves with the correct epoch of insertion, it should result in the final root hash.
• UpdateProof
  A vector of UpdateProofs are sent as the proof to a history query for a particular key. For each version of the value associated with the key, the verifier must check that:
• VerifyResult
  The payload that is outputted as a result of successful verification of a LookupProof or HistoryProof. This includes the fields containing the epoch that the leaf was published in, the version corresponding to the value, and the value itself.

Enums

• Direction
  This type is used to indicate a direction for a particular node relative to its parent. We use 0 to represent “left” and 1 to represent “right”.
• PrefixOrdering
  This type is used to indicate whether or not one label is a prefix of another, and if so, whether the longer string has a 0 after the prefix, or a 1 after the prefix. If the first label is equal to the second, or not a prefix of the second, then it is considered invalid.
• VersionFreshness
  Whether or not a node is marked as stale or fresh Stale nodes are no longer active because a newer version exists to replace them.

Constants

• ARITY
  The number of children each non-leaf node has in the tree
• EMPTY_LABEL
  The label used for an empty node
• EMPTY_VALUE
  The value to be hashed every time an empty node’s hash is to be considered
• TOMBSTONE
  A “tombstone” is a false value in an AKD ValueState denoting that a real value has been removed (e.g. data rentention policies). Should a tombstone be encountered, we have to assume that the hash of the value is correct, and we move forward without being able to verify the raw value. We utilize an empty array to save space in the storage layer

Traits

• SizeOf
  Retrieve the in-memory size of a structure