message_pickup.md

The xx network message pickup design

Benjamin Wenger
Richard T. Carback III
David Stainton

version 0

Abstract

Here we discuss some design details of the message transport and pickup.

Introduction

As was explained in the architectural overview, the XX Network is meant to be a general purpose mix network that can support a wide variety of applications. The clients connect directly to the gateways for all their network interactions.

The full end to end path looks like this:

Clients interact with a random Gateway in the network which in turn proxies outbound messages to the correct Gateway associated with the destination mix cascade. Currently mix cascades have five mix nodes and five Gateways, each mix node has a Gateway associated with it. The last mix node sends the mix cascade output messages to it's Gateway which in turn sends the messages to the rest of the mix cascade's Gateways for storage.

Messages are queued for up to three weeks in the gateway persistent message storage. Later on, the recipient client can retrieve their messages by interacting with any of the gateways.

Clients send their ephemeral recipient ID to the Gateway which responds with:

• known rounds
• bloom filter

Each gateway stores a KnownRounds buffer indicating for each round if they store messages for that round or not. The bloom filter is specific to the ephemeral recipient ID and indicates from which rounds the given ephemeral recipient ID received messages.

The client knows what rounds it has checked in the past. It finds the set exclusion between that list and known rounds. It then looks up all members of that exclusion in the bloom filter - which returns true if messages were received, false if they were not. If a message was received, the client gets the gateways associated with the round either from ram, or it isn't present asks any gateway. It then randomly chooses a gateway in the round and asks it for any messages received on the ephemeral recipient ID in that round which are returned to it.

The address space for ephemeral recipient IDs is intentionally small so as to create collisions such that multiple client would be making use of the same ephemeral recipient ID.

The client then analyzes the received messages and compares message IDs with deterministically generated message IDs so as to avoid trail decryption.

Pseudo Code Cryptographic Function Glossary

• |: byte concatenation

• H(x): H is a cryptographic hash function. Usually in our implementation this is Blake2b.

• Sign(private_key, payload): Returns a cryptographic signature.

• Verify(public_key, data, signature): Returns a boolean which will be true if the signature is a signature of data and is valid for the given public key.

The xx network Gateway wire protocol

• elixxir:comms/messages/messages.proto: Defines all of services and structures for the permissioning (registration), server, gateway, and clients in the cMix protocol.

The gateway service has the following gRPC service methods:

service Gateway {

    // RequestClientKey returns a Nonce to the user
    rpc RequestClientKey (SignedClientKeyRequest) returns (SignedKeyResponse) {
    }

    // PutMessage on the cMix Gateway
    rpc PutMessage (GatewaySlot) returns (GatewaySlotResponse) {
    }

    // PutMessage on the cMix Gateway
    rpc PutManyMessages (GatewaySlots) returns (GatewaySlotResponse) {
    }


    // Client -> Gateway unified polling
    rpc Poll (GatewayPoll) returns (stream StreamChunk) {
    }

    // Client -> Gateway historical round request
    rpc RequestHistoricalRounds(HistoricalRounds) returns (HistoricalRoundsResponse) {
    }

    // Client -> Gateway message request
    rpc RequestMessages(GetMessages) returns (GetMessagesResponse) {
    }

}

Sending messages

PutMessage or PutManyMessages are used by clients to send messages. The return values for these two methods indicates whether or not the messages were accepted into message slots of the specified rounds. For example if all message slots are filled then the return value indicates the message was not accepted and the client must resend to a different round.

Receiving messages

A bloom filter is returned as part of the stream and is used by the client to determine if an ephemeral message ID has a message delivered or not. The client may call RequestMessages with a set of message IDs that have been initially confirmed with the bloom filter.

Message ID Collisions

The message ID space is tuned intentionally to increase the probability of message ID collisions between clients. These collisions help protect against intersection attacks. Clients will retrieve multiple messages and in that sense each message ID represents a bucket of messages destined for multiple clients.

Clients check the hash at the end of the message, the identity fingerprint. If it matches their own identity fingerprint then the message can be processed with the cryptographic protocol described in our end to end protocol design document.