Skip to main content

Module seal

Module seal 

Source
Expand description

WU2: the e2e SEAL pipeline (SPEC §5) — the crypto crux of dig-message.

ONE Chia BLS12-381 identity keypair does everything: its G2 signature authenticates the sender and ECDH over its G1 group seals the payload. There is NO X25519 and NO Ed25519.

§Seal (send) — SPEC §1 pipeline + §5.1

serialize payload → compress (§1.1) → BLS-G2 sign the transcript (§5.1, domain-separated so it can never be a chain AGG_SIG) → G1-DHKEM auth-seal (HPKE AuthEncap analog over BLS12-381 G1: ephemeral + static-sender ECDH → HKDF-SHA256 → ChaCha20Poly1305). The kem_enc is the 48-byte ephemeral G1 point; the sealed region opens ONLY with the recipient private key AND the correct sender public key.

§Open (receive) — SPEC §5.2 / §5.7

subgroup-check kem_enc + sender key BEFORE any DH → G1-DHKEM auth-decap + AEAD-open → verify the BLS-G2 sender signature → header-match check → expiry discard (§5.6b) → anti-replay check (§5.6) → decompress under the bomb guard (§1.1) → deliver. Fail-closed at every step.

The DH / sign / verify / subgroup primitives come from dig-identity (never re-rolled). The DHKEM / HKDF / AEAD composition lives HERE (the decider’s crate split).

Structs§

OpenedMessage
A successfully opened + verified message (SPEC §5.2). The payload is the decompressed plaintext; the caller routes it via the type registry (SPEC §4).
SealParams
Everything the sender supplies to seal one message (SPEC §5.1). The anti-replay counter + timestamp_ms and the expires_at TTL are sender-chosen; the crate binds + enforces them.

Functions§

open_message
Open + fully verify a sealed envelope (SPEC §5.2 / §5.7), advancing the anti-replay guard.
seal_message
Seal a message end-to-end (SPEC §5.1), generating a fresh ephemeral for forward secrecy.