mpENC Multi-Party Encrypted Messaging Protocol design document

TL;DR

This paper presents mpENC, a comprehensive protocol for secure end-to-end group messaging that integrates cryptographic security with transport-layer considerations, aiming for broad applicability and modularity.

Contribution

It introduces a unified, flexible protocol design that combines cryptography, transport-layer integration, and user interface considerations for secure group messaging.

Findings

Protocol supports reliable, consistent group messaging with end-to-end security.

Designed for reuse and extension across different messaging protocols.

Addresses both cryptographic and transport-layer challenges.

Abstract

This document is a technical overview and discussion of our work, a protocol for secure group messaging. By secure we mean for the actual users i.e. end-to-end security, as opposed to "secure" for irrelevant third parties. Our work provides everything needed to run a messaging session between real users on top of a real transport protocol. That is, we specify not just a key exchange, but when and how to run these relative to transport-layer events; how to achieve liveness properties such as reliability and consistency, that are time-sensitive and lie outside of the send-receive logic that cryptography-only protocols often restrict themselves to; and offer suggestions for displaying accurate (i.e. secure) but not overwhelming information in user interfaces. We aim towards a general-purpose unified protocol. In other words, we'd prefer to avoid creating a completely new protocol merely to support automation, or asynchronity, or a different transport protocol. This would add complexity to the overall ecosystem of communications protocols. It is simply unnecessary if the original protocol is designed well, as we have tried to do. That aim is not complete -- our full protocol system, as currently implemented, is suitable only for use with certain instant messaging protocols. However, we have tried to separate out conceptually-independent concerns, and solve these individually using minimal assumptions even if other components make extra assumptions. This means that many components of our full system can be reused in future protocol extensions, and we know exactly which components must be replaced in order to lift the existing constraints on our full system.