[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[freehaven-dev] (FWD) 66arma_dingledine.pdf ---ACCEPT---ACCEPT---ACCEPT



----- Forwarded message from IHW 2001 <ihw@itd.nrl.navy.mil> -----

Date: Fri, 23 Feb 2001 15:11:28 -0500
To: arma@MIT.EDU
From: IHW 2001 <ihw@itd.nrl.navy.mil>
Subject: 66arma_dingledine.pdf ---ACCEPT---ACCEPT---ACCEPT 

Dear IHW2001 participant:

Included are the reviews for your paper.  The program committee consisted 
of 11 people. Every paper was carefully read by some subset of the program 
committee. I am including the reviews and the raw scores. Papers were 
judged on a scale from 0 (lowest) to 100 (highest) by each reviewer.  Of 
course, differences in reviewers scoring were taken into account.  Some 
reviewers just sent comments without a score (this is indicated by a 
missing score or NA ).

If your paper has been accepted, please read through the comments carefully 
and follow the reviewers' comments when revising your paper. In some cases, 
I have explicitly asked you to make certain alterations.

If your paper was rejected, I hope that you find the comments useful. 
Please note that, even though the comments for your paper might be sparse, 
all papers were discussed in detail among the program committee. Also keep 
in mind that we wanted a program that strove for originality, quality, and 
balance.

Registration information is now available at the IHW2001 web site
http://chacs.nrl.navy.mil/IHW2001
Questions about the program should be addressed to the Program Chair Ira 
Moskowitz at
ihw@itd.nrl.navy.mil .
However, registration & hotel questions should be addressed to the General 
Chair John McHugh at
jmchugh@cert.org  .

If in doubt, please send to both of us.

I look forward to seeing you in Pittsburgh this spring.

For the IHW2001 program committee, Ira Moskowitz.
February 22, 2001.


66arma_dingledine
______________________________________________________
Reviewer 1:Rating 89
Comments: Idea: stop service denial attacks on remailer stats
server by distributing it. This brings in various `electoral'
issues. Problem: doesn't work on the last hop. Receipts are hard
to do, and often fail. Also, you can't show that mixes fail, only
that hops fail. Various other nits can be picked; that's because
there's quite a lot of ideas here. Typographic point: put space
before citations to make them easier to read: ~\cite{}. Biblio:
full citation for refs 11 and 29, please.
______________________________________________________
Reviewer 2:Score        NA
______________________________________________________
Reviewer 3:give it a score 85
comments for author
Very nice paper - but a question:
In section 8 you write:
a sender has chance q/m each time it picks a MIX of picking a bad MIX.
Is this realy true? I believe this is only true for the first time I
pick a mix. If this was not a bad one, thanIi have a chance of q/(m-1)
to pick a bad mix for the second time and so on.
You write:
the chance of picking no bad MIXes is (1-(q/m))^k, since the sender
picks k Mixes...
If there are 5 MIXes and 3 of them are bad an I want to pick 4 MIXes,
than the chance of picking no bad MIXes is 0 i believe....
______________________________________________________
Reviewer 4: Score 50

Review summary: Severe practical problems associated with the
requirement for everybody to read everything all the time. Very strong
trust assumptions (that are not clearly stated). No clear advance.
Many meaningless statements about digital cash, weak treatment of the
related work.
Detailed comments: There are two types of mix networks: Synchronous
and asynchronous. Yours is asynchronous. Many of the other mix
networks you refer to are synchronous. The comparison is probably not
always meaningful, but you must point out the differences in trust,
model, and guarantees.
You do not speak of robustness. That is the term normally used to
describe the reliability of the mixing. You do not have a model that
describes what you assume, and what can be done. You also do not have
any claims of what you get. The goals on page 5 are unclear, and
insufficient without any description of the model.
Page 1: You say "Since shutting down ... for adversaries." I do not
understand what you mean and how that lead to the next statement.
Page 4, section 2.4 "some kind of digital cash". Why only like that?
Why not accounts? Makes no sense.
Page 4, sect 3. "negligible probability" should be "negligible
advantage". Define "passive adversary"! Otherwise it is a meaningless
statement. The part about traffic analysis being in its infancy is not
convincing. It is well understood how to perform traffic analysis if
you have unbounded (but polynomial) resources. That is the kind of
attack you have to consider!
Page 5: you require that the ledger is fully trusted. This is not made
clear. Why should I trust the ledger and not the servers? Why will
the ledger not constitute a bottleneck? Alice would have to read ALL
information available at the ledger. Otherwise, she reveals what
messages she is interested in checking the routing of. That means that
she has to read everything ALL the time -- stopping to be interested
would also reveal that the message has been delivered! This is
amazingly inefficient. If you read selectively, a lot of information
can be gleaned. That might be devastating.
p 7. "Unambiguous etc"> You are saying that D(E(m1))=m2 -> m1=m2. This
is absolutely standard, and it is meaningless to have it any other
way.
p 7 Do you need timestamps? By whom? If you trust the ledger anyway,
it only has to write down the time, no real time stamp.
p 9 "hash cash". Why such a solution? How do you verify the
correctness of an "access token"? If this has a cost associated with it
that is not way smaller than that of generating a random string and
submit that, it can still be abused for attacks. So it won't
work. This seems to be irrelevant to the remaining paper, and not
described in sufficient detail.
p 14. If you prove misbehavior, you give out identifying information,
as you state somewhere. That is a very low degree of robustness. A
last mix server on the line could always replace the outgoing message
with what he feels like. Will he be reported? The dummy messages you
suggest are the only way to do that. You give a feeling that things
are more secure earlier on. Carefully state what you achieve, early
on.
p 18 why is commercial remailers originally a cyberpunks idea, and why
is that relevant? It was Chaum's idea, wasn't it? Why would you need
to use digital cash? This opinion is not supported at all.
p 18 Yes, it is known how to make universally verifiable mixes. Many
of the mixes you quote as related work have that property.
p 18 How would you distribute the ledger? What do you mean?
Quorum control? Why is a distributed ledger better?
______________________________________________________
Reviewer 5:Score 50

The paper discusses a simple MIX-type network, and a reputation (or
rating) system for such a network.  It tries to present some details
formally, but in general it is extremely verbose.  Given that there is
nothing new in Sections 1-4, it could easily be condensed into 1/3 of
the pages, and I strongly recommend to do this. You should also avoid
lengthy presentations of trivial statements, like "Ciphertext
Collision Free Encryption;" please note that decryption is usually
deterministic, and in any case correctness requires that almost always
D(E(m)) = m for correctly chosen keys.

Regarding Sections 1-4, I disagree with your statement "The
reliability and efficiency of MIXes have been a secondary concern."
Reliability is the main motivation for using majority threshold
decryption for MIXes (your bibliography contains several such articles
...).  Ensuring synchronization among mixes and implementing a public
ledger is probably the most expensive part of most mix schemes, i.e.,
I don't think your overall design is more realistic than, e.g.,
threshold mixes a la [6]. Most of the modern scheme implement public
verifiability.

Sections 5-9 are somewhat new, but offer no surprises.  There is no
discussion on active attacks. For instance, usually a mix network
guarantees anonymity as long as one mix is honest. Now assume there is
only one honest mix. If it is easy to prevent this one honest mix from
acting quickly senders will complain an happily bridges this mix and
thus is giving up her anonymity. Or another example: if users choose
mixed according to their reputation then an adversary might simply try
to offer the best and most reliable service on many mixes, so that
often only his mixes are chosen.

Your calculations in Section 8-9 are too simplistic.

----- End forwarded message -----