Module tink_core::registry [−][src]
Expand description
Provides a container that for each supported key type holds a corresponding KeyManager object,
which can generate new keys or instantiate the primitive corresponding to given key.
Registry is initialized at startup, and is later used to instantiate primitives for given keys
or keysets. Keeping KeyManagers for all primitives in a single Registry (rather than having
a separate KeyManager per primitive) enables modular construction of compound primitives
from “simple” ones, e.g., AES-CTR-HMAC AEAD encryption uses IND-CPA encryption and a MAC.
Note that regular users will usually not work directly with Registry, but rather via primitive
factories, which in the background query the Registry for specific KeyManagers. Registry is
public though, to enable configurations with custom primitives and KeyManagers.
Traits
KeyManager “understands” keys of a specific key types: it can generate keys of a supported
type and create primitives for supported keys. A key type is identified by the global name of
the protocol buffer that holds the corresponding key material, and is given by type_url-field
of KeyData-protocol buffer.
KmsClient knows how to produce primitives backed by keys stored in remote KMS services.
Functions
Remove all registered KMS clients.
Return the key manager for the given type_url if it exists.
Fetches a KmsClient by a given URI.
Find a key template generator function by name.
Generate a new key for the given key template as a serialized protobuf message.
Generate a new KeyData for the given key template.
Create a new primitive for the given serialized key using the KeyManager
identified by the given type_url.
Create a new primitive for the key given in the given KeyData.
Register the given key manager. Does not allow overwrite of existing key managers.
Register a new KMS client
Register a key template generator function by name.
Return all available key template generator names.