Re: Lurkers: First draft: call for comments (was Re: Paper deadlines)

[Wouter Slegers <wouter@yourcreativesolutions.nl>]

On Tue, May 07, 2002 at 10:17:00AM -0400, Roger Dingledine wrote:
> On Mon, May 06, 2002 at 04:19:19PM +0200, Wouter Slegers wrote:
> > Overal: The document is hard to read "standalone", i.e. without prior
> > knowledge of the current discussions about remailers security and
> Our audience for this paper is people who have read and understood
> chaum81, babel, and remailer-essay.
Aside: maybe you should state this explicitly for those readers that are
interested but not yet current in remailer-theory, say the /. crowd.

> I'd like to also include a short
> overview of mixes, but I don't think we've got space for it at this
> point. Perhaps it should go as a separate document; but I think
> familiarity with the literature is a good thing to expect at this point.
Hmmm, I'm not referring to the generic design of a remailer, i.e. the
unwrap and forward design, but to the enhancements mixminion makes
w.r.t. mixmaster and particularly the reasons for these changes. Some of
them are implicitly stated (the tagging attacks come to mind) but some
are not.
Ah, I see that Zooko is writing on (part of?) this step-by-step design.

> > protocol-parts that are re-used from mixmaster I/II designs. In
> > particular paragraph 3.1 "Indistinguishable replies" is hard to read
> > without it.
> Hopefully section 3 has changed a bit since you last looked at it.
It's better.

> > Section 2 "Related work" should probably be moved to the end of the
> > document. It doesn't add to the understanding of mixminion as such, only
> > to differentiate it (but this is only apparent after you understand
> > mixminion).
> Hrm. This is a tricky one. The related work section is growing to provide
> a bit of the background that you were looking for above. Putting it
> at the end would have implications, e.g. we'd no longer have defined
> \emph{cascade} for the reader. It's a good thing to consider for the
> preproceedings revision; remind us about it then. :)
I will try. In any case, at least for me the related work section does
not provide additional information about the design of mixminion: by
reading that section the reader learns where some of the ideas came
from, but not how they work or why they are (or are not) carried over to
mixminion. So the section does not help the reader with his question
"what is mixminion and how does it work", which IMHO is the question
that the introduction as the teaser stimulates.
Hmmm, difficult to explain in email, but I'm looking at the paper from
the new reader's perspective and guessing their current information need
at each section. Section 2 IMHO has a mismatch here, as I think their
need is "ok, now I am interested, what is it?". Does that make sense?

> > Paragraph 4.4 "Message expiration, replay prevention and key rotation":
> > I do not understand why the rekeying frequency and the timeperiod over
> > which hashes of headers of messages are kept are set equal. It seems to
> > me that this links the security of a single node against (legal/hack)
> > compromise of its identity to the security of (partial) information on
> > the past traffic through that node. Ofcourse t_rekey >= t_hashflush, but I
> > can imagine flushing the hashes much frequently then longliving identity
> > keys.
> I can imagine flushes hash more frequently than longlived identity keys,
> but we must take care to never ever allow a replay of a message.
..
> So we thought rather than introducing timestamps inside messages to
> specify when they're valid, we would instead make a message unusable
> after a certain point (in this case, we do a key rotation to enforce it),
> and take care to remember hashes of *all* messages we've seen up until
> the key rotation.
Ok, that is the other part of the argument that I was looking for, i.e.
as we cannot allow message replay in the lifetime of an identitykey thus
t_rekey <= t_hashflush and therefor t_rekey == t_hashflush.

> > I think we also need to look at the information that these lists of
> > hashes contains, in particular from the point of defense against legal
> > attacks (sue for logs).
> Interesting point. Well, the presence of a hash in the replay db means
> that the MIX encountered a message whose headers hashed to that value,
> sometime since the last key rotation. This information is useful to
> somebody only via guess-and-check ("did you see this message? what about
> this one?"), so if they can't show up with the target message, they can't
> learn anything. And if they can show up with the target message, then
> by definition they're doing it before the key rotation (else the replay
> db will be erased), so the mix is able to decrypt the message for them.
> 
> So it sounds like the main attack is to show up with a message, and
> confirm ("prove") via the replay db that the mix did in fact preciously
> see the message. But note that I'm saying "see" and "encountered", not
> "processed and sent out the other side". Eg, the message might have
> decrypted to a broken message and been dropped.
Unless nodes have a built-in random drop function (which would severely
decrease the reliability of the network), this argument will not hold
for a court. The node is after all deterministic for all practical
purposes.
No, I think that the logs are proof that the node posessed the decryption
key for that message in that period and processed the message. The
message may have been dropped during sending or by the other node, but
that is another issue.
The conclusion to me seems to be that this hash-db of handled messages
makes a "I did not have that decryption key"-argument unbelievable so
that cannot be used as a defense against disclosure of cryptokeys by
legal force.

> Ok. I should sleep soon. Did I take that in the direction you intended,
> or a different one? :)
It was more or less the direction I was thinking of.

From a more information theoretical/cryptoanalysis point of view, the
hash database can be seen as information on the handled messages
(specificly their headers) in decrypted form. I can't really see what
that would give to an attacker, except that it may allow him to gain
information for bruteforce cryptoanalysis in a situation where he can
record only inbound OR outbound messages and get the hash database
afterwards (say via a blackbag operation). This seems to be a much less
usefull attack then compromising the node and keeping it in operation,
except that it may allow the attacker to go back in time for the period
that he was able to record the traffic but not grab the node. Not much
of a problem as far as I can see with only one cup of coffee :-)

With kind regards,
Wouter

-- 
Wouter Slegers
Your Creative Solutions
"Security solutions you can trust and verify."