Proposal: generic PQ threshold seal envelope using ML-KEM-768 and Shamir shares

[NayiemW]

Summary

This proposes a new brand-neutral package for a post-quantum threshold seal envelope.

The design is based on a stripped-down extraction of an internal Monolythium primitive. Monolythium-specific naming, chain assumptions, mempool assumptions, branding, and product packaging would be removed. The goal is a reusable Rust + TypeScript package for projects that need to seal bytes to an n-member committee where any t members can cooperate to recover the plaintext.

Proposed package name

pq-threshold-seal

Alternative names:

• pq-cluster-seal
• pq-seal-envelope

Primitive

• ML-KEM-768 for per-recipient encapsulation
• GF(256) Shamir secret sharing for t-of-n body-key recovery
• ChaCha20-Poly1305 for the sealed body and wrapped shares
• SHAKE256 for key commitment, nonce derivation, and KEK derivation
• Canonical binding context for domain separation and replay resistance

What the package would provide

• Rust implementation
• TypeScript implementation
• shared test vectors
• byte-for-byte cross-language compatibility tests
• no blockchain-specific types
• no project-specific names or domains
• no consensus, mempool, gossip, validator, or chain logic

API shape

Rust:

let sealed = seal(
    plaintext,
    recipient_encapsulation_keys,
    Threshold { k: 7, n: 10 },
    &BindingContext {
        domain,
        session,
        roster_hash,
    },
)?;

let share = decap_unwrap_share(decapsulation_key, &sealed.recipients[0], &ctx)?;
let plaintext = reconstruct_and_open(&shares, &sealed, &ctx)?;

TypeScript:

const sealed = sealToCommittee({
  plaintext,
  recipientEncapsulationKeys,
  threshold: { k: 7, n: 10 },
  context,
  rng,
});

const share = decapUnwrapShare(decapsulationKey, sealed.recipients[0], context);
const plaintext = reconstructAndOpen(shares, sealed, context);

Out of scope

• Monolythium naming or branding
• blockchain transaction formats
• mempool ordering
• committee discovery
• validator logic
• gossip
• key custody
• production security claims beyond the primitive composition
• claims of audit status

Security status

The package should be documented as experimental until reviewed. The underlying primitives are standardized or conventional, but the composition should not be described as audited or production-proven unless it receives independent review.

Why this belongs here

The repository already focuses on reusable post-quantum tooling across Rust and TypeScript. This package would add a generic bytes-oriented threshold sealing envelope using NIST-standardized ML-KEM-768, with payload size and cross-language vectors treated as first-class constraints.

Implementation notes

If this direction is acceptable, I can prepare a PR that keeps the package brand-neutral throughout:

• neutral package, type, function, and domain-separator names
• Rust + TypeScript parity
• deterministic test vectors
• byte-for-byte compatibility tests
• no dependency on Monolythium-specific runtime structures

Potential neutral domain separators:

pq-threshold-seal/commit/v1
pq-threshold-seal/kek/v1
pq-threshold-seal/nonce/v1
pq-threshold-seal/body/v1
pq-threshold-seal/share/v1
pq-threshold-seal/roster/v1