mushi

Crates.iomushi
lib.rsmushi
version
sourcesrc
created_at2025-03-26 00:29:44.197039+00
updated_at2025-03-27 22:30:14.153854+00
descriptionPoint-to-point QUIC networking with application-defined mutual authentication
homepage
repositoryhttps://github.com/passcod/mushi
max_upload_size
id1606016
Cargo.toml error:TOML parse error at line 18, column 1 | 18 | autolib = false | ^^^^^^^ unknown field `autolib`, expected one of `name`, `version`, `edition`, `authors`, `description`, `readme`, `license`, `repository`, `homepage`, `documentation`, `build`, `resolver`, `links`, `default-run`, `default_dash_run`, `rust-version`, `rust_dash_version`, `rust_version`, `license-file`, `license_dash_file`, `license_file`, `licenseFile`, `license_capital_file`, `forced-target`, `forced_dash_target`, `autobins`, `autotests`, `autoexamples`, `autobenches`, `publish`, `metadata`, `keywords`, `categories`, `exclude`, `include`
size0
Félix Saparelli (passcod)

documentation

https://docs.rs/mushi

README

Mushi 🫖🍵

WebTransport with mutual authentication.

What is this?

Iroh is peer-to-peer QUIC connections with peer-to-peer authentication based on ED25519 keys. Mushi is client-server QUIC connections with peer-to-peer authentication based on X.509 keys.

If you're not familiar, Iroh is this really neat project that offers the same kind of "it just works" networking as Tailscale, but embedded directly into applications, like you'd have TCP or HTTP. Iroh performs all the NAT traversal, hole-punching, port negotiation, discovery of peers, etc... and you get a super-simple Endpoint structure that you can talk to other peers with. The cryptography of Iroh is based on mTLS: each peer has an ED25519 keypair, and uses it both as a certificate and as a node identity. There's no PKI: an incoming connection presents its ED25519 public key, the TLS handshake makes sure it's authentic, and it's up to the application whether it trusts that key (and establishes the connection) or not.

Mushi came about when wanting something similar to Iroh, but in a context where the peer-to-peer bits were unnecessary (and in fact counter-productive), and where web PKI was inappropriate, yet an application-defined trust model with mutually-authenticated peers was more desirable. Additionally, with discovery and other details unused, it became easier to be flexible on the cryptography suite: Mushi works with anything that TLS 1.3 does, such as ECDSA, rather than being restricted to ED25519.

In the end, Mushi is:

  • QUIC
  • with short-lived self-signed certificates on both client and server sides
  • from persistent (long-lived) keypairs
  • wrapped in the WebTransport API

On connection establishment, an Endpoint receives the DER-encoded Public Key Information block of the other side, and can use that as an opaque identity blob for the remote peer. That structure contains both the public key data and an algorithm specifier, which lets applications choose from ECDSA or ED25519 as is more convenient. (RSA is not allowed.)

How do I use this?

Mushi is a Rust crate (docs), with some foreign interfaces for convenience:

Mushi is also nothing special: as long as you have TLS-level control for your WebTransport implementation, you can play along. Require client certificates, don't validate against web PKI, match public keys instead, and prefer issuing short-lived certificates on the fly.

🧋

Commit count: 0

cargo fmt