Skip to content

Issue R: Deprecated Hex Encoding for KeyPackage Content Enables Downgrade and Interop Failures #61

@erskingardner

Description

@erskingardner

Location

crates/mdk-core/src/key_packages.rs#L48

crates/mdk-core/src/groups.rs#L1265

Synopsis

The functions create_key_package_for_event and build_welcome_rumors_for_key_packages emit hex-encoded content and omit the encoding tag, which contradicts MIP-00 and MIP-02 and enables downgrade and parsing ambiguity across clients.

Impact

Medium.

An attacker can strip or omit the encoding tag or craft ambiguous content so that different clients decode different bytes, which may cause state divergence, denied group joins, or acceptance of noncompliant artifacts.

Feasibility

High.

An attacker must only have the ability to publish a key package or Welcome event or strip the encoding tag in transit. No special privileges are required.

Severity

High.

Preconditions

For this issue to occur, the following must hold true:

  • A client or relay must be able to submit a key package (kind-443) or Welcome (kind-444) event without the encoding tag;
  • At least one validating peer must follow MIP-00 or MIP-02 formatting expectations; and
  • Content that is valid in both hex and base64, or events where the encoding tag is omitted, must be present.

Technical Details

The function create_key_package_for_event selects encoding via self.config.use_base64_encoding. When false (the default), it uses ContentEncoding::Hex and does not add an encoding tag, while only base64 adds TagKind::Custom("encoding") with value "base64." The function build_welcome_rumors_for_key_packages mirrors this behavior for Welcome events. The function parse_key_package derives the format using ContentEncoding::from_tags, which defaults to hex if the tag is absent, and then calls the function parse_serialized_key_package, which decodes with the function decode_key_package_content before TLS deserialization.

An adversary can craft a kind-443 or kind-444 event containing hex content and omit the encoding tag, or a relay can remove the tag, leading to rejection by strict clients or inconsistent decoding paths. Strings valid in multiple encodings exacerbate parsing ambiguity and lead to denial of service.

Remediation

We recommend replacing the hex default and implicit behavior with mandatory base64 emission along with an explicit encoding tag, and using strict validation in the create_key_package_for_event and build_welcome_rumors_for_key_packages functions.

Status

Reported.

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions