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§
- Opened
Message - A successfully opened + verified message (SPEC §5.2). The
payloadis the decompressed plaintext; the caller routes it via the type registry (SPEC §4). - Seal
Params - Everything the sender supplies to seal one message (SPEC §5.1). The anti-replay
counter+timestamp_msand theexpires_atTTL 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.