1. Scope and threat model

mx.crypto is a thin R wrapper over the Olm + Megolm primitives in vodozemac. It sits beside mx.api (Matrix HTTP transport), and a higher-level package (eventually mx.client) is expected to compose the two into a real client. The threat model for the wrapper layer is narrow but load-bearing:

• A malicious homeserver can return anything in /_matrix/client/v3/keys/query, /_matrix/client/v3/keys/claim, or /_matrix/client/v3/sync. mx.crypto must not let those responses corrupt session state or silently leak plaintext.
• A compromised remote device can submit signed material that satisfies structural checks but originates from the wrong identity. mx.crypto cannot detect this on its own — identity pinning lives above this layer — but mx.crypto must at minimum expose verification primitives so callers can implement TOFU / cross-signing without rolling their own ed25519 glue.
• A buggy or hostile peer can ship malformed Olm / Megolm ciphertext or pre-key messages. mx.crypto must fail closed (clear error, no partial state mutation) rather than returning ambiguous values.

Out of scope for the wrapper: cross-signing, SAS verification, and the v2 MAC migration. Those land in a higher layer.

2. Dependency baseline: vodozemac 0.10.0

The Soatok post called out one high-severity issue and a handful of lower-severity issues. The high-severity issue is the one that matters most:

Olm Diffie-Hellman accepts the identity element. When this occurs, all three DH computations produce zero output, resulting in a predictable session key.

In vodozemac 0.10.0 the fix is already in place. The relevant code in the vendored crate (src/types/curve25519.rs:52) is:

/// Returns `None` if one of the keys does not show contributory behavior
/// resulting in an all-zero shared secret.
pub fn diffie_hellman(&self, their_public_key: &Curve25519PublicKey)
    -> Option<SharedSecret>
{
    let shared_secret = self.0.diffie_hellman(&their_public_key.inner);
    if shared_secret.was_contributory() { Some(shared_secret) } else { None }
}

Shared3DHSecret::new and RemoteShared3DHSecret::new propagate the None with ?. A dedicated regression test (triple_diffie_hellman_non_contributory_key) builds an all-zero remote one-time key and asserts that Shared3DHSecret::new returns None. Our pinned 0.10.0 ships that test and that fix.

Strict Ed25519 verification is also the default in 0.10.0 (src/types/ed25519.rs), with the laxer #[cfg(fuzzing)] form only compiled when the fuzzing Cargo feature is enabled. mx.crypto does not enable that feature in its build.

So the primitive is correct. The remaining question is whether mx.crypto correctly propagates the primitive’s results.

3. Surface map

Before 0.2.0 mx.crypto exposed 24 functions covering:

What was missing was any way to verify signatures. mxc_account_sign existed; nothing on the other side. That meant:

• /keys/query could return arbitrary attacker-chosen ed25519 + curve25519 keys for a target device and no caller could check the self-signature.
• /keys/claim could return OTKs signed under any ed25519 key the homeserver felt like and no caller could check.

0.2.0 adds three exports plus one internal Rust binding:

• mxc_ed25519_verify(public_key, message, signature) — thin vodozemac binding (uses verify_strict).
• mxc_verify_device_keys(device_keys, expected_user_id, expected_device_id, required_algorithms = NULL) — full structural + signature check for a /keys/query device entry. required_algorithms = NULL means “both Olm and Megolm” (i.e. m.olm.v1.curve25519-aes-sha2 and m.megolm.v1.aes-sha2); pass character(0) to skip the algorithms check.
• mxc_verify_one_time_key(algorithm_key_id, key_object, signing_ed25519, expected_user_id, expected_device_id) — same for a /keys/claim entry. algorithm_key_id is the outer "<algorithm>:<key_id>" map key from the claim response so the helper can reject anything but signed_curve25519.

Internal-only: mxc_curve25519_is_valid() is a Rust binding (not exported) used by mxc_verify_one_time_key to confirm the OTK’s key value really decodes to a 32-byte curve25519 public key, so a signed-but-malformed key cannot pass.

The two high-level helpers are pure R; they call mxc_ed25519_verify + mxc_curve25519_is_valid (Rust) and mx.api::mx_canonical_json (pure R) for the signed-bytes reconstruction.

4. Canonical JSON

mx.crypto does not implement canonical JSON itself — it consumes the output of mx.api::mx_canonical_json(), which was audited separately when those endpoints landed in mx.api 0.2.0. Key properties of that encoder (97-assertion test suite):

• Locale-independent key sort (UTF-8 byte order, radix sort).
• Integers only ([-(2^53)+1, (2^53)-1]), no floats, no exponents.
• Rejects NaN, Inf, NA, NA object keys, duplicate object keys.
• Non-ASCII passes through as raw UTF-8 bytes; control chars 0x01-0x1F use the spec-defined \b \f \n \r \t named escapes or \u-form.
• I() forces array encoding (matches jsonlite).

The encoder is hand-rolled — not a jsonlite wrapper — because byte stability across implementations is the entire point. Letting another package’s default flags drift would silently break signature verification across clients.

5. Finding (HIGH): mxc_olm_create_outbound swallowed SessionCreationError

vodozemac’s Account::create_outbound_session has this signature:

pub fn create_outbound_session(
    &self,
    session_config: SessionConfig,
    identity_key: Curve25519PublicKey,
    one_time_key: Curve25519PublicKey,
) -> Result<Session, SessionCreationError>

The Result::Err(SessionCreationError::NonContributoryKey) variant is exactly how the vodozemac fix surfaces the “remote key is all zeros” case to the caller. mx.crypto’s wrapper, however, looked like this:

fn mxc_olm_create_outbound(...) {
    let sess = acct.create_outbound_session(SessionConfig::version_1(), id_key, otk);
    RExternalPtr::encode(sess, TAG_OLM_SESSION, pc)
}

RExternalPtr::encode<T> is generic; it happily boxed a Result<Session, _> into an external pointer that R hands back to the caller, with the external-pointer tag claiming it was a Session. Downstream code (mxc_olm_encrypt, mxc_olm_decrypt) then did ext.decode_mut::<Session>() and used those bytes as if they were a Session. That is undefined behavior in the Rust type-system sense. In practice it “worked” on the happy path because of niche-layout coincidences between Result<Session, _> and Session; on the error path it produced unpredictable behavior.

library(mx.crypto)
acct <- mxc_account_new()
zero <- jsonlite::base64_enc(as.raw(rep(0, 32)))  # 32-byte zero key
sess <- mxc_olm_create_outbound(acct, zero, zero)
class(sess)
#> [1] "externalptr"               <-- no error raised
mxc_olm_encrypt(sess, charToRaw("hi"))
#> *** R hangs / aborts / returns garbage ***

let sess = acct
    .create_outbound_session(SessionConfig::version_1(), id_key, otk)
    .stop_str(
        "create_outbound_session failed (e.g. non-contributory \
         Diffie-Hellman key)",
    );
RExternalPtr::encode(sess, TAG_OLM_SESSION, pc)

library(mx.crypto)
acct <- mxc_account_new()
zero <- jsonlite::base64_enc(as.raw(rep(0, 32)))
mxc_olm_create_outbound(acct, zero, zero)
#> Error: create_outbound_session failed (e.g. non-contributory
#> Diffie-Hellman key)

6. Finding (HIGH): no signature-verification primitive

Before 0.2.0 the demo at inst/integration/e2e_demo.R (and any other caller) treated the homeserver’s /keys/query and /keys/claim responses as ground truth — every signature returned in those responses went unchecked. mx.crypto’s threat model documented “trust the caller’s identity-pinning layer,” but the caller could not actually do that work because mx.crypto did not expose ed25519 verification.

#[roxido]
fn mxc_ed25519_verify(public_key_b64: &str, message: &RObject, signature_b64: &str) {
    let pk = Ed25519PublicKey::from_base64(public_key_b64)
        .stop_str("invalid ed25519 public key (base64)");
    let sig = Ed25519Signature::from_base64(signature_b64)
        .stop_str("invalid ed25519 signature (base64 / length)");
    let msg = raw_bytes(message);
    let ok = pk.verify(msg, &sig).is_ok();
    ok.to_r(pc)
}

7. DH / session error propagation (full pass)

Recap of section 5 with a wider lens. mx.crypto’s R-side error handling on the happy path is straightforward — .Call(.mxc_*) errors propagate as R simpleErrors. The risk is silent corruption: returning what looks like a valid externalptr/value when the underlying primitive errored. Confirmed: post-fix, every fallible vodozemac call surfaces its error as a clean R error before any external-pointer is handed back. No partial-state mutation paths remain.

8. Pickle and local state

mxc_*_pickle() takes a caller-supplied 32-byte raw vector. The pickle format encrypts the serialised account/session state under that key. Behavior:

• Wrong key: mxc_*_unpickle() errors cleanly (already covered by test_account.R).
• Corrupted blob: errors at decryption.
• Right key, wrong tag (e.g. an Olm session pickle handed to mxc_megolm_inbound_unpickle): errors at deserialization.

Spec caveat: vodozemac’s pickle uses a deterministic IV. The implication is that reusing the same pickle key across pickles can leak ordering information. The recommended discipline is one pickle key per Account / Session, which is what callers should do anyway for separation-of-concerns reasons. This is now stated in SECURITY.md.

9. Other Soatok findings, mapped to our pin

10. API boundary with mx.api

mx.crypto deliberately does not depend on mx.api for runtime crypto — Suggests only, used by mxc_verify_device_keys / mxc_verify_one_time_key to canonicalize signed payloads. The bright line:

• mx.api knows about HTTP and JSON; it does no signature work.
• mx.crypto knows about ed25519, curve25519, Olm, Megolm; it does no HTTP work.
• A higher layer (eventually mx.client) is expected to thread them together with identity pinning, key storage, and the broadcast / receive loop.

The integration demo at inst/integration/e2e_demo.R is a working example of that thread. With these audit fixes in place, the demo should also use the new verify helpers before opening Olm sessions — that follow-up is captured in section 11.

11. Pending follow-ups

Not in scope for this audit; tracked for later versions.

• Wire mxc_verify_device_keys + mxc_verify_one_time_key into the e2e_demo.R broadcast loop so the demo reflects best practice.
• TOFU / cross-signing helpers (master / self / user signing keys).
• SAS verification (m.key.verification.start etc.).
• v2 Olm MAC migration when the Matrix spec lands.
• Track upstream vodozemac for any future disclosures and pull the changelog into NEWS.md on each bump.

12. Verification

Build + test results from this audit branch:

Changelog

mx.crypto 0.2.0:

• HIGH: mxc_olm_create_outbound now propagates SessionCreationError (previously swallowed; non-contributory DH keys silently produced a corrupt session pointer).
• HIGH: Added mxc_ed25519_verify, mxc_verify_device_keys, mxc_verify_one_time_key so callers can validate /keys/query and /keys/claim responses before using them.
• SECURITY.md added.
• Vignette: this document.
• DESCRIPTION: bumped to 0.2.0; added mx.api (>= 0.2.0) and simplermarkdown to Suggests; VignetteBuilder: simplermarkdown.