[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: modularization and some comments (was: Notes from Conversationwith Roger)
Dear All,
I see today is quite a working day for the MixMinion project. I hope we
are not bothering people who do not want to receive that much mail
(David?).
On Thu, 21 Mar 2002, Zooko wrote:
> 1. the "Mix Core" module
>
> This is the part that George designs with our help. Anything which directly
> affects the anonymity of the message mix belongs inside this conceptual module,
> and anything which does not affect the anonymity of the message mix belongs
> outside. (But see #3 and #4 below...)
>
This is the model I have in mind. Of course strictly the security of the
systems also relies on some properties of (#4) such as forward secrecy,
and #3 (management).
> 3. the "trust management" module
>
> This is a conceptual module, which is responsible for informing the Mix Core
> about what chains (and/or cascades) to use. One implementation is that the user
> manually specifies. Another is a random selection algorithm. A third would be
> transitive trust management such as Roger and Raph Levien are researching.
>
> Regardless of what kind of trust management you want to implement, I hope you
> will agree that it should be conceptually separated from the other modules.
Agreed.
>
> 4. the "MixMinion Transport Protocol" module
>
> Encryption, integrity, forward-secrecy, etc.
>
It turns out that SSL provides enough power to implement all the
properties we were looking for. I am still reading carefully the standard.
> George Danezis <gd@theory.lcs.mit.edu> wrote:
> >
> > I truly believe that there is a clear need (we may have mentioned before)
> > for a policy language where each mix puts: signature keys, encryption
> > keys, expire dates, mixes it peers with, modules installed, some stats on
> > latency and anonymity. Then we need a mechanism to parse this language and
> > produce candidate routes, given some inputs (minimal) from the user. It
> > would also be nice (wish list) to be able to get the anonymity set of the
> > network from these policy files.
>
> This is interesting. My first question is: can we make sure that this will be
> outside of the Mix Core module, so that George can finish defining it and we can
> proceed to implement it?
>
> If the user makes all decisions about the node chain (which seems good and
> proper to me), then all of this policy file stuff can be encapsulated in the
> trust management module and we can proceed on the Mix Core module.
>
Yes indeed I hope (and try to make sure) that the trust management will be
independent form the "mix core", GIVEN that the information is present in
the clients possession. How the client acquires this information without
compromising security is a whole different issue, and might need to be
done as an "application service" that uses the underlying mix network. Of
course as long as the number of servers is small a long list on a web
server should be fine.
> > It contains pseudo code for processing the
> > packets (That should go up to Andrei for proof)
>
> Andrei who?
>
Andrei Serjantov is a theorist here in Cambridge who is working (sometimes
with me) on proving anonymity properties.
Yours,
George