Skip to main content

Module cose

Module cose 

Source
Expand description

This file contains private-use constants for COSE encoded key types and algorithms. Standardized values from https://www.iana.org/assignments/cose/cose.xhtml should always be preferred unless there is a a clear benefit, such as a clear cryptographic benefit, which MUST be documented publicly.

Re-exportsΒ§

pub use thumbprint::CoseKeyThumbprint;
pub use thumbprint::CoseKeyThumbprintExt;

ModulesΒ§

symmetric πŸ”’
COSE symmetric encryption β€” the middle layer of the three-layer stack:
thumbprint πŸ”’
RFC 9679 COSE Key Thumbprints.

EnumsΒ§

CoseExtractError πŸ”’
SafeObjectNamespace πŸ”’

ConstantsΒ§

ALG_ARGON2ID13 πŸ”’
ALG_PBKDF2_SHA256 πŸ”’
PBKDF2-HMAC-SHA256 KDF algorithm discriminant, used by the password protected key envelope in the FIPS cipher suite. PBKDF2 is FIPS-approved, unlike Argon2id (ALG_ARGON2ID13).
ARGON2_ITERATIONS πŸ”’
ARGON2_MEMORY πŸ”’
ARGON2_PARALLELISM πŸ”’
ARGON2_SALT πŸ”’
CONTAINED_KEY_ID πŸ”’
Indicates for any object containing a key (wrapped key, password protected key envelope) which key ID that contained key has
CONTENT_TYPE_BITWARDEN_LEGACY_KEY πŸ”’
CONTENT_TYPE_PADDED_CBOR πŸ”’
CONTENT_TYPE_PADDED_UTF8 πŸ”’
CONTENT_TYPE_SPKI_PUBLIC_KEY πŸ”’
PBKDF2_ITERATIONS πŸ”’
PBKDF2 iterations and salt, used by the password protected key envelope in the FIPS cipher suite.
PBKDF2_SALT πŸ”’
SAFE_CONTENT_NAMESPACE πŸ”’
Each type of object has it’s own namespace for strong domain separation to eliminate attacks which attempt to confuse object types. For signatures, this refers to signature namespaces, for data envelopes to data envelope namespaces and so on.
SAFE_OBJECT_NAMESPACE πŸ”’
MUST be placed in the protected header of cose objects
SIGNING_NAMESPACE πŸ”’
The label used for the namespace ensuring strong domain separation when using signatures.
SYMMETRIC_KEY πŸ”’
XAES_256_GCM πŸ”’
XAES-256-GCM (https://c2sp.org/XAES-256-GCM) extended-nonce AEAD. Given an input key and 192-bit nonce, a counter-based KDF is instantiated with CMAC-AES256, the input key, and the first 96 bits of the input nonce. The derived key and last 96 bits of the input nonce are then used to encrypt with AES-256-GCM.
XCHACHA20_POLY1305 πŸ”’
XChaCha20 https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-xchacha-03 is used over ChaCha20 to be able to randomly generate nonces, and to not have to worry about key wearout. Since the draft was never published as an RFC, we use a private-use value for the algorithm.

TraitsΒ§

ContentNamespace πŸ”’
CoseSerializable
Trait for structs that are serializable to COSE objects.

FunctionsΒ§

debug_key_operation πŸ”’
Helper function to convert a COSE KeyOperation to a debug string
extract_bytes πŸ”’
extract_integer πŸ”’