Crate akd_client
source ·Expand description
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
- default blake3: Blake3 256-bit hashing
- sha256: SHA2 256-bit hashing
- sha512: SHA3 512-bit hashing
- sha3_256: SHA3 256-bit hashing
- 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
Functions for performing the core cryptographic operations for AKD
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.
This module contains all the hashing utilities needed for the AKD directory
and verification operations
This module contains all of the structs which need to be constructed
to verify any of the following AKD proofs
Utility functions
This module contains verification calls for different proofs contained in the AKD crate
Structs
The label of a particular entry in the AKD
The value of a particular entry in the AKD
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.
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.
The value associated with an element of the AZKS
Used to denote an azks value that has been hashed together with an epoch
This proof is just an array of
UpdateProofs.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:
Merkle proof of membership of a
NodeLabel with a particular hash
value in the tree at a given epochRepresents the label of a AKD node
Merkle Patricia proof of non-membership for a
NodeLabel in the tree
at a given epoch.Represents a specific level of the tree with the parental sibling and the direction
of the parent for use in tree hash calculations
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.
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:
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
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”.
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.
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
The number of children each non-leaf node has in the tree
The label used for an empty node
The value to be hashed every time an empty node’s hash is to be considered
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
Retrieve the in-memory size of a structure