Re: [minion-cvs] Small corrections covering in particular the first half...

[Roger Dingledine <arma@mit.edu>]

On Fri, Feb 28, 2003 at 04:04:24PM -0500, gd@seul.org wrote:
>  each message. Link encryption also blocks many active and
> -passive attacks on the communication links, forcing attackers to run
> -corrupt nodes to mount these attacks.
> +passive attacks on the communication links, leaving the attackers with
> +the sole option of subverting the nodes themselves.

I still don't buy this. Even despite link encryption the adversary can
do traffic analysis to gain information. Agree/disagree?

>  We review mixes and mix-nets in Section \ref{sec:background},
>  describe our goals and assumptions in Section \ref{sec:assumptions},
>  and then address the above list of improvements in Sections
> -\ref{sec:design}-\ref{sec:nymservers}. We then summarize how our design
> -stands up to known attacks, and conclude with a list of open problems.
> -
> +\ref{sec:design}-\ref{sec:nymservers}. 
>   We conclude with a summary of
>  how our design stands up to known attacks, and a list of future work.

Whoops. Looks like I changed this, but left the old version in too. It's
a good idea to remove one of them. I'd prefer to keep the one that you
removed though. :) What do you think?

>  set.\footnote{Note that replies are still weaker than forward messages:
>  an adversary can successively force intermediate mixes to reveal the
>  next hop of the reply block until its originator is reached.}
> +% XXX I explain this in detail in my paper in NordSec2002 on
> +%     Forward Secure Mixes. Can add a ref if you wish... -GD

Yes, do so. I spent a while looking at the footnote wondering if we
should take it out, before realizing what it meant.

>  Mixminion's reply model is in part inspired by Babel \cite{babel}, as it
>  requires the creator of a reply block to keep no other state than its public
>  key in order to read the reply.  All the secrets that an anonymous recipient
>  needs to strip the layers of encryption from a reply message are derived from
>  a master secret contained in the last header of the single-use reply block,
> -encrypted with the recipient's public key.
> -% XXX this is no longer true.
> +encrypted with the recipient's private key.
> +% XXX this is no longer true. 
> +% - fixed it -GD

No, I mean it's more not true than that. :)

Encrypting it under the recipient's public key takes 128 bytes of space.
If we symmetrically encrypt some seed from which we can derive the keys
used at each hop, then we need only use 20 bytes. Also, the recipient can
more efficiently recognize which nym a message is for, since he doesn't
have to do any asymmetric crypto ops. See the E2E-spec.txt for more info.

>  Having indistinguishable replies, however, makes it more difficult to
> -prevent tagging attacks.  Since the author of a reply block is not the
> -one writing the message's contents, a hash of the entire message cannot be used.
> +prevent \emph{tagging attacks}. Since the author of a reply block,
> +used for routing and conventionally checking the integrity of the
> +message, is not the 
> +one writing the message's contents, a hash of the entire message
> +cannot be included in the SURB. 

Can we just change this to "Since the author of a SURB cannot predict
the message that will be attached to it, a hash of the entire message
cannot be included in the SURB."?

>  If he tags a message
>  leaving Alice, the payload will be entirely random when it reaches
>  Bob.  Thus, an adversary who tags a message can at worst turn the
> -corresponding payload into trash.
> +corresponding payload into trash, namely pseudo-random unpredictable
> +and unpredictable for the attacker bit strings.

perhaps "into trash (pseudorandom bit strings entirely unpredictable to
the attacker)."?

Remaining changes look good.
Thanks!
--Roger