CS578---Privacy in a Networked World          Instructor: Antonio R. Nicolosi
      Notes for blackboard presentation, Week 7 (3 March 2008)

Mix-networks: Message delivery and anonymous reply
==================================================

Let's start with a bit of notation:

S is the original sender
M1 is the 1st mix-server in the cascade
...
Mn is the last mix-server in the cascade
R is the original recipient

We'll refer to the data going from the sender
to the recipient as "forward communication," and
to the response as "backward communication."

So the forward communication occurs as in the diagram:

.    ---->         ---->   ...   ---->        ---->    .
S    ---->         ---->   ...   ---->        ---->    .
.    ---->    M1   ---->   ...   ---->   Mn   ---->    .
.    ---->         ---->   ...   ---->        ---->    .
.    ---->         ---->   ...   ---->        ---->    R

(The dots refer to other senders/recipients in the system,
and the position of S/R is just an arbitrary example.)

Let's take a look at the backward communication.
Assuming we are going to use the same mix-servers,
but in reverse order (note: this is not necessary; it's just
easier to describe), then data flies as follows

.    <----         <----   ...   <----        <----    .
S    <----         <----   ...   <----        <----    .
.    <----    M1   <----   ...   <----   Mn   <----    .
.    <----         <----   ...   <----        <----    .
.    <----         <----   ...   <----        <----    R

Now, if R knew who the sender S was, communication
in the backward direction could occur exactly as for the
forward direction.

But how about the more interesting gase in which S is
writing anonymously, so that R does not know the sender,
nor the address? Even in that case, backward
communication can take place in a way that cannot be
traced back. How?

The point is that in the forward direction, S will have
included some information that allows R to create the
encrypted messages that will fly in the backward direction.

This info that S sends to R is called a "return block."
It basically consists of S's real email address, encrypted
under the public encryption key of mix M1 (the one that is
closer to S in the backward cascade), and then in
turn sequentially encrypted under the public encryption key
of all the other mixes:

Ret-Blk ::= { { { S, K1 }_EK1 , K2 }_EK2, ... Kn }_EKn

(Recall the notation { m }_EK : it stands for "a ciphertext
obtained by encrypting m with the public encryption key EK.")

Here, EK1 is the public encryption key for mix M1, etc.
The values K1, K2, ..., Kn (which I had not mentioned in my
short description above) are additionally symmetric keys,
that will be used for symmetric encryption; will get to that
in a second.

Ok, so the first step is for S to send R (in the forward
direction) a message consisting of three things:

- the return block, Ret-Blk (described above)
- an ephemeral public encryption key EK-tmp (for which
S knows the corresponding private decryption key)
- the actual text that S wants to get to R.

So when this "compounded message" is delivered to R, R
replies by sending the following to Mn:

        Ret-Blk, { reply }_EK-tmp

Mn <----------------------------------- R

Now, Mn can decrypt Ret-Blk, obtaining Rn and a "smaller"
return block Ret-Blk' of the form:

Ret-Blk' ::= { { { S, K1 }_EK1 , K2 }_EK2, ... K(n-1) }_EK(n-1)

Then, mix Mn sends the following to Mix M(n-1)

          Ret-Blk', { { reply }_EK-tmp }_Kn

M(n-1) <-------------------------------------- Mn

So that's how the keys Ki are used: the mix servers
successively re-encrypt R's reply with them. This is done
so that it's never the case that a mixer keeps its inputs equal
to its output: if mix Mn just relayed { reply }_EK-tmp
(which it got from R) to M(n-1), then it would be possible
for an attacker to correlate Mn's inputs with its output.
This, in turn, would make it possible to trace the path
that R's reply takes on its way through the mixes to S.
(Note also that the fact that R's reply is encrypted with
EK-tmp to begin with does not help in preventing this
sort of traffic analysis.)

The process is then repeated, and eventually mix M1
receives the message:

    Ret-Blk*, { ... { { reply }_EK-tmp }_Kn ... }_K2

M1 <------------------------------------------------- M2

where:

Ret-Blk* ::= { S, K1 }_EK1

Now, M1 decrypts this, finding out that this message is
headed to S. Notice, though, that M1 has no idea where the
message is coming from, nor can it tell what's the content.

In this way, S gets the encrypted reply:

{ { ... { { reply }_EK-tmp }_Kn ... }_K2 }_K1

Since S chose all of the keys involved in the ciphertext
above, S can decrypt it, thus obtaining R's reply in a
secure and untraceable way.