# Boomerang Encryption

A core challenge in a mix-net is ensuring that all envelopes get to the appropriate server on the path. A user complaining of protocol deviation (e.g., dropped messages) runs the risk of deanonymization. Boomerang encryption—a simple extension of onion encryption solves this problem by providing “receipts” that can be used by servers to anonymously blame on a user’s behalf. Boomerang encryption is designed to (1) ensure that all servers on a path receive messages addressed to them and (2) allow honest servers to trace the source of active attacks and assign blame accordingly.

<figure><img src="/files/p6mjW88WDJ9j1nmvRSqc" alt=""><figcaption></figcaption></figure>

### Boomerang encryption and routing

Onion routing works in one “direction:” routing envelopes *forward* through the chain of servers such that only the destination server learns the plaintext message. In contrast, boomerang routing is bidirectional: it applies onion encryption *twice*, once in the forward direction and once in reverse (hence the name, *boomerang*). If we define reverse-onion encryption as:

$$
\overleftarrow{\text { onion }}(\mathbf{s k}, m):=\operatorname{Enc}*{\mathbf{s k}*{\ell}}\left(\operatorname{Enc}*{\mathbf{s k}*{\ell-1}}\left(\ldots \operatorname{Enc}*{\mathbf{s k}*{1}}(m) \ldots\right)\right)
$$

then boomerang encryption is defined as:

$$
\overleftrightarrow{\text { boomerang }}(\mathbf { sk }, \overrightarrow{m}, \overleftarrow{m}):=\overrightarrow{\text { onion }}(\mathbf{s k}, \overrightarrow{m} | \overleftarrow{\text { onion }(\text { sk }}, \overleftarrow{m}))
$$

where $$\overrightarrow{m}$$ is the forward message and $$\overleftarrow{m}$$ is the returned message. We note that the $$\overleftarrow{m}$$ cannot be returned without first decrypting all envelopes in the forward onion chain.

***Boomerang decryption as an anonymous proof-of-delivery***. We make the following somewhat surprising observation: a successful boomerang decryption can be turned into a proof of message delivery when applied to onion routing. Specifically, letting $$\overleftarrow{m}$$ (the returned message) be a random nonce acts as a message delivery receipt: it guarantees that every server along the path decrypted the correct onion layer and forwarded it to the next server. To see why this holds, observe that in order to successfully recover $$\overleftarrow{m}$$, all envelopes in the forward onion must be decrypted to recover $$\overrightarrow{m} | \overleftarrow{\text { onion }}(\text { sk }, \overleftarrow{m})$$.  Therefore, message $$\overrightarrow{m}$$ must have been delivered to the server at the end of the path (i.e., the last envelope in the forward onion chain must have been decrypted).


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://000z.gitbook.io/0/distinct-features/boomerang-encryption.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.