E2EE

This document describes MME2EE Protocol 1.0 and the broader end-to-end encryption system used by Mullet Maters, including its protocol architecture, cipher suite, threat and trust models, identity authentication, message encryption and franking, encrypted push notifications, security properties, and known limitations.

MME2EE Protocol: 1.0

MMCV: 0x0001_0000

Cipher suite: 1

Protocol revision: 0

Contents

1. Purpose and scope
2. What Mullet Maters means by end-to-end encryption
3. MME2EE, MMCV, cipher suites, and protocol revisions
4. Security philosophy and threat model
5. System model and trust boundaries
6. The OpenPGP connection
7. Protocol overview
8. Identity authentication and verification
9. Message franking
10. Encrypted push notifications
11. What Mullet Maters can and cannot see
12. Security properties
13. Known limitations and non-goals
14. Compromise analysis
15. Implementation notes
16. Protocol evolution
17. Security research
18. Glossary
19. References

1. Purpose and scope

Mullet Maters (MM/M.M.) encrypts chat messages end-to-end. The purpose of this document is to describe what that statement means, how the cryptographic system is constructed, what assumptions it relies upon, and — most importantly — where its protections stop.

This is not intended to be a line-by-line implementation manual. The client implementation is open source and remains the authoritative reference for implementation details. Instead, this document focuses on the parts of the system that matter when evaluating its security:

• what assets the protocol is designed to protect;
• which parties possess which keys;
• how a conversation encryption key is established and distributed;
• how messages are encrypted;
• how public identity keys are authenticated;
• how users can independently verify those identities;
• what the Mullet Maters backend learns despite E2EE;
• how abuse reports can be authenticated without routine plaintext access;
• what happens when different keys, devices, or infrastructure components are compromised; and
• which properties the protocol deliberately does not provide.

The primary security objective of the current protocol is straightforward:

Mullet Maters infrastructure should not ordinarily possess the information required to reconstruct chat-message plaintext.

That is a narrower goal than “perfectly private messaging.” Mullet Maters does not claim metadata privacy, anonymity, forward secrecy, post-compromise security, protection from a compromised endpoint, or protection from a recipient who chooses to disclose a message. Those distinctions are central to this document rather than footnotes to it.

The current design also reflects the product it protects. Mullet Maters is a dating application in which conversations are normally created between users who begin as strangers. That fact materially affects identity verification, metadata requirements, safety tradeoffs, and the practicality of out-of-band security-code comparison. See Identity authentication and verification and Known limitations and non-goals.

2. What Mullet Maters means by end-to-end encryption

For Mullet Maters chat, the cryptographic endpoints are the participants' devices.

A message is encrypted on the sending device before it is submitted to Mullet Maters. Mullet Maters stores and relays ciphertext. The intended recipient's device obtains the relevant conversation key and decrypts the message locally.

At a high level:

      Alice's device                Mullet Maters infrastructure                 Bob's device
    ┌────────────────┐            ┌──────────────────┐             ┌────────────────┐
    │ plaintext      │            │                  │             │                │
    │ "hey cutie :)" │            │                  │             │                │
    └───────┬────────┘            │                  │             │                │
            │ encrypt             │                  │             │                │
            ▼                     │                  │             │                │
    ┌────────────────┐            │                  │             │                │
    │ ciphertext     │───────────►│ ciphertext       │────────────►│ ciphertext     │
    └────────────────┘            │ + metadata       │             └───────┬────────┘
                                  │                  │                     │ decrypt
                                  └──────────────────┘                     ▼
                                                                     ┌────────────────┐
                                                                     │ plaintext      │
                                                                     │ "hey cutie :)" │
                                                                     └────────────────┘

The Mullet Maters backend participates in routing, storage, key-directory functions, identity-key attestation, conversation-state validation, message franking, and push delivery. It is therefore very much part of the messaging system. It is not, however, intended to be a plaintext endpoint for chat content.

This distinction is important. E2EE does not mean that the server is uninvolved, that the server sees nothing, or that the server cannot interfere with communication. It means that the confidentiality of chat content is constructed so that the server does not normally hold the decryption secrets required to recover that content.

There are explicit exceptions to “Mullet Maters does not receive plaintext” at the application boundary. Most notably, a user may voluntarily disclose message plaintext when filing a report. See Message franking. Likewise, plaintext necessarily exists on participant devices after decryption. E2EE cannot prevent a recipient, malware on an endpoint, an unlocked device, or the operating system itself from obtaining plaintext available at that endpoint.

3. MME2EE protocol versions, MMCV, cipher suites, and protocol revisions

Mullet Maters refers to a complete version of its end-to-end encryption protocol using a dotted MME2EE Protocol version.

The two components of an MME2EE Protocol version correspond directly to the cipher suite and protocol revision used by that construction:

MME2EE Protocol 1.0
                │ │
                │ └── Protocol Revision 0
                └──── Cipher Suite 1

Accordingly:

MME2EE Protocol 1.0  =  Cipher Suite 1, Protocol Revision 0
MME2EE Protocol 1.1  =  Cipher Suite 1, Protocol Revision 1
MME2EE Protocol 2.0  =  Cipher Suite 2, Protocol Revision 0

The dotted form is human-readable terminology for the complete protocol construction. It resembles conventional software versioning but does not use semantic-versioning semantics: the two components correspond directly to the cipher-suite and protocol-revision identifiers.

For encoding and storage, Mullet Maters represents the same version using MMCV, or Mullet Maters Crypto Version.

MMCV is an unsigned 32-bit value divided into two 16-bit fields:

 31                    16 15                      0
+------------------------+------------------------+
|      Cipher Suite      |    Protocol Revision   |
+------------------------+------------------------+

The upper 16 bits identify the cipher suite. The lower 16 bits identify the protocol revision implemented using that suite.

The human-readable and encoded forms therefore map directly:

MME2EE Protocol 1.0  =  MMCV 0x0001_0000
MME2EE Protocol 1.1  =  MMCV 0x0001_0001
MME2EE Protocol 2.0  =  MMCV 0x0002_0000

This document describes:

MME2EE Protocol 1.0 — MMCV 0x0001_0000

A cipher-suite change means that one or more cryptographic primitives or security-critical suite parameters have changed. A protocol revision allows security-relevant protocol behavior to evolve while retaining the same cipher suite.

A change to an algorithm, domain-separation context, key size, or other frozen suite parameter must not silently reuse the same cipher-suite identifier. Likewise, a protocol behavior change that affects compatibility must not silently masquerade as the same protocol revision.

3.1 Cipher Suite 1

Cipher Suite 1 specifies the following cryptographic algorithms and security-critical parameters.

Algorithms

Parameters

The implementation uses distinct Suite-1-specific context strings to domain-separate the relevant key-derivation, hashing, authentication, and AEAD constructions. The exact context strings are part of the cipher-suite implementation and are defined identically where the corresponding construction crosses the client/server boundary.

Canonical security-sensitive integer encodings are big-endian where explicitly serialized.

3.2 MME2EE Protocol 1.0

MME2EE Protocol 1.0 is the static-key, conversation-DEK construction described throughout this document. It does not implement a Double Ratchet, ratchet tree, per-message key evolution, post-quantum key agreement, or a key-transparency system.

These omissions and their security consequences are discussed directly in Known limitations and non-goals.

4. Security philosophy and threat model

4.1 The primary goal of E2EE on Mullet Maters

MME2EE Protocol 1.0 is primarily concerned with keeping chat-message plaintext exclusively between the participants in a conversation. (End-to-end encrypted push notifications is an additional concern that largely falls out of this primary concern as a natural privacy extension.)

Mullet Maters' starting principle is that the contents of a dating conversation should be available to its participants, not to the platform carrying it or any other party. Mullet Maters therefore does not retain the cryptographic material required to reconstruct message plaintext. Except when a user voluntarily discloses message plaintext to MM, such as when filing a report, Mullet Maters is not intended to have access to the contents of users' conversations.

This design also limits the consequences of infrastructure compromise. A database disclosure, storage leak, routine server access, or compromise of infrastructure that possesses only stored conversation records and message ciphertext does not provide the private endpoint key material required to reconstruct message plaintext.

These properties address the same underlying risk from two directions: Mullet Maters should not ordinarily possess users' conversation plaintext, and compromising infrastructure that does not possess plaintext should not transform Mullet Maters into a repository from which that plaintext can be recovered.

Dating conversations can contain unusually intimate information. Mullet Maters' E2EE architecture is designed around the premise that those conversations belong to their participants.

4.2 Threats that are within scope

The protocol is designed to provide useful protection against, among other things:

• passive network observation of chat content;
• disclosure of stored server-side message records;
• disclosure of sealed conversation-key records without the corresponding endpoint identity private keys;
• a network attacker attempting to substitute an unauthenticated public identity key;
• identity-key substitution detectable by participants through out-of-band comparison of Mullet Maters security codes;
• accidental or unauthorized routine server-side plaintext access;
• tampering with authenticated portions of message ciphertext;
• rollback or malformed conversation-key state that conflicts with locally retained trusted state;
• unexpected changes to previously trusted endpoint identity or conversation-key state; and
• push-provider access to the protected contents of Mullet Maters' sealed notification envelope.

The precise guarantee depends on which component is compromised. “The server is compromised” is too imprecise to be a useful security statement. A database export, a backend process compromise, compromise of Mullet Maters' identity-attestation signing authority, compromise of a device, and compromise of a participant's long-term identity key are different events with different consequences. See Compromise analysis.

4.3 Threats that remain knowingly unsolved

The current protocol does not attempt to provide complete protection against:

• a compromised or unlocked participant device;
• a malicious recipient who can legitimately read a message;
• screenshots, copying, photography, screen recording, or voluntary disclosure;
• metadata observation by MM;
• traffic analysis;
• denial of service, message withholding, or guaranteed delivery;
• forward secrecy;
• post-compromise security / automatic cryptographic self-healing;
• post-quantum confidentiality / harvest now, decrypt later (HNDL) attacks;
• automatic first-contact detection of a malicious server that can mint valid Mullet Maters identity-key attestations;
• proof that an Mullet Maters profile corresponds to a particular real-world human being; or
• the behavior of arbitrary code executing inside a trusted endpoint process.

Some of these are inherent boundaries of E2EE. Others are deliberate v1 scope decisions.

4.4 MME2EE Protocol 1.0 deliberately uses a simpler security model

Modern secure-messaging protocols can provide security properties beyond basic end-to-end confidentiality. Protocols such as the Signal Protocol and Messaging Layer Security (MLS) evolve cryptographic key material over time to provide properties including forward secrecy and post-compromise security.

MME2EE Protocol 1.0 does not provide those properties. It uses long-term X25519 identity keys, derived conversation KEKs, and conversation-scoped symmetric DEKs rather than a continuous ratcheting or epoch-based key-evolution protocol designed to provide forward secrecy and post-compromise security.

This is a deliberate simplification of the protocol and its state management, with corresponding security tradeoffs. The consequences of long-term identity-key compromise, conversation-DEK compromise, endpoint compromise, and the absence of forward secrecy and post-compromise security are described explicitly later in this document.

That design choice is informed in part by Mullet Maters' application model. Conversations on a dating platform are generally expected to have a shorter useful lifetime than message histories in general-purpose messaging applications, reducing—but not eliminating—the value of secrecy properties designed to limit exposure across long-lived message histories.

Mullet Maters is also a dating app first and an E2EE messaging platform second. There is little to no established precedent within the dating-app category for how E2EE should be implemented in practice, how it should interact with the broader product and safety model, or which security properties such an implementation should be expected to provide. MME2EE Protocol 1.0 therefore favors a comparatively small, inspectable construction with OpenPGP-like security properties over introducing a substantially more complex ratcheting system before Mullet Maters has operational experience demonstrating that such complexity is warranted.

This is not a claim that forward secrecy or post-compromise security are unimportant. They are ordinarily desirable security properties that MME2EE Protocol 1.0 knowingly does not provide, and future revisions may adopt stronger key-evolution mechanisms without changing the security claims made for MME2EE Protocol 1.0.

5. System model and trust boundaries

The important parties are:

• Alice and Bob, representing conversation participants and their devices;
• Mullet Maters application infrastructure, which authenticates accounts, stores records, validates conversation state, routes messages, and performs server-side cryptographic support functions;
• Mullet Maters identity-attestation signing authority, backed by Google Cloud KMS and rooted in public keys pinned into the client;
• push infrastructure, including FCM and APNs; and
• the local operating environment on each participant device.

A simplified trust map looks like this:

                               ┌────────────────────────────┐
                               │ M.M. attestation authority │
                               │ P-256 signing key(s)       │
                               └─────────────┬──────────────┘
                                             │ attests public IKs
                                             ▼
┌────────────────────┐               ┌─────────────────────────┐               ┌────────────────────┐
│ Alice's device     │               │ M.M. backend / storage  │               │ Bob's device       │
│                    │               │                         │               │                    │
│ Alice IK private   │◄─ public IKs ─┤ public IK directory     ├─ public IKs ─►│ Bob IK private     │
│ conversation DEK   │               │ sealed DEK wrappers     │               │ conversation DEK   │
│ message plaintext  │── ciphertext ►│ message ciphertext      │── ciphertext ►│ message plaintext  │
│ local encrypted DB │               │ routing + metadata      │               │ local encrypted DB │
└────────────────────┘               │ franking service        │               └────────────────────┘
                                     └───────────┬─────────────┘
                                                 │ sealed push envelope
                                                 ▼
                                        ┌─────────────────┐
                                        │ FCM / APNs      │
                                        │ routing layer   │
                                        └─────────────────┘

The private identity keys and recovered conversation DEKs are endpoint secrets. The backend stores public identity keys, attestations, sealed conversation DEKs, ciphertext, and metadata needed to operate the application.

The attestation authority deserves separate treatment from ordinary storage because possession of identity-signing authority materially changes the attacker's capabilities. A database attacker who cannot forge an attestation is not equivalent to a malicious system capable of minting a new apparently legitimate identity key for a user.

6. The OpenPGP connection

Mullet Maters does not implement the OpenPGP wire format, packet types, certificate model, signatures, or keyring semantics. “Based on OpenPGP” should therefore not be read as “Mullet Maters messages are OpenPGP messages.”

The relationship is architectural.

OpenPGP uses hybrid encryption: message content is encrypted with symmetric key material, and that symmetric key material is then protected for each recipient using public-key cryptography. In modern OpenPGP terminology, a random session key is generated for an encrypted object, the object is symmetrically encrypted, and the session key is protected for the recipient or recipients.

Conceptually:

OpenPGP-style hybrid encryption

     plaintext object
           │
           │ encrypt with random session key K
           ▼
     encrypted object

     K ── encrypted/protected for Alice ──► Alice
     K ── encrypted/protected for Bob   ──► Bob

Mullet Maters adopts that broad pattern but changes the lifetime of the symmetric key.

Instead of generating a new session key for every chat message, Mullet Maters creates a random conversation data-encryption key (DEK) for a conversation epoch. That DEK is protected separately for each participant. Individual messages in that epoch are then independently AEAD-encrypted under the shared conversation DEK using independent nonces and message-specific authenticated context.

MME2EE Protocol 1.0

                    random conversation DEK Kc
                              │
                 ┌────────────┴────────────┐
                 │                         │
                 ▼                         ▼
        sealed for Alice            sealed for Bob
        using Alice/Bob             using Alice/Bob
        identity agreement          identity agreement
                 │                         │
                 ▼                         ▼
              Alice                      Bob

     msg 1 ── AES-GCM(Kc, nonce 1, AAD 1) ──► ciphertext 1
     msg 2 ── AES-GCM(Kc, nonce 2, AAD 2) ──► ciphertext 2
     msg 3 ── AES-GCM(Kc, nonce 3, AAD 3) ──► ciphertext 3

The useful shorthand is therefore:

Mullet Maters uses an OpenPGP-inspired hybrid-encryption model, but moves the symmetric “session” key up from the message level to the conversation-epoch level.

That choice is central to both the simplicity and the limitations of the system.

A conversation DEK can be rotated. Rotation creates a new independent DEK and increments the conversation DEK epoch. It does not create a per-message ratchet, and it should not be confused with forward secrecy. See No forward secrecy and No post-compromise security.

7. Protocol overview

This section describes the protocol at the level necessary to understand the security model. It intentionally omits many DTO, storage, and UI details that are better inspected in source.

7.1 Long-term identity keys

Each user has a long-term X25519 identity key pair:

Alice:  (IK_A_private, IK_A_public)
Bob:    (IK_B_private, IK_B_public)

The private key is endpoint secret material. The public key may be distributed by Mullet Maters and is accompanied by an MM-issued attestation that binds the public key to a user identifier and identity-key epoch.

Identity-key epochs allow key replacement to be represented explicitly rather than silently mutating a key under the same version state.

7.2 Identity-key attestation

Mullet Maters' server-side attestation path constructs a canonical payload containing, at minimum:

• an identity-attestation domain-separation context;
• the user's Mullet Maters identifier;
• the identity-key epoch; and
• the public identity-key bytes.

A SHA-256 digest of that payload is signed with an ECDSA P-256 signing key managed through Cloud KMS. The client verifies the signature against an attestation root compiled into the application binary.

This establishes an important property:

A party that can modify network traffic but cannot mint a valid Mullet Maters attestation cannot simply replace Bob's public identity key with an arbitrary key and have an unmodified client accept it.

It does not establish that Mullet Maters itself could never issue a fraudulent attestation. That stronger case is discussed in Identity-key substitution by a mint-capable server.

7.3 Conversation creation

Assume Alice creates a conversation with Bob.

Alice obtains the current attested public identity keys for the participants and generates a fresh random 256-bit conversation DEK, Kc, for DEK epoch 0.

Alice and Bob's X25519 identity keys produce a static-static Diffie-Hellman shared secret:

Alice                                               Bob

IK_A_private                                        IK_B_private
     │                                                   │
     │ X25519 with IK_B_public       IK_A_public with X25519
     └──────────────────┐             ┌──────────────────┘
                        ▼             ▼
                         same DH secret
                              │
                              │ HKDF-SHA-256
                              │ + domain context
                              │ + both public IKs
                              │ + conversation ID
                              │ + DEK epoch
                              ▼
                        conversation KEK

The public identity-key bytes are canonically ordered in the HKDF context, so both endpoints derive the same KEK regardless of which endpoint is performing the calculation.

The conversation DEK itself is then AES-GCM sealed using that KEK. The wrapper's authenticated data binds the wrapper to:

• the intended holder identifier;
• the conversation identifier; and
• the conversation DEK epoch.

Each participant receives a sealed-DEK record appropriate to that participant. Mullet Maters stores those wrappers but does not receive the plaintext conversation DEK.

For two participants, the result can be understood as:

                         random Kc
                            │
              ┌─────────────┴─────────────┐
              │                           │
              ▼                           ▼
      Alice's sealed Kc            Bob's sealed Kc
      holder = Alice               holder = Bob
      epoch  = 0                   epoch  = 0
              │                           │
              └──────────┬────────────────┘
                         ▼
                   stored by M.M.

Mullet Maters stores the sealed wrappers. Alice and Bob can open their own wrapper
using their private identity key and the other participant's public identity key.

The same broad wrapper model can generalize to more participants, although participant count is a product/server policy concern and increases the number of endpoints that possess the shared conversation DEK.

7.4 Message encryption

Before a message is sent, the sending client recovers the conversation DEK from its sealed wrapper.

The plaintext encrypted by the message AEAD contains both:

• the user-visible message text; and
• the secret message-franking commitment key associated with that message.

The message is AES-GCM encrypted under the current conversation DEK. The message AEAD authenticates context that includes:

• sender identifier;
• message identifier; and
• conversation DEK epoch.

The nonce is carried separately from the ciphertext/tag on the wire.

Alice's device

"hey cutie :)"
      │
      ├── + secret franking commitment key
      ▼
┌────────────────────────────┐
│ encoded message plaintext  │
└─────────────┬──────────────┘
              │ AES-256-GCM
              │ key = conversation DEK
              │ AAD = sender + message ID + DEK epoch
              ▼
┌────────────────────────────┐
│ ciphertext + tag           │
│ nonce                      │
└─────────────┬──────────────┘
              │
              ▼
        M.M. stores/relays
              │
              ▼
          Bob's device
              │
              │ recover same conversation DEK
              │ verify/open AES-GCM
              ▼
        "hey cutie :)"

The server replaces client-asserted authorship and creation time with server-authoritative context when storing the message record. In particular, the stored sender identifier is derived from the authenticated caller and the stored creation timestamp is assigned by the server.

This matters for franking and sender attribution. The message AEAD by itself is not a digital signature from Alice. Participants in a conversation share the same conversation DEK. Mullet Maters therefore relies on the authenticated submission path together with the AEAD-bound sender identifier, rather than claiming signature-style non-repudiation between participants.

7.5 Conversation DEK rotation

The current conversation key can be rotated. Rotation creates a new random conversation DEK and a strictly greater DEK epoch, then replaces the participant wrappers with wrappers for that new epoch.

A client retaining a trusted local baseline performs forward-rotation checks, including monotonic epoch checks and validation that the new wrappers are structurally valid, usable, and tied to valid identity-key attestations.

Rotation is useful for compartmentalizing a disclosed conversation DEK. If only epoch 3's DEK is compromised and the endpoints remain trustworthy, replacing it with an independent epoch 4 DEK prevents the old DEK itself from decrypting epoch 4 messages.

Rotation is not forward secrecy. The wrapping KEK is still derived from long-term identity-key material. A later compromise of a long-term identity private key can have consequences for previously stored wrappers and therefore previously encrypted messages. See No forward secrecy.

8. Identity authentication and verification

E2EE is not useful if an attacker can silently replace the public keys that define the endpoints. Mullet Maters therefore separates several related concepts that are easy to conflate.

8.1 Attestation: “Mullet Maters issued this key binding”

An identity-key attestation says, roughly:

Mullet Maters' attestation authority signed a binding between this Mullet Maters user ID, this identity-key epoch, and this public identity key.

Clients do not obtain the attestation root of trust from the network. P-256 public roots are compiled into the signed application binary. Missing, malformed, unknown-root, or invalid attestations fail verification.

This is specifically useful against network and transport substitution. A hostile Wi-Fi network, rogue proxy, mis-issued certificate, or other party that can alter a server response but lacks Mullet Maters' signing authority cannot mint a replacement key that chains to the pinned root.

8.2 Local persistence and rollback resistance

Mullet Maters retains trusted conversation state locally. When a server copy of a conversation is encountered again, the client can compare it with the locally retained baseline.

The current implementation rejects or flags backward movement in security-relevant epochs and other invalid rotation states. Local persistence therefore provides useful protection against rollback of conversation-key state that conflicts with what the endpoint has already observed.

This should not be overstated into a stronger claim. MME2EE Protocol 1.0 deliberately permits legitimate forward identity-key and conversation-key rotation. A server with the ability to mint apparently valid higher-epoch identities is a different threat from a server merely replaying stale state. See Identity-key substitution by a mint-capable server.

8.3 Security codes: “are these the same cryptographic identities?”

Mullet Maters can derive a conversation security code from the participants' identity information.

The construction hashes a canonical, domain-separated representation of the participating identities using SHA-256. Participant entries are deterministically ordered and include both the identity owner identifier and public identity-key bytes. The resulting full SHA-256 digest is displayed as uppercase hexadecimal grouped into four-character blocks.

Two endpoints that are using the same set of cryptographic identities should independently derive the same code.

The comparison must be exact. “Almost the same” has no cryptographic meaning.

Security codes are the independent check that closes the trust loop around server-provided identity keys. If Alice and Bob compare the code through a channel Mullet Maters cannot manipulate and the codes match, a server-side identity substitution would be exposed by the mismatch it causes.

Security codes authenticate cryptographic identities, not biographies. A matching code does not prove that a profile photo, age, name, occupation, or other dating-profile claim is true. It proves that both endpoints are seeing the same relevant Mullet Maters identity-key material.

8.4 The dating-app problem with out-of-band verification

Out-of-band verification is unusually awkward in a dating application.

In many secure messengers, the participants already know one another. They may have an existing phone number, in-person relationship, previously trusted account, or another independent channel. The secure messenger is protecting an already-existing social edge.

A dating app often creates the social edge in the first place.

Alice and Bob may be strangers precisely because they met through Mullet Maters. Before trust develops, they may have no independent channel through which to compare a security code. Exchanging a phone number or outside social account creates a new identity link; meeting in person may be premature; and asking strangers to perform a security ceremony before saying hello is not a realistic universal defense.

That is a genuine limitation, not a UX problem that cryptographic terminology makes disappear.

Mullet Maters therefore makes security-code comparison available and meaningful without pretending that every pair of strangers will perform it. Automated key transparency could improve this situation at scale, but it is not part of MME2EE Protocol 1.0. See Key transparency is not provided.

9. Message franking

End-to-end encryption creates a moderation problem: if the service provider cannot routinely read messages, how can a recipient later prove that an abusive message was genuinely sent through the service?

Mullet Maters uses message franking to address that narrow problem.

The goal is not to give Mullet Maters a hidden decryption capability. The goal is to allow a recipient to voluntarily reveal a particular message later and allow Mullet Maters to verify that disclosure against cryptographic evidence created at send time.

9.1 Commitment creation on the sender

For each outgoing message, the sender generates a random 256-bit commitment key, Kf.

The client computes a commitment using HMAC-SHA-256 over the message plaintext and the commitment key under that commitment key:

commitment = HMAC-SHA256(Kf, plaintext || Kf)

The commitment is sent alongside the ciphertext. The secret Kf is included inside the E2EE-protected message plaintext so that the legitimate recipient obtains it only after decrypting the message.

9.2 Server franking tag

At relay time, Mullet Maters computes a separate HMAC under a server-held franking key. The server's franking payload binds the client commitment to server-authoritative message context including:

• authenticated sender ID;
• conversation ID;
• message ID; and
• server-recorded creation time.

Sender                     Mullet Maters server                         Recipient
  │                            │                                 │
  │ plaintext                  │                                 │
  │ Kf                         │                                 │
  │ commitment = HMAC(...)     │                                 │
  │                            │                                 │
  │ ciphertext + commitment ─► │                                 │
  │                            │ stamp commitment + context      │
  │                            │ with server franking HMAC       │
  │                            │                                 │
  │                            ├── ciphertext + commitment + ───►│
  │                            │   server franking tag           │
  │                            │                                 │
  │                            │                  decrypts text + Kf

The server does not need the message plaintext or Kf to create this relay-time tag.

9.3 Voluntary report

If the recipient later reports the message, the recipient can disclose the plaintext and commitment key. Mullet Maters can then verify two things:

1. the server franking tag proves that Mullet Maters stamped this exact commitment and authoritative message context at relay time; and
2. the disclosed commitment key opens the commitment to the disclosed plaintext.

This gives Mullet Maters a basis for authenticating voluntarily disclosed content without giving Mullet Maters routine access to unreported message plaintext.

9.4 What franking does not prove

Franking is not a complete moderation oracle.

It authenticates the reported message. It does not prove that the reporter supplied the complete surrounding conversation. A recipient may disclose one authentic message while withholding preceding or following messages that materially change its context.

MME2EE Protocol 1.0 does not cryptographically bind an entire message sequence into a report or prove completeness of the disclosed context.

Franking also should not be confused with a public digital signature. The server tag is an HMAC under an MM-held secret. Its purpose is server-side report authentication, not third-party non-repudiation.

Finally, the construction is inspired by the message-franking / committing-encryption literature, but this document does not claim that Mullet Maters' application-specific construction is formally identical to a particular published compactly committing AEAD scheme. The implemented construction should be evaluated on its actual operations and assumptions.

10. Encrypted push notifications

Push notification delivery ordinarily crosses infrastructure operated by Apple and/or Google to send messages to iOS based clients and/or Android based clients respectively. Though Mullet Maters does not currently support an Android based client, its push notifications cross Google infrastructure anyway as an implementation detail discussed further below. Mullet Maters uses a separate server-to-device encrypted envelope for notification payloads to prevent leaking an end-user's dating activity data.

Mullet Maters' current push-notification infrastructure uses Firebase Cloud Messaging (FCM — Google infrastructure) and the Apple Push Notification service (APNs). FCM is an Mullet Maters implementation choice used as part of the current notification-delivery pipeline; APNs is the Apple-operated infrastructure through which remote push notifications are ultimately delivered to Mullet Maters on Apple platforms.

Each device has an X25519 push key pair. When Mullet Maters needs to send a notification to that device, the server:

1. generates a fresh ephemeral X25519 key pair;
2. performs X25519 agreement with the device's public push key;
3. derives an AES-256-GCM key using HKDF-SHA-256;
4. encrypts the serialized Mullet Maters notification payload; and
5. sends the ciphertext, nonce, ephemeral public key, and MMCV through the push network.

M.M. backend                       FCM / APNs              M.M. device

fresh ephemeral X25519
       │
       ├─ DH(device push pub)
       │
       ├─ HKDF-SHA-256
       │
       └─ AES-256-GCM seal
              │
              ▼
       ┌───────────────┐
       │ sealed push   │──────────────► routing ──────────────►│
       │ envelope      │                                       │
       └───────────────┘                                       ▼
                                                       Notification Service
                                                       Extension opens with
                                                       device push private key

For chat-message notifications, the Mullet Maters notification subject contains the already encrypted Mullet Maters message record. The iOS Notification Service Extension does not display that message as plaintext merely because a push arrived. It attempts to use locally trusted conversation state and the relevant private identity key to decrypt and authenticate the message. If the locally stored conversation is corrupt or has a non-nominal security status, the extension declines to display the protected message content.

This push layer has a different trust purpose from chat E2EE. Mullet Maters itself constructs the notification envelope and therefore knows non-chat event data it legitimately already knows. The push envelope principally prevents the third-party push-delivery infrastructure from learning the protected contents carried inside that envelope.

MM-specific application metadata carried by the notification—including Mullet Maters user, conversation, message, and sender information—is contained within the encrypted envelope. FCM and APNs instead observe the delivery-layer information inherently required to route and operate push notifications, such as provider-specific device or registration tokens, delivery timing, payload size, and delivery behavior. These routing identifiers are push-provider identifiers, not Mullet Maters user IDs or other Mullet Maters application-level identifiers contained within the encrypted envelope.

Push providers can delay, suppress, or fail to deliver a notification. Push delivery is therefore an availability mechanism, not the source of truth for chat history. A delayed, suppressed, or failed push does not alter the underlying message cryptography.

11. What Mullet Maters can and cannot see

E2EE protects message content. It does not make the Mullet Maters backend blind to the operation of a dating service.

The distinction should be explicit.

This leads to an important sentence that should not be buried:

E2EE does not mean anonymous communication.

Mullet Maters knows that accounts interact because the dating application cannot currently match, authorize, route, rate-limit, moderate, or operate conversations without substantial metadata. MME2EE Protocol 1.0 does not attempt to hide that metadata from Mullet Maters.

Metadata can itself be sensitive. Knowing that two people matched, when they communicated, how frequently they communicated, and approximately how much data they exchanged can reveal meaningful information even when the message bodies remain secret.

That exposure is a deliberate v1 scope decision, not part of the E2EE claim.

12. Security properties

The properties below describe the intended behavior of MME2EE Protocol 1.0 under the assumptions stated elsewhere in this document.

12.1 Server-side ciphertext cannot be decrypted from stored server data alone

Mullet Maters stores message ciphertext, public identity keys, and sealed conversation DEK wrappers. It does not store the private identity keys required to derive the KEKs that protect those DEKs.

As a result, possession of Mullet Maters' stored server-side data is not sufficient to decrypt message history. An attacker who obtains the message database, public identity keys, and sealed DEK wrappers must additionally obtain relevant private identity-key material from an endpoint to recover the conversation DEKs and decrypt the corresponding messages.

This is the principal confidentiality property Mullet Maters' E2EE architecture is designed to provide: compromise or disclosure of stored Mullet Maters infrastructure does not, by itself, turn the platform's encrypted message history into a plaintext message archive.

12.2 Conversation-key wrappers are bound to context

The KEK derivation is domain-separated and incorporates both participating public identity keys, the conversation identifier, and the DEK epoch. The AES-GCM wrapper additionally authenticates holder identity, conversation identity, and epoch.

A wrapper is therefore not intended to be a context-free encrypted blob that can be freely transplanted between users, conversations, or epochs.

12.3 Message ciphertext is authenticated

AES-GCM authenticates the encrypted message payload and message AAD. Modification of the ciphertext, authentication tag, nonce-dependent sealed representation, or authenticated sender/message/epoch context should cause decryption to fail rather than silently produce modified plaintext.

This provides ciphertext integrity. It does not guarantee that the server delivered every message or delivered messages in the intended order.

12.4 Network-level identity-key substitution is constrained by pinned attestation roots

A network attacker that cannot use Mullet Maters' identity signing authority cannot create an arbitrary replacement identity key with a valid Mullet Maters attestation under a client-pinned root.

This moves trust for first-contact key acceptance away from TLS alone and into an application-level pinned signing root.

12.5 Rollback of already-observed conversation state is detectable in relevant cases

Locally retained trusted conversation state gives the client a baseline against which later server state can be reconciled. Backward DEK epochs, backward identity-key epochs, unchanged or otherwise structurally invalid rotation state, and malformed attestations can be surfaced as security failures rather than accepted silently.

12.6 Conversation-DEK compromise is compartmentalized by conversation and epoch

A conversation DEK is scoped to a particular conversation epoch. Possession of one DEK does not directly reveal the DEK for unrelated conversations, and a fresh independently generated DEK is not derived from the prior DEK.

That is useful compartmentalization. It is not forward secrecy against identity-key compromise.

12.7 Push providers do not receive the Mullet Maters notification payload in plaintext

The Mullet Maters notification object is placed inside a separate X25519/HKDF/AES-GCM envelope addressed to the device push key before being sent through FCM/APNs.

Push providers continue to receive routing and delivery metadata.

13. Known limitations and non-goals

This section is intentionally direct. A security design is easier to evaluate when its failure modes are stated as clearly as its successful cases.

13.1 No forward secrecy

MME2EE Protocol 1.0 does not provide forward secrecy.

Messages within a conversation epoch are encrypted with the same conversation DEK. More importantly, that DEK is protected by a KEK derived from long-term static X25519 identity keys.

This has two different consequences:

If a conversation DEK is compromised: all messages encrypted under that DEK are exposed, including stored earlier messages and future messages that continue using the same DEK. Rotating to a fresh independent DEK ends the usefulness of the old DEK for future epochs.

If a long-term identity private key is later compromised: the impact can extend beyond the current DEK epoch. An attacker who obtains historical sealed-DEK wrappers and the relevant counterpart public identity keys may be able to reconstruct historical KEKs and recover historical conversation DEKs associated with that long-term identity key.

That means DEK rotation is not “coarse-grained forward secrecy.” It limits the blast radius of a DEK leak, but it does not erase the historical consequences of later long-term identity-key compromise.

A ratcheting protocol achieves stronger secrecy-over-time properties by continually replacing and deleting key material such that current compromise does not automatically reveal old message keys. MME2EE Protocol 1.0 does not do that.

13.2 No post-compromise security / self-healing

MME2EE Protocol 1.0 also does not provide post-compromise security (PCS) in the ratcheting-messenger sense.

There is no per-message or periodic DH ratchet introducing fresh endpoint entropy into an evolving root chain.

Recovery depends on what was compromised:

• If only a conversation DEK was disclosed, rotating to a fresh independent conversation DEK can restore confidentiality for later epochs, assuming the endpoint identity keys and devices remain secure.
• If a long-term identity private key remains compromised, rotating only the conversation DEK is insufficient. New wrappers can still be vulnerable through the compromised identity-key relationship. Recovery requires replacing the compromised identity key and re-establishing conversation state under uncompromised key material.
• If the endpoint itself remains compromised, protocol-level key rotation cannot make that endpoint trustworthy while the attacker retains access to the new secrets.

This distinction is one reason this document avoids the vague phrase “key compromise” without specifying which key.

13.3 Identity-key substitution by a mint-capable server

This is the most important active-server limitation in the current identity model.

Pinned attestation roots stop an attacker who can modify network traffic but cannot mint a valid Mullet Maters attestation. They do not stop Mullet Maters' own signing authority — or an attacker controlling it — from issuing a fraudulent binding between a user's identifier and attacker-controlled identity-key material.

At first contact, the problem is fundamental: the client has no independently trusted prior identity key for the stranger it is meeting.

A sufficiently capable malicious backend with attestation-signing authority can potentially interpose attacker-controlled identity keys, construct conversation state consistent with those identities, and relay/re-encrypt traffic as a man in the middle.

What Alice believes:                       What is actually happening:

Alice  <-------------------->  Bob         Alice  <---->  M.M./MITM  <---->  Bob
            E2EE to Bob                            key A'             key B'

Alice verifies an M.M.-issued              Mullet Maters can mint apparently valid
attestation for "Bob".                     attestations for substituted keys.

Locally persisted state improves rollback resistance, but the current protocol permits legitimate forward key rotation. The supplied implementation does not justify a claim that local TOFU state, by itself, automatically detects every mint-capable forward substitution using apparently valid higher-epoch identity state.

The independent defense is the security code. A successful substitution changes the cryptographic identities and therefore changes the code. Users who compare the code through an independent channel can detect the discrepancy.

The practical limitation is that dating-app participants are often strangers and may not possess such a channel. See The dating-app problem with out-of-band verification.

13.4 Compromise of the attestation-signing authority

Compromise or malicious use of the Mullet Maters identity-attestation signing authority collapses the network-attacker model into the mint-capable-server model above.

Cloud KMS materially hardens the signing keys against direct extraction and provides a controlled signing boundary. That is valuable operational protection, but it is not a cryptographic proof that signing authority can never be misused.

Pinned public roots also do not help if the attacker can legitimately produce signatures under a still-trusted root.

13.5 Endpoint compromise is outside the E2EE guarantee

E2EE terminates at endpoints. Plaintext must exist there to be read.

An attacker controlling a participant device may obtain:

• displayed plaintext;
• locally stored plaintext-domain objects after local decryption;
• long-term private identity material if the endpoint protection around it is defeated;
• recovered conversation DEKs;
• message-franking commitment keys;
• security codes as displayed by the compromised client; and
• future messages as they are composed or decrypted.

Mullet Maters encrypts its local chat records before writing them to its local database using a device storage key. That is an additional at-rest control, but it does not turn a compromised endpoint into a safe endpoint.

This document does not claim, based on the supplied implementation set, a particular Secure Enclave or non-exportability guarantee for every local secret. Those claims depend on the secret-store implementation and device configuration and should be documented separately if relied upon.

Third-party code executing inside the application process is also an endpoint-security concern. Dependency auditing, binary analysis, keychain access controls, and runtime hardening may reduce that risk, but they are not properties created by the E2EE protocol itself.

The endpoint trust boundary necessarily includes the operating system and other privileged platform components on which Mullet Maters executes.

13.6 A legitimate recipient can disclose plaintext

E2EE prevents an intermediary from reading plaintext. It does not prevent the intended recipient from doing so — that is the point of delivering the message.

A recipient can:

• copy text;
• take a screenshot or photograph;
• record the screen;
• transcribe the message;
• show the device to another person;
• export information by another channel; or
• voluntarily disclose the message to Mullet Maters in a report.

No transport cryptography can revoke information already revealed to a legitimate recipient.

13.7 Key transparency is not provided

MME2EE Protocol 1.0 does not implement a public or auditable key-transparency log.

Key transparency can make targeted identity-key substitution harder to conceal by requiring key-directory state to be committed into an append-only or otherwise auditable structure, often with inclusion/consistency proofs and some mechanism for detecting equivocation.

Mullet Maters currently relies on pinned attestation roots, local state, explicit key epochs, and optional out-of-band security-code comparison instead.

A future transparency design could improve automated detection of mint-capable substitution, but deploying one correctly requires more than publishing a list of keys. Equivocation detection, auditing, client consistency, recovery, privacy, and operational availability all matter.

13.8 Metadata confidentiality is not a v1 goal

MME2EE Protocol 1.0 does not attempt to hide communication metadata from Mullet Maters.

Mullet Maters can observe conversation membership, sender and receiver relationships, message timestamps, traffic frequency, ciphertext sizes, read-state information, and the dating graph required to operate likes and matches.

This is not equivalent to message-content access, but it is sensitive information.

A dating application also differs structurally from a general-purpose messenger. The backend must know enough about the social graph to discover users, process likes, create matches, authorize conversations, enforce blocks, and operate safety systems. Broad server-side metadata confidentiality would therefore require changes to the architecture of the product itself, not merely additional encryption around message content.

That does not mean metadata exposure is all-or-nothing. Techniques such as sealed-sender-style message delivery, reduced metadata retention, and greater separation between routing information and persistent account or conversation state may be capable of reducing the amount of communication metadata available to Mullet Maters infrastructure without making the dating graph itself opaque.

Applying such techniques to a dating platform requires further research and nontrivial implementation work. It also raises product-specific questions about the appropriate balance between metadata privacy and the safety, abuse-prevention, accountability, rate-limiting, and authorization mechanisms expected of a dating application. Those tradeoffs deserve explicit consideration rather than assuming that a metadata-minimization design developed for a general-purpose messenger transfers unchanged to a dating platform.

For these reasons, broad metadata confidentiality is not a goal of MME2EE Protocol 1.0. Mullet Maters nevertheless remains interested in techniques that can meaningfully reduce metadata exposure without undermining the platform's safety model, and considers metadata minimization an area for continued protocol and platform research.

13.9 Message withholding and deletion are not cryptographically preventable

A malicious or unavailable server can refuse to deliver a message that a recipient has never seen.

The recipient cannot cryptographically prove the existence of an object it was never told existed. MME2EE Protocol 1.0 does not use a globally auditable append-only message log or per-message hash chain that would make all omissions evident.

Once a message has been received and retained locally, local persistence can prevent an ordinary later server response from simply erasing the recipient's local copy. That does not force the server to deliver unseen messages in the first place.

Availability and completeness are separate from confidentiality.

13.10 Message ordering metadata is not end-to-end authenticated

The server-recorded creation timestamp used for message ordering is server-side metadata and is not authenticated by the message AEAD.

A malicious server may therefore manipulate the apparent ordering of messages that an endpoint has not yet discovered.

Local persistence and record pinning constrain manipulation of previously observed history, but MME2EE Protocol 1.0 does not cryptographically authenticate conversation chronology.

13.11 Replay resistance has limits

Message identifiers are authenticated by the message AEAD, while server-side create semantics and local persistence prevent or deduplicate straightforward replay under the same identifier.

These mechanisms provide practical replay resistance, but MME2EE Protocol 1.0 does not maintain a cryptographic sequence or transcript hash proving that every participant observed one unique and complete message history.

13.12 Message AEAD is not sender non-repudiation

All participants in a conversation epoch possess the same conversation DEK. AES-GCM therefore proves possession of that shared DEK, not possession of a sender-exclusive signing key.

In normal operation, sender attribution is strengthened by Mullet Maters' authenticated RPC boundary: the server constructs the stored sender field from the authenticated caller, and that sender field must match the value authenticated inside the ciphertext AAD for decryption to succeed.

This is sufficient for the intended online service model, but it is not equivalent to every message carrying an independently verifiable digital signature from the sender.

Message franking provides a separate server-verifiable report-authentication mechanism. It also is not public non-repudiation.

13.13 Post-quantum protection is not provided

Cipher Suite 1 uses classical X25519 key agreement and classical P-256 signatures. It therefore does not provide post-quantum (PQ) security.

This leaves MME2EE Protocol 1.0 exposed to harvest now, decrypt later (HNDL) attacks. An adversary could retain encrypted Mullet Maters traffic or stored conversation-key wrappers today and attempt to recover their contents if a cryptographically relevant quantum computer (CRQC) capable of defeating the underlying classical public-key assumptions becomes available in the future.

MME2EE Protocol 1.0 does not use hybrid post-quantum key establishment. Future cipher suites could combine X25519 with a post-quantum key-encapsulation mechanism such as ML-KEM, allowing conversation-key protection to depend on both classical and post-quantum assumptions.

Mullet Maters is interested in post-quantum key establishment as an area for future protocol evolution. Compared with changes requiring fundamentally different conversation semantics or continuous key evolution, hybrid key establishment may fit relatively naturally into Mullet Maters' existing conversation-key architecture. Its adoption would nevertheless require appropriate algorithm and parameter selection, protocol design, compatibility and migration planning, and implementation review.

MMCV provides the versioning mechanism necessary to introduce such a cipher-suite change without altering the security claims made for MME2EE Protocol 1.0. No particular post-quantum algorithm, parameter set, or migration schedule is currently promised.

13.14 Human identity is not cryptographically proven

Mullet Maters identity attestations bind a public cryptographic key to an Mullet Maters account identifier. Security codes verify sets of cryptographic identities.

Neither proves that a person is who their dating profile claims they are.

Cryptographic identity, account identity, profile authenticity, photo verification, social trust, and physical-world identity are related but distinct problems.

13.15 More participants means more endpoints holding the same DEK

MME2EE Protocol 1.0 natively supports multi-participant conversations. A conversation uses one shared DEK, independently sealed for each authorized participant using that participant's identity-key relationship. Supporting more than two participants therefore does not require a different cipher suite or protocol revision.

The security tradeoff is a correspondingly larger attack surface and compromise blast radius. Each additional participant adds another endpoint that legitimately possesses the shared conversation DEK and plaintext. In this model, the number of endpoints capable of exposing conversation content grows approximately linearly with the number of participants.

This does not weaken the underlying cryptographic primitives; it increases the number of trusted endpoints on which the confidentiality of the conversation depends. Compromise or malicious behavior by any one participant can expose content protected by the shared DEK for the relevant epoch.

Mullet Maters does not currently expose group conversations as a product feature, but MME2EE Protocol 1.0 is already capable of supporting them. Mullet Maters is interested in introducing multi-participant conversations in the future, with the remaining work centered primarily on product behavior, participant-membership semantics, and user interface rather than a replacement of the underlying E2EE construction.

13.16 Push encryption does not hide delivery metadata or guarantee delivery

Mullet Maters' encrypted push envelope protects notification content and MM-specific application metadata from the third-party push-delivery infrastructure, but it cannot conceal delivery-layer metadata inherently exposed to that infrastructure.

FCM and APNs may observe provider-specific routing information, timing, payload size, and delivery behavior, and may delay, suppress, or fail to deliver a notification. See Encrypted push notifications.

14. Compromise analysis

The table below summarizes the intended consequences of several distinct compromise scenarios. “Historical plaintext” assumes the attacker also obtains relevant retained ciphertext/wrappers where required. “Future plaintext” means future content without an additional independent compromise after appropriate recovery.

This table intentionally avoids collapsing very different events into “E2EE broken.” A cryptosystem is easier to reason about when the compromised authority is named precisely.

15. Implementation notes

This section records a small number of implementation facts that materially affect the threat model without attempting to document the entire codebase.

15.1 Client-side chat persistence

Mullet Maters encrypts the locally persisted contents of conversation and message records before writing them to the chat database. The encryption key used for this purpose is maintained separately from the database as device-local key material.

This does not mean that the local chat database is encrypted in its entirety. A limited amount of operational metadata remains outside the encrypted record payload where needed to support local indexing and queries. For example, locally stored message records retain the conversation identifier and creation time as queryable database fields, while the message record itself is stored as encrypted data. Conversation records similarly retain limited query metadata outside their encrypted payload.

Local persistence therefore protects the substantive contents of stored conversation and message records, but does not attempt to conceal every piece of local database metadata.

As with E2EE itself, encryption at rest does not protect plaintext after it has been legitimately decrypted by a running Mullet Maters client. A sufficiently compromised endpoint may be able to observe plaintext or cryptographic key material while the application is using it.

15.2 Canonical encodings and domain separation

Security-sensitive constructions use explicit domain-separation contexts. Variable-length fields in canonical signed/MACed/KDF payloads are generally length-prefixed, and fixed-width security-sensitive integers are encoded in a defined byte order.

These details are intentionally left to the source implementation rather than exhaustively reproduced here. Changing frozen context bytes or canonical layouts can change derived keys or invalidate signatures/tags and is therefore a protocol compatibility event, not a cosmetic refactor.

15.3 Client verification of server-provided state

The Mullet Maters client attempts to avoid treating security-relevant server state as authoritative where that state can reasonably be verified independently. Among other checks, the client validates identity-key attestations, authenticated cryptographic records, supported protocol versions, key epochs, and relevant state transitions against locally retained information.

This does not make the client independent of the server or eliminate the server from the trust model. The precise boundary between server authority, client verification, and locally retained trust is implementation-specific and is better evaluated directly in the open client source code.

15.4 Client security status

The client maintains an explicit security status for locally persisted conversations. The current implementation distinguishes:

• nominal
• ikRotationDetected
• rollbackDetected
• ikAttestationInvalid
• integrityLoss
• pinnedRecordCorruption

Non-nominal security states are surfaced to the user through the client interface rather than being treated solely as internal diagnostic conditions, and require end-user acknowledgement before further interaction with the conversation. Conversation-DEK rotations are not considered security states requiring end-user acknowledgement, but are nonetheless surfaced within conversation message threads.

Not every security-relevant event indicates an attack. Identity-key rotation and conversation-DEK rotation can occur legitimately during normal operation. Nevertheless, unexpected key rotation or other changes to previously trusted cryptographic state can also be evidence of tampering or compromise. The client therefore treats such transitions as security-relevant and can surface them to the user even when the underlying event may have a legitimate explanation.

The exact conditions that produce each status, and the client's resulting behavior, are defined by the client implementation.

15.5 Server responsibilities are deliberately narrower than client responsibilities

The backend implementation performs identity-key attestation, conversation-state validation, message franking, storage/relay, and push-envelope sealing.

It does not perform the normal conversation-DEK unwrapping or message AES-GCM decryption path used by chat endpoints.

15.6 Source availability is part of the verification story

A cryptographic document cannot prove that deployed software does what the document claims. The implementation matters.

The Mullet Maters client implementation is open source. Mullet Maters is currently available only on iOS, making the published iOS client the authoritative reference for client-side implementation details. The complete Mullet Maters backend implementation is not currently open source or otherwise publicly available for source inspection. Mullet Maters may publish additional backend source in the future. For purposes of E2EE verification, however, the client is the more security-relevant implementation to expose because it contains the endpoint-side cryptographic operations responsible for key handling, message encryption and decryption, trust-state validation, and security-code verification. This means that some claims about client behavior can be compared directly against published source, while server-side behavior that is not represented in published source cannot be independently verified in the same way. The protocol and threat model should not be interpreted as proof that a closed server implementation behaves as described.

Mullet Maters therefore treats source availability, reviewability, pinned trust roots, reproducible/auditable build practices where available, and independent security research as complementary to the protocol description rather than substitutes for one another.

Security-code verification ultimately assumes that the client honestly computes and displays the code. If an endpoint binary is malicious, it can lie about what it sees. That is an endpoint/software-supply-chain problem rather than something a fingerprint formula can solve by itself.

16. Protocol evolution

MME2EE protocols are explicitly versioned so that changes to the protocol and its security properties can be distinguished from the constructions that preceded them.

The current protocol is:

MME2EE Protocol 1.0  =  MMCV 0x0001_0000
                             └─┬──┘ └─┬┘
                             suite 1  revision 0

A future change that retains Cipher Suite 1 but changes protocol behavior could become MME2EE Protocol 1.1, represented by MMCV 0x0001_0001.

A future construction that changes the cryptographic suite could become MME2EE Protocol 2.0, represented by MMCV 0x0002_0000.

MMCV therefore provides the encoded representation used by the implementation, while the corresponding dotted MME2EE Protocol version identifies the complete protocol construction in human-readable form.

The exact compatibility policy for a future version must be defined with that version. Clients should not infer compatibility merely because two versions share some primitives or a cipher suite.

Likewise, old ciphertext does not become magically stronger when a new protocol version ships. Historical data remains protected according to the protocol and key material under which it was created.

Potential areas for future work include, without commitment to a particular design:

• forward-secure / ratcheting message keys;
• post-compromise recovery;
• hybrid post-quantum key establishment;
• automated key-transparency mechanisms;
• stronger transcript consistency / ordering guarantees;
• further metadata-minimization research; and
• sealed senders.

Any such feature should be documented in terms of the security property it adds rather than simply described as “more encryption.”

17. Security research

Mullet Maters' E2EE design should be treated as something to inspect, challenge, and attempt to falsify.

Useful research questions include:

• Can a participant be induced to accept a DEK wrapper that violates the intended identity or epoch binding?
• Can a malformed or cross-context ciphertext be accepted under the wrong protocol operation?
• Can identity-key rotation or conversation rotation be manipulated into an undetected rollback or substitution?
• Can franking evidence be forged, opened ambiguously, or detached from authoritative message context?
• Can push envelopes be replayed or cross-bound in a way that causes protected content to be displayed incorrectly?
• Can server-controlled metadata cause the client to misattribute otherwise valid ciphertext?
• Are locally retained trust decisions weakened by cache loss, reinstall, account recovery, or migration behavior?
• Does any third-party code executing in the endpoint process gain access to cryptographic secret material outside the intended paths?

Security reports should identify the exact MMCV or MME2EE protocol and, where relevant, the app/backend revision tested. A finding against MME2EE Protocol 1.0 should not be generalized to a later MMCV without verifying that the relevant construction is unchanged.

Security contact: security@mulletmaters.app

18. Glossary

19. References

The references below provide background for the standards, protocol designs, and research discussed in this document. MME2EE Protocol 1.0 is defined by the Mullet Maters implementation and this document, not by importing the behavior or security properties of another protocol wholesale.

1. OpenPGP — RFC 9580. The OpenPGP standard's hybrid-encryption model is the architectural inspiration for Mullet Maters' use of symmetric content encryption plus per-recipient protection of symmetric key material.
   
   https://www.rfc-editor.org/rfc/rfc9580.html

2. The Double Ratchet Algorithm — Signal specifications. Background for the forward-secrecy and post-compromise-security properties discussed as contrasts to MME2EE Protocol 1.0.
   
   https://signal.org/docs/specifications/doubleratchet/

3. Messaging Layer Security (MLS) — RFC 9420. An IETF secure-messaging protocol providing forward secrecy and post-compromise security through evolving group cryptographic state. Referenced as another example of security properties not provided by MME2EE Protocol 1.0.
   
   https://www.rfc-editor.org/rfc/rfc9420.html

4. Paul Grubbs, Jiahui Lu, Thomas Ristenpart — “Message Franking via Committing Authenticated Encryption.” Background for the problem of verifiable abuse reporting in end-to-end encrypted messaging.
   
   https://eprint.iacr.org/2017/664

5. Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM) — NIST FIPS 203. Standard defining ML-KEM, referenced as a potential building block for future post-quantum key establishment.
   
   https://csrc.nist.gov/pubs/fips/203/final

6. Mullet Maters Client Source. The authoritative reference for the published client implementation, including current client-side byte layouts, state reconciliation, storage behavior, security-state handling, and endpoint cryptographic operations.
   
   https://github.com/lemmaturtles/mullet-maters-ios