Re: Payload encryption

[George Danezis <gd@theory.lcs.mit.edu>]

Let me rephrase the question.

The issue arises when one considers how the (small amount of) information 
leaked by the remaining tagging attacks can be used by an adversary. We 
also need to assess how information can be used for traffic analysis.

There are the following cases:
1) Anonymous sender to identifiable receiver.
2) Identifiable sender to anonymous receiver.
3) Anonymous sender to anonymous receiver.

In case (1) tagging the first leg of the message will destroy the 
rest of the path. Tagging the second leg cannot be used to link messages 
(first leg provides anonymity). The message does not appear in clear at 
the swap point anyway, so there is no problem.

Case (2) should protect the anonymity of the recipient, and no tagging 
attacks can be performed since the adversary never expects to see any 
message "in clear".

Problems arise in case (3). The message appears in clear at the crossover 
point which can be used to detect tagging at the first leg. It can also be 
used to extract information (in the previous 2 cases it is obvious that 
information is going to be revealed to 3rd parties, while users that use 
bi-directional anonymous channels might be folled to think that the 
information transfered is private).

Both sender and receiver uses custom software so it is possible to encrypt 
the payload so that tagging attacks are more difficult to detect (because 
data will appear to be random in both cases). This should also mask the 
content of the communication.

Option A: No encryption. The recipient of the message is not known, so 
even if the tagging attack works, one can at best know that a sender sent 
a message (we do not want to provide unobservability anyway). Content is 
still revealed (we can hide content in case of tagging attack).

Option B: Encrypt the payload so that it is indistinguishable from noise 
in all cases. Prevents easy detection of tagging and content disclosure. 
Tagging can still be detected by the fact that the message will be dropped 
at the next hop.

Does that make more sense?

George

On Tue, 4 Jun 2002, Roger Dingledine wrote:

> On Fri, May 31, 2002 at 10:29:55AM -0400, George Danezis wrote:
> > *How should we do the encryption of the payload?*
> 
> I'm not quite sure I understand the question, so I'll think out loud
> for a bit:
> 
> We've got (at least) four types of mail coming out of the Mixminion
> network:
> 
> A) plaintext messages to normal users.
> B) encrypted messages to PGP-aware users.
> C) encrypted payloads going to anonymous users (via reply blocks).
> D) trashed payloads from tagging attacks.
> 
> It seems that in cases A and B, we'd like to send only the stuff the
> sender meant to send. The sender is using our software, the receiver
> is not. Both of these cases will have redundancies/recognizable text in
> the payload (yes, even case B. it'll have PGP headers, etc.).
> 
> In case C, on the other hand, the receiver is using our software, and
> the sender may not be.
> 
> So one simple solution is to include a short piece at the top of the
> payload, that basically specifies the length of the plaintext, and has
> some redundancy so encrypted/trashed payloads are unlikely to be mistaken
> for plaintext payloads. If the redundancy checks out, then the final
> mix extracts the appropriate amount of plaintext and sends it off to the
> recipient. If the redundancy doesn't check out, he sends it off intact
> [1], and assumes the recipient will know what to do with it.
> 
> [1] I'm assuming messages between mix nodes aren't ascii-armored. Would
> it be wise to ascii-armor non-plaintext messages going to recipients?
> 
> Now, with this solution, trashed payloads are only mistakable for
> encrypted payloads (case C), not for cases A or B. But really, we cannot
> get both "non-anonymous recipients don't have to use our software" and
> "all exiting messages look like trash".
> 
> So I'm not sure what your question is about. If it's a reply block,
> the payload will already look encrypted. If it's not, then we can't
> give the recipient software to decrypt the message, because that breaks
> our assumptions.
> 
> Can you clarify the problem?
> 
> --Roger
>