Enum KemAlg 

#[repr(u8)]
pub enum KemAlg {
    X25519HkdfSha256 = 1,
    P256HkdfSha256 = 2,
    RsaOaepSha256 = 3,
    XWing = 4,
    MlKem768P256 = 5,
}

Key encapsulation mechanism. Specified per slot, not per file.

Variants

X25519HkdfSha256 = 1

Author → server and author → recipient.

P256HkdfSha256 = 2

Server → device. P-256 specifically, not X25519: Microsoft Platform Crypto Provider does not provide X25519; TPM 2.0 offers ECDH P-256 and RSA.

RsaOaepSha256 = 3

Fallback for TPMs without ECDH support.

XWing = 4

X25519 and ML-KEM-768 hybrid using X-Wing: a post-quantum half alongside a classical half. Mechanism: crate::xwing; normative form: docs/format.md, “VERSION 3 OPENED”, item 1 (the item itself is in version 4).

Targets a SOFTWARE key: X-Wing is defined over X25519, while a TPM key is P-256. Post-quantum protection and hardware binding of the recipient are currently mutually exclusive; see docs/threat-model.md §2.

MlKem768P256 = 5

ECDH P-256 and ML-KEM-768 hybrid: MLKEM768-P256. Mechanism: crate::mlkem_p256; normative form: docs/format.md, version 5.

The difference from Self::XWing is not strength but WHERE the classical half resides: Platform Crypto Provider supports P-256 but not X25519. Thus the fifth mechanism is the only one combining post-quantum protection with TPM key non-exportability rather than making them mutually exclusive.

Implementations

impl KemAlg

pub fn ensure_supported(self) -> Result<(), CryptoError>

Whether the build can execute the declared mechanism: ONE name for this question.

The name was not introduced for neatness. “Is this mechanism executable?” was answered separately by the fingerprint table (kdf::device_fpr), header length tables, and the client’s share-B issuance branch; the answers agreed only through the editor’s memory. Such a set can diverge exactly once: in the direction of “somewhere a mechanism this build cannot execute was considered executable”.

The answer comes from seal::supports_kem rather than being duplicated here: the match without _ must sit BESIDE THE IMPLEMENTATION, so adding a KemAlg member breaks the build at the code responsible for executing it. This is the Result form of the same answer, for callers needing rejection rather than bool, following SigAlg::ensure_supported.

Errors

CryptoError::UnsupportedAlgorithm: the registry has the number but the build lacks the mechanism.

pub fn from_u8(v: u8) -> Result<Self, CryptoError>

Parse an identifier from a file.

Why this has NO second boundary, unlike its neighbors

AeadAlg::from_u8, SigAlg::from_u8, and TreeHashAlg::from_u8 call ensure_supported during parsing: an unimplemented header algorithm must reject the FILE, the earlier the better. For kem_id, the consequence differs normatively: docs/format.md §3.3 and §3.5 require SKIPPING a slot with an unimplemented or unknown mechanism rather than rejecting the file; a usable slot for this recipient may be adjacent. Rejection built in here would move “skip or reject” from the caller’s level into number parsing, which knows nothing about slots.

The boundary therefore remains a separate Self::ensure_supported call, while parsing answers only “is this number in the registry?”.

Trait Implementations

impl Clone for KemAlg

fn clone(&self) -> Self

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Copy for KemAlg

impl Debug for KemAlg

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl Eq for KemAlg

impl PartialEq for KemAlg

fn eq(&self, other: &Self) -> bool

Equality operator ==.

fn ne(&self, other: &Rhs) -> bool

Inequality operator !=.

impl StructuralPartialEq for KemAlg