Re: Payload encryption

[Roger Dingledine <arma@mit.edu>]

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